Comment 11 for bug 199689

I thought this might be a bug in Ghostscript, which generated the above PDF ( http://launchpadlibrarian.net/25800877/test3.pdf ) so I filed the problem as a bug with Ghostscript. According to Ken Sharp's reply to my bug, it seems to be a non-standard encoding problem with the font, see below:

---------
http://bugs.ghostscript.com/show_bug.cgi?id=690440
<email address hidden> changed:

Status: RESOLVED
Resolution: INVALID

------- Additional Comments From <email address hidden> 2009-04-21 10:50 -------
The font in question is a TrueType font embedded as a subset without a ToUnicode
CMap, and using a custom encoding. For example /Y (capital Y) is encoded at
position 1. In addition the glyph names in the encoding are not what one would
expect, I would expect to see /F, /i /r, /s, /t and so on. Instead I see /Y /bar
/Udieresis /aacute etc.

So there is no Unicode information, and the encoding is non standard. In this
case Acrobat falls back to translating the glyph names into their ASCII
equivalents (when possible). Using the Encoding to map from the character codes
to the glyph names we see that we get /Y /bar /Udieresis /aacute /agrave /space
/aacute /t and so on, which matches what you get when you copy and paste.

Its impossible to tell from the PDF file why the file was created this way, one
would have to guess that the file was created from a PostScript file which had
re-encoded the font like this, so that the PDF file had to be made the same way.

I don't see a bug here, possibly (given that the PDF file was created by GS
8.63) there is a bug in pdfwrite which caused the encoding oddness, btu that
can't be determined without seeing the PostScript file.
---