[
https://issues.apache.org/jira/browse/PDFBOX-2091?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14007028#comment-14007028
]
Andreas Lehmkühler commented on PDFBOX-2091:
--------------------------------------------
I don't want to splits hairs, but the whole implemented in line with the spec.
The issue is the font itself.
Let me explain why Jurajs patch just works by accident:
- the code is mapped to the charactername by using the font encoding
- the charactername is mapped to a code using the WinAnsiEncoding, in this case
it's the very same as used encoding for PDFont, which leads to the effect that
the first mapping is reverted
- the cmapWinSymbol is used to map the code to the glyphid
This is the very same which is done in the branch for symbol fonts.
IMHO we should detect such case and not just accidentily (the given case only
works because of the coincidence that the pdf and Jurajs patch are using the
same encoding) work around them.
> Some characters are not rendered (font with symbol encoding)
> ------------------------------------------------------------
>
> Key: PDFBOX-2091
> URL: https://issues.apache.org/jira/browse/PDFBOX-2091
> Project: PDFBox
> Issue Type: Bug
> Components: Rendering
> Affects Versions: 2.0.0
> Reporter: Juraj Lonc
> Attachments: PDFBOX-2091_TTFGlyph2D.diff, missing_yaccute.pdf,
> output.png
>
>
> Some characters are not rendered (see attached PDF).
> In this case it is "yaccute".
--
This message was sent by Atlassian JIRA
(v6.2#6252)
