Re: [Boost-docs] [boostbook] Docbook processing instructions get stripped out?

Subject: Re: [Boost-docs] [boostbook] Docbook processing instructions get stripped out?
From: John Maddock (boost.regex_at_[hidden])
Date: 2010-10-28 16:04:45


>> For example if I insert:
>>
>> '''<?dbtimestamp format="Y-m-d H:M:S"?>'''
>>
>> Into my quickbook source, then the processing instruction is present in
>> the
>> Boostbook source, but not in the Docbook source (and hence missing from
>> final output).
>>
>> Anyone any ideas?
>
> You probably just need something like the attached patch. It might
> need some more rules for different contexts.

Thanks, that gets it for me, is there anyway we can verify that this doesn't
break anything before committing to Trunk?

Next thing.... I've been experimenting with generating HTML-only features,
in particular integrating MathJax MathML support into Boost.Math's pages so
we get proper equations instead of PNG's, just like we do in PDF output.
There are a number of hurdles to overcome, but at present:

1) There's currently no way to know for sure what the current build target
is: bjam knows this information, so we can inject it into a command line
such as an XSL param, but as far as I can see there's no way to get at this
information within quickbook (or to pass it to quickbook?) so that we could
use quickbook's conditional feature? We could also use Docbooks profiling
feature for this, but that would mean invoking different stylesheets
(profile-chunk.xsl rather than chunk.xsl), and I'm not too sure what the
consequences of that would be. Ah wait, just checked, and I suspect that
two pass profiling is required in our case, which makes things even worse
:-(

2) I would need a way to insert random chunks of HTML into the <head>
section of each chunk to load the equation processor, I guess I could write
a program to do this and have it run post-html-build. Unless there's an
easier way (preferably without making our stylesheets even more complex)?

3) I can foresee opposition to having documentation relying on third party
JavaScript code - in fact having just checked it's 124Mb which I think rules
out inserting it into the Boost SVN tree :-( We could put it on the server
only I guess, but then that would rule out off-line browsing. Dang,
snookered :-(

Thinking out loud yours, John.


This archive was generated by hypermail 2.1.7 : 2017-11-11 08:50:41 UTC