[
https://issues.apache.org/jira/browse/PDFBOX-4017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16822717#comment-16822717
]
Tilman Hausherr edited comment on PDFBOX-4017 at 4/21/19 3:43 PM:
------------------------------------------------------------------
Omega is glyphid 58 (uniF057). But the problem is that for omega, the method
should somehow return unif057 instead of uni0057. The number returned by the
inverted map would be a low number again.
Anyway, I looked at the whole thing again. I had opened this issue two years
ago, gave up, hoped that other people would notice the problem and maybe bring
a solution, but seems that nobody has windows 10 or nobody cares. Today I used
the PDF code {{getEncoding().getNameToCodeMap().get(name)}} which I think is
also what you mentioned and add F000 to it and then prepend "uni", and it works
somewhat better, but still not perfect. Then I used
{{SymbolEncoding.INSTANCE.getNameToCodeMap().get(name)}} and it got better.
Still some differences left, but this could be because of different computers
(different fonts).
was (Author: tilman):
Omega is glyphid 58 (uniF057). But the problem is that for omega, the method
should somehow return unif057 instead of uni0057. The number returned by the
inverted map would be a low number again.
Anyway, I looked at the whole thing again. I had opened this issue two years
ago, gave up, hoped that other people would notice the problem and maybe bring
a solution, but seems that nobody has has windows 10 or nobody cares. Today I
used the PDF code {{getEncoding().getNameToCodeMap().get(name)}} which I think
is also what you mentioned and add F000 to it and then prepend "uni", and it
works somewhat better, but still not perfect. Then I used
{{SymbolEncoding.INSTANCE.getNameToCodeMap().get(name)}} and it got better.
Still some differences left, but this could be because of different computers
(different fonts).
> Symbol font glyphs not found on Windows 10 fall creators update
> ---------------------------------------------------------------
>
> Key: PDFBOX-4017
> URL: https://issues.apache.org/jira/browse/PDFBOX-4017
> Project: PDFBox
> Issue Type: Bug
> Components: FontBox, Rendering
> Affects Versions: 2.0.8
> Environment: Windows 10 fall creators update
> Reporter: Tilman Hausherr
> Priority: Major
> Attachments: symbol.ttf, test.pdf
>
>
> Since the Windows 10 fall creators update all files with the Symbol standard
> 14 font are no longer rendered properly. Seems to have something to do with a
> difference in the cmap subtable (all numbers start with F000) and a missing
> postscript table.
> The font has two cmap subtables. The first one has codes that start with 0,
> the second one has codes that start with 0xF000. The code names we get from
> {{getUniNameOfCodePoint(unicodes.codePointAt(0))}} are NOT the low ones, only
> some match, those that are also in ascii.
> For ">", there are two cmap subtables codes: for "Macintosh, Roman" it is
> 0x3e, for "Microsoft, Symbol" it is 0xf03e. I tried forcing the first table
> {{code}}
> cmap = cmapTable.getSubtable(CmapTable.PLATFORM_MACINTOSH, 0);
> {{code}}
> but many codes are missing, e.g. the greek alphabet.
> For "eta" (looks like an "n")
> pdf code 0150 = 0x68
> unicode 0x3b7
> windows code in charmap.exe: 68
> code in subtables: 0x68 and 0xf068
> lozenge
> unicode 0x25ca
> pdf code 0340 = 0xe0
> code in subtables: 0x0e and 0xf0e0
> So it seems one has to bypass this unicode thing and work directly with the
> symbol encoding...
> Websites:
> https://www.microsoft.com/typography/otspec/cmap.htm#windowsPlatform
> https://developer.apple.com/fonts/TrueType-Reference-Manual/RM06/Chap6cmap.html
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
