Re: [boost] Improving PDF generation - a common look and feel?

From: John Maddock (john_at_[hidden])
Date: 2007-05-08 06:31:38

Vladimir Prus wrote:
>> The biggest one is that PDF generation is a lot harder than it
>> should be with bjam: if we could get FO's and PDF's placed in a
>> "pdf" subdirectory that would help enormously - currently they get
>> generated in a directory of bjam's choosing under bin.v2 which
>> results in all links to images breaking
>
> Will "bin.v2/pdf" be fine? I don't feel like creating directories in
> the source tree.

We already put them in the source tree for HTML generation.  But yes, it 
does need to be in the source tree otherwise all external references to 
graphics are broken.  Manually copying them to "some other place" is what I 
want to avoid.  Folks already set their graphic's paths so that generated 
HTML finds them in the right place, so if we could do the same thing with 
PDF's so that the FO processor can find the existing graphics that would be 
great.  Docbook XML can stay where it is, it's just the PDF and FO files 
that need to move.

>> :-(  FO generation also fails if the FO file already exists.
>
> Which is FOP bug, it seems from your boost-build posting.

No happens before FOP is invoked: it's the XSLT stage that fails.

>> So basically
>>> I
>> need a Boost.Build expert to help with these: or at least explain
>> how the existing rules work!
>
> For removing output fop, I think you can do it yourself: add
>
>        $(RM) $(>)
>
> to fop action, and somewhere in fop.jam add:
>
>        RM = [ common.rm-command ] ;

Thanks, I will try this out.

> As for path -- I suppose I can do it. How urgent is this? I doubt
> I'll have any time this week.

Well it's not a release issue for sure.  Just another of those things that 
we should fix at some point :-)

I've had one go at fixing this myself, but only managed to make things worse 
:-(  If Doug G. or yourself can explain what needs changing I'll have 
another go.

Thanks, John.