[XSL-LIST Mailing List Archive Home] [By Thread] [By Date]

Re: [xsl] XSL-FO to PDF conversion speed

Subject: Re: [xsl] XSL-FO to PDF conversion speed
From: Jesper Tverskov <jesper@xxxxxxxxxxx>
Date: Tue, 1 Oct 2013 11:07:08 +0200

Thanks for all the nice information.

When it comes to just the stylesheet, I have managed to reduce
processing time 20% just by fine-tuning the FO and doing away with a
couple of small tables replacing them with tricks like below.

I would like to share two tricks, the first one I found googling, the
other one took an hour of hard experiments and fine-tuning.

How can you do away with a small table of one row and two columns used
for pure layout, e.g. in a page footer to have the title of a document
aligned left and the page number aligned right in one and the same

In the solution below I have reduced the problem to left-align A and
right-align B in the same line. Justify and fo:leader are doing the

<fo:block text-align-last="justify">A <fo:leader/> B</fo:block>

The FO contained the following cracy SVG, used four times to create
small HTML like form checkboxes!

<fo:instream-foreign-object xmlns:svg="http://www.w3.org/2000/svg">
<svg:svg width="9pt" height="9pt">
<svg:g style="fill:none; stroke:black; stroke-width:1">
<svg:rect x="0" y="0" width="9" height="9"/>

I managed to replace the SVG with the following:

<fo:inline font-size="8pt">
<fo:leader leader-pattern="rule" rule-thickness="8pt" color="white"
border="solid 1pt black" leader-length="9pt" alignment-baseline="mathematical"/>

I don't know what "mathematical" means but it gave me the most perfect
vertical alignment of the checkboxes.

Sadly enough there where no really bad FO in the original solution
like nested tables.


On Mon, Sep 30, 2013 at 7:04 PM, Kevin Brown <kevin@xxxxxxxxxxx> wrote:
>> Some of that will probably be JVM startup.
>> There are ways to mitigate that (e.g. nailgun) or you could maybe run FOP
> from a servlet.
> Certainly. Running a single document especially in a Java/bat/sh call will
> never perform even close to a server-based solution. Unless the server is
> written incorrectly and does things like clean-up after processing a single
> document which would wipe the cache of things like fonts (and then load then
> again on the next call).
> Also fonts are involved in both startup and processing. Many people use
> crazy fonts like Arial Unicode MS. The use of this font in a real conforming
> (copyright aware) processor adds at least 356KB to the file size minimally
> if you subset the font. This is because the font prolog is that large and
> required for copyright consideration. And parsing a 26MB file to extract
> this prolog and a single character takes time. As does pre-processing all of
> the fonts that may be specified in the configuration at start-up.
> Complex tables and especially nested tables are performance drains. Keeping
> track of keeps and end of page conditions and possible table headers and
> footers (not to mention the possibility of footnotes) is complex. I have
> seen performance of documents double when removing nested tables when they
> are not required.
> Kevin Brown
> RenderX

Current Thread