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)