[
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:40 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}
You can find the full text at
http://superb-dca3.dl.sourceforge.net/project/aglfn.adobe/glyphlist.txt
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.
{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}
> 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)
