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

Norman Dunbar Norman at dunbar-it.co.uk
Thu Jan 26 10:20:31 UTC 2012


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




More information about the publican-list mailing list