You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@pdfbox.apache.org by "Andreas Lehmkühler (JIRA)" <ji...@apache.org> on 2014/09/24 10:30:34 UTC
[jira] [Commented] (PDFBOX-2380) Glyphlist .properties are not
ordered
[ https://issues.apache.org/jira/browse/PDFBOX-2380?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14146058#comment-14146058 ]
Andreas Lehmkühler commented on PDFBOX-2380:
--------------------------------------------
Obviously we have to implement our own reader to store the data as needed and we don't have to change the delimiter to do so. On the contrary, PDFBOX-1665 explicitly creates a new format to get rid of the external dependencies.
> Glyphlist .properties are not ordered
> -------------------------------------
>
> Key: PDFBOX-2380
> URL: https://issues.apache.org/jira/browse/PDFBOX-2380
> Project: PDFBox
> Issue Type: Bug
> Affects Versions: 2.0.0
> Reporter: John Hewson
> Assignee: John Hewson
>
> Currently we use .properties files to load the glyph lists, however Java's Properties is not ordered (the properties are stored in a Hashtable) and so the glyphs are not read in the correct order.
> This results in incorrect encoding when calling GlyphList.unicodeToName(), because the Adobe glyph lists are ordered: the default mapping comes first, and auxiliary mappings follow it, for example:
> {code}
> space=0020
> spacehackarabic=0020
> {code}
> Currently in PDFBox, GlyphList.unicodeToName(0x20) returns "spacehackarabic", which is wrong, we always want the first entry in the glyph list.
> We need to move away from using .properties and instead just use Adobe's existing glyph list format, the only difference is that we switch {{=}} for {{;}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)