[jira] [Comment Edited] (PDFBOX-2380) Glyphlist .properties are not ordered

["John Hewson (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/PDFBOX-2380?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14146498#comment-14146498 ] 

John Hewson edited comment on PDFBOX-2380 at 9/24/14 4:39 PM:
--------------------------------------------------------------

{quote}
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.
{quote}

True, but I have other glyphlist files which don't work with PDFBox because it doesn't use the standard format, so if we're implementing a new glyphlist loader it'd be far more convenient for it to read standard glyphlist files.

{quote}
On the contrary, PDFBOX-1665 explicitly creates a new format to get rid of the external dependencies.
{quote}

Fortunately we don't have to worry about that anymore, the Adobe glyphlist license is now more permissive, so we can use their files verbatim, here's the important bit:

{code}
# Redistribution and use in source and binary forms, with or
# without modification, are permitted provided that the
# following conditions are met:
#
# Redistributions of source code must retain the above
# copyright notice, this list of conditions and the following
# disclaimer.
#
# Redistributions in binary form must reproduce the above
# copyright notice, this list of conditions and the following
# disclaimer in the documentation and/or other materials
# provided with the distribution.
{code}


was (Author: jahewson):
{quote}
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.
{quote}

True, but I have other glyphlist files which don't work with PDFBox because it doesn't use the standard format, so if we're implementing a new glyphlist loader it'd be far more convenient for it to read standard glyphlist files.

Fortunately we don't have to worry about that anymore, the Adobe glyphlist license is now more permissive, so we can use their files verbatim, here's the important bit:

{code}
# Redistribution and use in source and binary forms, with or
# without modification, are permitted provided that the
# following conditions are met:
#
# Redistributions of source code must retain the above
# copyright notice, this list of conditions and the following
# disclaimer.
#
# Redistributions in binary form must reproduce the above
# copyright notice, this list of conditions and the following
# disclaimer in the documentation and/or other materials
# provided with the distribution.
{code}

> 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)