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" <[email protected]>
> To: [email protected]
> 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
> [email protected]
> https://www.redhat.com/mailman/listinfo/publican-list
> Wiki: https://fedorahosted.org/publican
> 

_______________________________________________
publican-list mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/publican-list
Wiki: https://fedorahosted.org/publican

Reply via email to