[
https://issues.apache.org/jira/browse/PDFBOX-5785?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17827405#comment-17827405
]
Andreas Lehmkühler commented on PDFBOX-5785:
--------------------------------------------
In 3.0 the font parser changes so that the descendant font maybe either a TTF
or an OTF. In 2.0 it is always an OTF. That explains the regression with my
first version of the patch for 2.0.
However, I've changed the implementation for 3.0 and the trunk according to the
code in 2.0
> Issue with embedded Font and descendant Font
> --------------------------------------------
>
> Key: PDFBOX-5785
> URL: https://issues.apache.org/jira/browse/PDFBOX-5785
> Project: PDFBox
> Issue Type: Bug
> Components: Rendering
> Affects Versions: 2.0.30, 3.0.1 PDFBox
> Reporter: Oliver Schmidtmer
> Assignee: Andreas Lehmkühler
> Priority: Major
> Labels: regression
> Fix For: 2.0.31, 4.0.0, 3.0.3 PDFBox
>
> Attachments: 1 (3).pdf, Renfer_Beleg_ueber_SFr_1000.pdf,
> image-2024-03-13-18-01-57-168.png, image-2024-03-13-18-04-49-957.png,
> image-2024-03-13-21-06-01-596.png
>
>
> On the attached PDF, a text where the second font is used cannot be rendered:
> !image-2024-03-13-18-01-57-168.png|width=547,height=60!
> From debugging I can see, that PDType0Font.codeToGID(code) does return "0"
> for this chars.
> The call there is delegated to descendantFont.codeToGID(code).
> However at least for code to unicode, the map is in the font itself, not the
> descendant:
> !image-2024-03-13-18-04-49-957.png|width=500,height=213!
> The font view in the PDF Debugger also shows codes from 1 to 7, instead of
> those from the unicode map.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
