Andreas L Delmelle wrote:
AFAICT, it is already parsed with SAX (see
org.apache.fop.fonts.FontReader).
Perhaps it is something else then? :S
It doesn't seem like it's those widths by itself that are causing the
problem. An array of 50K int-widths should correspond to min. 200K
max. 400K of heap. :/
That sounds logical.
Can you provide a bit more context information?
Does it appear as a cumulative effect, or does the problem also
present itself if the document has only one fo:block with a few
characters?
Does it (only) appear in a context where multiple documents are being
rendered in parallel?
No, it appears with one document, with one table that has several cells
with in some of those cells one character from another font. The rest of
the document (which is in total 1 page) consists of SVG and some "plain"
text blocks in other cells (with the default font). I tested without all
the rest (no SVG etc) and the problem persisted. If needed, I can
provide you with the full xsl-fo. When I remove the other font and
replace it with a base-14 font, the problem disappears.
But my original memory counting was flawed by other processes. I did
some additional tests and found that, regardless the size of the
one-page table:
1. With only Base-14 fonts, FOP consumes about 25 MB of the JVM
memory pool.
2. With the Arial Unicode MS (one char is enough), FOP consumes about
80 MB of the JVM memory pool
3. Without Tomcat (just commandline), FOP consumes approx. 95MB with
the Unicode font.
Taken that the font itself (the TTF) is 23MB (but why would it be read
in memory in full if you only need one character?), this still doesn't
add up, not even if you count the 50.000 integers for the widths. But it
makes it much more likely than my original 500MB increase (sorry about
that).
Cheers,
-- Abel
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
