Bug #: 52477
Summary: FOP always uses the same prefix for embeded font
After having some problems with ghostscript while trying to concatenate PDF
files generated by FOP, we went to the conclusion that FOP generates the
embedded fonts prefix by always using the same sequence.
@see http://bugs.ghostscript.com/show_bug.cgi?id=692795 for the initial bug
According to Ken Sharp from ghostscript, the embedded font should have an
unique name, non-repeatable across multiple generations. I couldn't find this
in the PDF specs, but i kinda lost myself trying to find anything in there, so
this is not really relevant.
Basically, it seems that FOP always generates the embedded font prefix by using
EAAAAA, EAAAAB, EAAAAC etc sequentially when it should generate unique
Because it generates the same prefix, gs(and the PDF viewer) cannot display the
required fonts. I cannot contribute a patch as i have 0 knowledge of java, but
i think that the prefix should be based on the current timestamp+the current
index(easiest), or be based on the currently embedded font glyphs, this should
be more accurate, but any method will do for now.
It should be able to disable this through the command line to allow automatic
unit-tests that tests binary files to not fail because of always having
something different in otherwise identical files.
I have font-embeding enabled, according to
http://xmlgraphics.apache.org/fop/trunk/fonts.html#embedding , and it only
embeds used glyphs. Same thing happens though if i embed the whole font (using
I have located the culprit in java\org\apache\fop\pdf\PDFFactory.java in
function createSubsetFontPrefix(), but as mentioned i'm unable to provide a
I have found this as a related issue.
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.