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.
1)
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
line?
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
trick:
<fo:block text-align-last="justify">A <fo:leader/> B</fo:block>
2)
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"/>
</svg:g>
</svg:svg>
</fo:instream-foreign-object>
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"/>
</fo:inline>
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.
Regards
Jesper
On Mon, Sep 30, 2013 at 7:04 PM, Kevin Brown <kevin(_at_)renderx(_dot_)com>
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
--~------------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail:
<mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--
--~------------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: <mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--