[
https://issues.apache.org/jira/browse/FOP-3087?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18011718#comment-18011718
]
Julian Müller commented on FOP-3087:
------------------------------------
I can still easily replicate this with FOP 2.11 and JDK 8 or 21: I set the font
to "Arial" for some text and Adobe Reader ends up substituting it with "Times
New Roman" (because the font is missing).
I also searched your issue tracker now and there at least two other tickets
reporting the same problem: FOP-2983, FOP-2896. (I don't know why I missed
these other reports when I opened the ticket, I usually check for existing
reports before opening a new one.) And the analysis in all of these issues is
that the logic in PDFAbstractTranscoder.getEffectiveConfiguration() is just
broken, which becomes very obvious simply by stepping through this method with
a debugger because the "auto-detect" key in the generated configuration ends up
missing.
> PDFTranscoder fails to auto-detect system fonts by default
> ----------------------------------------------------------
>
> Key: FOP-3087
> URL: https://issues.apache.org/jira/browse/FOP-3087
> Project: FOP
> Issue Type: Bug
> Affects Versions: 2.5, 2.4, 2.6, 2.7
> Reporter: Julian Müller
> Priority: Minor
>
> Contrary to the documentation, the PDFTranscoder fails to auto-detect system
> fonts by default, and also does not honor transcoding hint KEY_AUTO_FONTS =
> true.
> This is because the implicitly built configuration is not set up correctly.
> Line 163
> {code:java}
> c.addChild(fonts); {code}
> in AbstractFOPTranscoder needs to be moved after line 165, which is
> {code:java}
> fonts.addChild(autodetect); {code}
>
> A simple workaround to this problem is to explicitly pass a correctly set up
> configuration to PDFTranscoder, however, it would be preferable if
> PDFTranscoder would just honor its contract.
> I think this bug was introduced by FOP-2733, due to a subtle difference in
> Avalon's configuration package and its replacement. Avalon's configuration
> package allowed the addition of children in any order, but the new FOP
> configuration package adds copies instead of the original children, so the
> configuration tree needs to be built from the leaves to the root node.
> Currently, the code in AbstractFOPTranscoder does not follow this new
> requirement and instead builds the configuration tree from the root to the
> leaf.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
