http://permalink.gmane.org/gmane.comp.lib.boost.documentation hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://permalink.gmane.org/gmane.comp.lib.boost.documentation/4939 <pre> I had a look for places which would be affected by this. There's quite a lot of markup along the lines of: [pre some text ] Which will add extra whitespace to the left of the block. I could possibly unindent pre blocks in the same manner as code blocks, but since they can contain a wider variety of markup, I'm a bit worried that some markup might cause unexpectedly odd results. I'll look into it. </pre> Daniel James 2012-04-12T18:20:46 http://permalink.gmane.org/gmane.comp.lib.boost.documentation/4938 <pre> OK that works, thanks. BTW this looks like a plain bug to me - stripping newlines after [pre seems fair enough, but I can't think of a legitimate use case for stripping all whitespace, but, &lt;shrug&gt; I guess ;-) Thanks, John. </pre> John Maddock 2012-04-12T17:09:00 http://permalink.gmane.org/gmane.comp.lib.boost.documentation/4937 <pre> Yes, it has always done that. Looking at the source I fixed it for 1.6 but didn't for older versions to maintain backwards compatibility. I've done that quite a lot because I've found that seemingly sensible changes can break things. I should get round to finishing of 1.6, it's pretty much ready. I think I just need people to have a look at the changes and try them out to see if there's anything they object to or want changed. As a workaround, you can trick quickbook by putting something that doesn't cause any output after the pre tag (other than a comment), such as an empty template: [template empty] [pre [empty] 1 ] </pre> Daniel James 2012-04-12T12:04:45 http://permalink.gmane.org/gmane.comp.lib.boost.documentation/4936 <pre>I have a problem with this [pre] block: [pre 1 2 6 24 120 720 5040 40320 ................Limit of 16 bit integers 362880 3628800 39916800 479001600 ................Limit of 32 bit integers 6227020800 87178291200 1307674368000 20922789888000 355687428096000 6402373705728000 121645100408832000 2432902008176640000 ................Limit of 64 bit integers 51090942171709</pre> John Maddock 2012-04-12T11:32:43 http://permalink.gmane.org/gmane.comp.lib.boost.documentation/4935 <pre>Hi, If I have files like so: boost/bar/xxx.hpp boost/foo/www.hpp boost/foo/yyy.hpp boost/aaa.hpp boost/zzz.hpp Doxygen+Boostbook will give them in the following order: boost/aaa.hpp boost/foo/www.hpp boost/bar/xxx.hpp boost/foo/yyy.hpp boost/zzz.hpp i.e. it only looks at the name of the file and not at the path. Is there a way to fix this? </pre> Mathias Gaunard 2012-03-27T12:31:15 http://permalink.gmane.org/gmane.comp.lib.boost.documentation/4934 <pre> simpler of all the seemed or exploit it. is I don't think that this is quite the end of the story because you haven't mentioned PDF. matter how Although HTML is a requirement, for me PDF is also an extremely desirable end product of the documentation process. The docs are a single document and can be searched from end to end and used offline. All the hyperlinking works as well as the HTML, version including indexes. Steven Watanabe and John Maddock have done a lot of work to get this to function and many Boost libraries are also available in this format. but that I don't like the whole tool chain either, but once (if painfully) set up, it does the business quite smoothly. Paul --- Paul A. Bristow, Prizet Farmhouse, Kendal LA8 8AB UK +44 1539 561830 07714330204 pbristow&lt; at &gt;hetp.u-net.com </pre> Paul A. Bristow 2012-03-20T10:16:11 http://permalink.gmane.org/gmane.comp.lib.boost.documentation/4933 <pre> Yes! That's a really useful page, thank you! chunk.section.depth seems to be the setting I need. Thanks, that's a nice example. -Julian </pre> Julian Gonggrijp 2012-03-18T20:53:47 http://permalink.gmane.org/gmane.comp.lib.boost.documentation/4932 <pre> Thanks for your response. I've become quite interested in ways to make effective documentation simpler to generate and more useful. Soooo, just to make sure I understand all this more or less correctly. a) In the beginning there was DocBook b) Doug Gregor made BoostBook as DocBook with an extra layer of sauce for detailed specification of functions, classes, member functions, etc. c) A couple of libraries have used BoostBook directly. Any, DateTime but those don't seem to use all the detail that BoostBook has. d) Joel Guzman made quickdoc as a quick way to generate HTML from a simpler mini-language e) Eric Neibler used this to make quickbook which generates BoostBook. The generated BoostBook doesn't included all the BoostBook "detail" because the quickbook mini-language doesn't have a syntax to specify it and also because no one seemed suffiiciently interested to do this because 1) It's a pain the butt, and 2) no other tools rely on or exploit it. f) Doxygen has been used to generate XML which is then p</pre> Robert Ramey 2012-03-18T19:30:03 http://permalink.gmane.org/gmane.comp.lib.boost.documentation/4931 <pre> Quickbook doesn't have any support for writing boostbook reference documentation, most people write it using doxygen, write it directly in boostbook, or write it in quickbook. Quickbook does have support for linking to boostbook reference document (funcref, classref etc.) so it integrates well with it and isn't just a docbook generation tool. AFAIK there's no one has ever expressed any desire for writing boostbook reference documentation in quickbook, I don't think it'd be a particularly good match. It might be possible to do something using escaped boostbook and templates. </pre> Daniel James 2012-03-18T13:29:24 http://permalink.gmane.org/gmane.comp.lib.boost.documentation/4930 <pre> This is really a docbook question, rather than a quickbook one, but basically all the XSL params you need are documented here: http://docbook.sourceforge.net/release/xsl/current/doc/html/index.html under "chunking", and as you can see there are quite a few options to choose from! Take a look at the Jamfile in libs/math/doc/sf_and_dist which messes with some of these. HTH, John. </pre> John Maddock 2012-03-17T13:25:29 http://permalink.gmane.org/gmane.comp.lib.boost.documentation/4929 <pre>Dear quickbook/boostbook wizards, I'm fooling around with sections and it struck me that only the top-level sections are isolated on separate pages. How can I let quickbook/boostbook/bjam know that I want the subsections to be on separate pages as well? My Jamfile: main.qbk: The resulting table of contents (as I want it): The generated pages (not as I want it): How I'd want the pages to be generated: This is, by the way, a type of information I'd expect to find in the quickbook or boostbook documentation. Unfortunately neither provides any clue on how paging can be adjusted. Hopefully somebody can help me out... thanks in advance. -Julian </pre> Julian Gonggrijp 2012-03-17T09:39:51 http://permalink.gmane.org/gmane.comp.lib.boost.documentation/4928 <pre> That's probably correct. I'm not any more knowledgeable about all of this than you, but hopefully I can still help a little with some educated guesses from an outsider's perspective. :-) BoostBook is described as an "extension" to DocBook, which makes me think that it's a variant of DocBook rather than some kind of preprocessor for it. So I'd expect that BoostBook xml is translated directly to html (through the BoostBook xslt sheet). Yes, but note that according to the QuickBook documentation it started out as a sample application for Boost.Spirit that produced html directly. It was adapted to be translated to BoostBook xml only later. So, I think this is because QuickBook was not originally designed as a "shorthand" for BoostBook. I don't know either, but QuickBook seems to be dealing well with code nonetheless (importing, displaying, linking). Since it's smart enough to colour your syntax, I guess it may perhaps also translate your "plain" code into semantically structured xml. Yes,</pre> Julian Gonggrijp 2012-03-10T11:12:27 http://permalink.gmane.org/gmane.comp.lib.boost.documentation/4927 <pre>I thought I understood this: // docbook includes all the transformations to generate "general purpose" documents // xslt transforms docbook elements to html or whatever. docbook xml -&gt;xslt -&gt; html or (fo -&gt;pdf) or ?.. // boostbook adds a bunch of new elements specialized for C++ library documentation // xslt transforms this to docbook elements. The output of this transformation can be used above. boostbook xml -&gt; xslt-&gt; docbook xml // quickbook defines a new "more convenient syntax" for C++ library documents // quickbook transforms this syntax to boostbook syntax to be used above. quickbook source -&gt; quickbook -&gt; boostbook xml. OK this always made sense to me. I look in the documentation for boost book xml and I find a lot of elements such as function, method, etc with a fairly elaborate structure This also makes sense since the object is to capture the "meaning" or "structure" of the documentation (and by implication the library being documented). BUT when I look a the quickbook syntax I don</pre> Robert Ramey 2012-03-09T23:05:57 http://permalink.gmane.org/gmane.comp.lib.boost.documentation/4926 <pre> You can set the path in your user-config.jam file. Something like: using boostbook : /usr/share/xml/docbook/stylesheet/nwalsh/current ; I didn't implement it, so I can't say for sure. Probably just to have a single method for all platforms. It originally required you to explicitly specify the paths, checking known locations is a pretty recent addition. There are problems with relying on the standard catalog. There's a fairly good chance that on some machines it won't be correct, or will be missing an entry. For example, if the stylesheets were installed manually or the packaged versions were uninstalled badly. To automatically support catalog files, it'd need to do is to first check that the catalog exists and then check that it correctly maps the relevant paths to existing local files. Or perhaps there could be some special parameter to say, 'use this catalog', although it'd also need to somehow know which urls are mapped in the catalog. We're probably short on volunteers willing to implement such a </pre> Daniel James 2012-02-29T12:59:31 http://permalink.gmane.org/gmane.comp.lib.boost.documentation/4925 <pre>Trying to build the boost documentation on openSUSE fails because the stylesheets are in /usr/share/xml/docbook/stylesheet/nwalsh/current (a symlink to the current version) and not in /usr/share/xml/docbook/stylesheet/nwalsh where boost.book searches. This begs the question why you check that at all on Linux. All standard stylesheets and dtds can be found via the catalog so /etc/xml/catalog is the only thing that needs to be referenced besides the boost.book specific stuff. Being not very familiar with JAM (boost is the only package I maintain for SLES/openSUSE that uses it), how would I have to change boostbook.jam in order to conditionally not use docbook-xsl-dir and docbook-dtd-dir? Currently I simply use the attached patch for boostbook.jam but that doesn't make it conditional on OS. Philipp _______________________________________________ Boost-docs mailing list Boost-docs&lt; at &gt;lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-docs </pre> Philipp Thomas 2012-02-29T10:10:14 http://permalink.gmane.org/gmane.comp.lib.boost.documentation/4924 <pre>Hi, Some library documentations start with Chapter 1.0, for example: bimap, ICL, and also Boost.Geometry. Many do have a proper chapter number. How is this number assigned? I cannot find the difference between our main QBK and for example that of Chrono, which has a proper chapter number. Should we add a dependency in doc\Jamfile.v2 ? Because I see this line &lt;implicit-dependency&gt;../libs/chrono/doc//chrono it seems logical that geometry (and some other libs) should be added there. Is then a chapter number assigned? Or does it work otherwise? Thanks, Barend </pre> Barend Gehrels 2012-02-12T11:21:05 http://permalink.gmane.org/gmane.comp.lib.boost.documentation/4923 <pre> Unfortunately neither help with offline reading of the docs - we could probably get MathJax working acceptably well for online docs - it's reading the docs on your hard drive that's the issue. Cheers, John. </pre> John Maddock 2012-02-02T16:16:12 http://permalink.gmane.org/gmane.comp.lib.boost.documentation/4922 <pre> Never tested this myself: http://en.wikipedia.org/wiki/MathPlayer Also, have you tried using an Apache RewriteRule to redirect all MathJax requests into subdirectories into a unique location? Disclaimer: Never heard about MathJax before this. Mika Heiskanen </pre> Mika Heiskanen 2012-02-02T14:05:59 http://permalink.gmane.org/gmane.comp.lib.boost.documentation/4921 <pre>containing if you disappear :-( Looks a non-starter :-( But MathML should 'just work'. IE9 says clearly "Note: Your browser does not support Native MathML rendering". So IE users will not get equations - end of story? SVG's, :-) - they all look the same, and are nice and sharp and can be magnified without going fuzzy. Nobody should be using older versions still? (On security grounds at least). Can we just only support IE9? - or some standards compliance browser - like any of the others! SVG or the enough, IE and It doesn't solve the problem immediately, but should we report this to MS. (After all equations are a long running saga!) SVG and gone the IE As Victor Meldrew would say " I do not believe it!" In summary, my view is that we should accept that IE viewers won't be able to see the equations until native MathML is supported. (And then only for IE9). (Do we still need SVGs for PDF generation?) So is that acceptable? It is to me but what do others think? Sympathy, and thanks for end</pre> Paul A. Bristow 2012-02-02T12:52:27 http://permalink.gmane.org/gmane.comp.lib.boost.documentation/4920 <pre>Some more experimentation reveals that: * IE9 will only support the MathJax scripts if the script is loaded from a subdirectory of the one containing the HTML (a non-starter) otherwise you get a security warning (which I missed the first time), and if you either miss the warning or just follow IE9's advice and block the script then all the equations disappear :-( * I tried using SVG's instead of MathML or Tex, and Oh dear that's as bad :-( Yes IE9 supports SVG's, but in order for a graceful fallback be provided for earlier IE users you have to use &lt;object&gt; tags - that's OK that's what the Docbook stylesheets generate - except IE9 (and only IE9) won't then display either the SVG or the fallback image unless the image has explicit width and height attributes. If that's not bad enough, IE and all the other browsers handle the width and height attributes differently. I'm mean seriously what the &amp;&amp;^%$$ does MS think it's doing here? Anyhow, I simply can't find a magic combination of factors that </pre> John Maddock 2012-02-02T11:19:12 http://permalink.gmane.org/gmane.comp.lib.boost.documentation/4919 <pre>I've been experimenting with the tentative equation handling support in Trunk, and have some observations: * There's no docs.... took me a while to figure out what to do... * I added quickbook markup as follows to doc/test/test.qbk to test both LaTex and MathML support: [section Equations] This equation is formatted from Latex text: '''&lt;inlinemediaobject&gt;&lt;textobject role="tex"&gt;ax^2 + bx + c = 0&lt;/textobject&gt;&lt;/inlinemediaobject&gt;''' This equation is formed from MathML: '''&lt;inlinemediaobject&gt;&lt;textobject role="MathML"&gt;&lt;?dbhtml-include href="test.mml"?&gt;&lt;/textobject&gt;&lt;/inlinemediaobject&gt;''' [endsect] Then I modified the Jamfile to add an xsl:path attribute so that test.mml could be found in the current directory, and everything builds OK, raw HTML output looks OK to. * The equations are both rendered correctly in Firefox, but MathJax support is only present in the HTML if a Tex object is present - I guess some change to our XSL stylesheets is required for the latter (and that I can't set the role t</pre> John Maddock 2012-02-01T19:28:21 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.comp.lib.boost.documentation