[publican-list] Dbfo keep-together instructions stripped out by publican?

[Norman Dunbar]

Morning Jared,

> Apologies for the tl:dr response that follows, but stick with it and hopefully it will help you.
Ummm, tl:dr? You've got me there!

<SNIP>

I have looked at the wkhtmltopdf utility and found it ok, that was when 
it was first announced. I have not yet tried to interface it with 
Publican - I shall certainly give it a try as a publican plugin.

<SNIP>

> It *might* also solve some of your table problems that FOP is causing. The keep-together issue has stripped out entire<task>  blocks from PDFs that are larger than 1 page in length.
I'm not seeing this. The big tables are still there in the pdf, just 
wrapped around themselves on a page. The reason being, as far as I can 
see, that my processing instruction within the large tables has been 
stripped out by the publican build command, before it gets to converting 
from xml to xsl-fo and before fop is involved.

In my customisation layer over pdf.xsl I have set the keep-together to 
be "always" and for these two tables, a PI sets it to "auto". If I 
change it back to "auto" then these two tables do correctly split but so 
do all the other ones I don't want splitting.

Under plain old DocBook, it works the way I need it to work. So I'm 
assuming that Publican's preprocessing is the culprit and is quietly 
removing my PI from my source. But is doing so without warning me.

Running publican build --format=test .... shows no warnings about the PI 
and the print_banned output doesn't list PIs as being a bad thing either.

<SNIP>

> Based on previous bugs I raised against FOP issues, I don't think this will be fixed any time soon (because to get it working correctly across the many scenarios that require keep-together is a tremor-inducing nightmare).
As I mention above, I'm not convinced that this is a FOP issue, the PI 
is stripped out long before FOP is executed.

> I hope this helps you out. It certainly made the PDFs I was generating locally look fantastic, and function correctly.
Thank you again. I will give the new system decent chance. It may well 
fix the problem without needing the PI, I hope so, and it will be a lot 
quicker than me trying to learn perl to see what's what in the source 
for Publican! ;-)

Many thanks.


Cheers,
Norm.

PS. Brisbane? I love that place.

-- 
Norman Dunbar
Dunbar IT Consultants Ltd

Registered address:
Thorpe House
61 Richardshaw Lane
Pudsey
West Yorkshire
United Kingdom
LS28 7EL

Company Number: 05132767