Re: [boost] New Acknowldegement for RenderX

From: Vladimir Prus (ghost_at_[hidden])
Date: 2007-08-19 05:11:51

John Maddock wrote:

> Rene Rivera wrote:
>> 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 ;-)
> 
> Um, so you did, now where did I leave that brain of mine....
> 
>> 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.
>>
>>> 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?
>>
>> Which images?
> 
> 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 :-(

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?

> 
> 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.

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.

> 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.

I have no idea/comment on this alternative.

- Volodya