Re: [boost] New Acknowldegement for RenderX

From: Vladimir Prus (ghost_at_[hidden])
Date: 2007-08-19 06:43:47

John Maddock wrote:

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

Truly weird interface, I would say.

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

It is, as a quick look at $svn_trunk/Jamroot will reveal.

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

So, the requirement that user should be able to build boost from
a readonly medium without copying is lifted? 

> Frankly I'd be 
> pretty unhappy if the location changed, and coincidently, it would break
> quite a bit of Boost's current docs.

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