[jira] [Commented] (FOP-3087) PDFTranscoder fails to auto-detect system fonts by default

    [ 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)