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

[Jared Morgan]

Hi Norman

Apologies for the tl:dr response that follows, but stick with it and hopefully it will help you.

I had trouble getting FOP playing nicely on F16 at all. I asked internally here, and it was suggested that I give the wkhtmltopdf plugin a shot for PDF generation.

You might want to revisit the thread back in August 2011, that goes into a bit of detail about the testing of the tool. Jeff has rolled some of his own RPMs, which are available from the links in the email thread below..

https://www.redhat.com/archives/publican-list/2011-August/msg00063.html

Caveat: this is not yet implemented in publican fully yet, and is very much a beta feature. But it is about 10 times faster than FOP, and at least for me, results in frankly beautiful PDF output (thanks Publican team for getting it this far!!).

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.   

If wkhtmltopdf does not fix your issue, or makes it worse, just remove both packages and you are back to FOP.

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

I hope this helps you out. It certainly made the PDFs I was generating locally look fantastic, and function correctly.

Cheers

Jared Morgan
EPP Maintenance Lead | PressGang Lead
Red Hat Asia Pacific
1/193 North Quay
BRISBANE QLD 4000

P: +61 7 3514 8242
M: +61 413 005 479

Too brief? Here's why! http://emailcharter.org 

----- Original Message -----
> From: "Norman Dunbar" <Norman at dunbar-it.co.uk>
> To: publican-list at redhat.com
> Sent: Thursday, January 26, 2012 8:20:31 PM
> Subject: [publican-list] Dbfo keep-together instructions stripped out by	publican?
> 
> I'm running Publican 2.8 on Fedora 16.
> 
> I have a manual that I'm creating and in order to prevent all tables
> splitting across pages, I've added the following to a customisation
> layer which I've called pdf.xsl after renaming the Publican file of
> the
> same name to pdf.original.xsl. (This is in the
> /usr/share/publican/xsl
> directory.)
> 
> <?xml version='1.0'?>
> <!DOCTYPE xsl:stylesheet>
> 
> <xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
> ...
> 
> <!-- import original pdf.xsl file from Publican -->
> <xsl:import href="pdf.original.xsl"/>
> 
> <!-- Don't allow tables to split over a page boundary. This will,
>    ++ unfortunately, cause large tables to crush up. These will
>    ++ need an individual processing instruction as follows:
>    ++
>    ++ <table>
>    ++ (optional) <title> ... </title>
>    ++ <?dbfo keep-together="auto" ?>
>    ++ ...
>    ++ </table>
> -->
> <xsl:attribute-set name="table.properties">
>    <xsl:attribute
>    name="keep-together.within-column">always</xsl:attribute>
> </xsl:attribute-set>
> 
> <xsl:attribute-set name="informaltable.properties">
>    <xsl:attribute
>    name="keep-together.within-column">always</xsl:attribute>
> </xsl:attribute-set>
> 
> ...
> 
> </xsl:stylesheet>
> 
> The problem is that while the tables do not split over a page break,
> which is what I want, the two very large tables now get crushed up
> onto
> a page.
> 
> I looked in the tmp/en-US/xml folder for the Publican processed xml
> file
> and the processing instruction I added to the big tables had been
> stripped out.
> 
> There were no warning messages about deprecated or invalid xml when
> processing the particular file in question.
> 
> Is there a way I can get around this please?
> 
> As a workaround I could add the instruction to the Publican generated
> XML file, there are only two large tables, but how do I then get the
> build to (a) stop after generating the XML and (b) generate the PDF
> from
> the tmp/en-US/xlm files rather than starting again from my source
> files?
> 
> 
> Many thanks.
> 
> 
> Cheers,
> Norm.
> 
> PS. Happy to log a bug, but a search showed nothing relevant and I
> thought I'd ask first. Thanks.
> 
> --
> Norman Dunbar
> Dunbar IT Consultants Ltd
> 
> Registered address:
> Thorpe House
> 61 Richardshaw Lane
> Pudsey
> West Yorkshire
> United Kingdom
> LS28 7EL
> 
> Company Number: 05132767
> 
> _______________________________________________
> publican-list mailing list
> publican-list at redhat.com
> https://www.redhat.com/mailman/listinfo/publican-list
> Wiki: https://fedorahosted.org/publican
>