Re: [boost] New Acknowldegement for RenderX

From: John Maddock (john_at_[hidden])
Date: 2007-08-19 06:02:18

Vladimir Prus wrote:
>> 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?

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?

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

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.