Re: [boost] New Acknowldegement for RenderX
Doug, - try us. I hereby grant you permission to use XEP to format Boost project's documentation in server environment until our VP of Sales - Kevin Brown, contacts Boost and emails our formal license for such purpose. Kevin should do it either tonight or in several days (he's out of town). He will also send you a license for DevKit that includes API. I think you will find it useful. Let me know if you need anything else: Java PDF, Docbook PDF related tools: www.renderx.com/tools our new development - DiType: http://moin.renderx.com/rxwiki We always like to work with technology people who promote open standards. Roman Kagarlitsky, CEO www.renderx.com
Roman Kagarlitsky wrote:
Roman, Very many thanks for that: it's a generous offer and I'm sure we'll be able to put that to good use. Doug: is there server space we can put this on? The tricky part I suspect is getting links to images to function correctly, we may need some adjustments to BBv2 before we can make full use of this? John.
Taking this to the docs list... John Maddock wrote:
Doug: is there server space we can put this on?
I brought the possible need for a documentation building server with the moderators last week. Which includes you John ;-) I mentioned setting up a buildbot for this. In particular it would be possible to have a doc building slave which others can ask to build docs with (from the buildbot web interface). If the doc builder is the OSL machine the docs can be made available through beta.boost.org.
Which images? -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo
Rene Rivera wrote:
Um, so you did, now where did I leave that brain of mine....
Here's the outstanding issue: suppose I have a quickbook file that references some png's (or whatever): [$../graphs/graph1.png] The path ../ is set up so that it's relative to where the html docs are generated (in a html/ subdirectory), but FO files and PDF's currently end up in a long mangled path under bin.v2/. So... neither admonishment graphics, nor referenced image files are found, unless you manually move them to where the FO processor is looking for them. Not fun :-( So the question is how do we get the server to "work". If we instruct it to build from a Jamfile in SVN, then IMO we need to fix up BBv2 so that .fo and .pdf files get placed in a sub-directory (called pdf?) just like HTML does, and then hopefully external image files will get automatically found. In fact I believe this is the "right thing to do" anyway, as it eases local building. Alternatively, the easiest option for the server setup might be to only accepts self-contained .fo files with all the images embedded inside it. Unfortunately I don't believe that XSLT processing can automatically embed externally referenced image files, so that would need a post-processing step or something. Thoughts? John.
John Maddock wrote:
I think the idea of "setting paths ... so that it's relative to where the html docs are generated" is wrong -- if you add "--build-dir" option to bjam, all your paths will be wrong, even with HTML. Is there any option to quickbook/boostbook/docbook to specify search paths for images?
Uh, well, removing toolset and other things from build path will be easy. The problem is that now HTML generation is weird -- it generates to $srcdir/html and unconditionally putting thigns to srcdir is bad. So I'd suppose we need to fix that first, and then again, relative paths to images won't work.
I have no idea/comment on this alternative. - Volodya
Vladimir Prus wrote:
Yes there is, it's the image.src.path option. I haven't tried it though, because the path specified in the <xsl:param> Jamfile option requires a trailing / in the name, but bjam "helpfully" strips the slash from filenames, so specifying paths to external elements that way is currently broken anyway. In any case, how would we set a relative URL from what is currently an "unmentionable" path where the pdf docs are built to the image location? Or even an absolute path for that matter - is $(BOOST_ROOT) generally available in a Jamfile these days?
I can only speak for myself here: but personally I really like where the html is placed now, and I'd like pdf's etc to do the same. Frankly I'd be pretty unhappy if the location changed, and coincidently, it would break quite a bit of Boost's current docs. John.
John Maddock wrote:
Truly weird interface, I would say.
It is, as a quick look at $svn_trunk/Jamroot will reveal.
So, the requirement that user should be able to build boost from a readonly medium without copying is lifted?
What's going to break, specifically? Note that even now, the doc location is different when building full boost docs, and when building docs for just a single library. - Volodya
Vladimir Prus wrote:
None the less, all the Docbook XSL stylesheets when they accept a path-prefix *require* that it terminate in a /.
Ah, OK good.
The user doesn't need to build docs though: they already exist in the distribution.
Yep, which is a real pain. There are several recent libraries in SVN now that use quickbook, but put there docs in libs/libname/doc/html rather than integrating into the central doc/ build, which IMO is getting out of hand and doesn't scale to large numbers of libraries. See regex, Bimap, um quickbook, and I'm sure others for examples. But all this is moot, if there is a way to put the output *wherever you want it*, *and* there is a way to pass URL's to xsltproc without bjam helpfully stipping off the trailing / :-) John.
Vladimir Prus wrote:
FWIW: I have worked out a solution that almost works. I wrote a manifest install generator that is able to take the path to a manifest file as its input and will copy all files that are described by this file to whatever location is desired. I did this with some little shell scripts (residing in bjam actions) and making use of copy and mkdir commands as the only external tools required. This works already for windows and linux. Currently boostbook.jam however is hardwired to generate the docs to $src/html, but this is easy to change. Roland aka speedsnail
John Maddock wrote:
OK, and I have a makefile that puts the output where I want it, and finds all the images etc :-)
Sorry, I lost track. I was speaking of Jamfiles. Do you mean Jamfile when saying Makefile? Roland aka speedsnail
This is an kind offer we would be most curmudgeonly to refuse ;-) (It would be nice if RenderX were *using* Boost too - then we can include you in our 'Who's Using Boost' page). Thanks. Paul --- Paul A Bristow Prizet Farmhouse, Kendal, Cumbria UK LA8 8AB +44 1539561830 & SMS, Mobile +44 7714 330204 & SMS pbristow@hetp.u-net.com
participants (6)
-
John Maddock -
Paul A Bristow -
Rene Rivera -
Roland Schwarz -
Roman Kagarlitsky -
Vladimir Prus