Bug #: 52477
           Summary: FOP always uses the same prefix for embeded font
           Product: Fop
           Version: all
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: major
          Priority: P2
         Component: pdf
    Classification: Unclassified

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 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 , 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\ in
function createSubsetFontPrefix(), but as mentioned i'm unable to provide a
I have found this as a related issue.

Configure bugmail:
------- You are receiving this mail because: -------
You are the assignee for the bug.

Reply via email to