[gs-bugs] [Bug 690764] VISCII fonts

bugzilla-daemon at ghostscript.com bugzilla-daemon at ghostscript.com
Tue Sep 21 09:49:15 UTC 2010


--- Comment #5 from Ken Sharp <ken.sharp at artifex.com> 2010-09-21 09:49:03 UTC ---
Created an attachment (id=6740)
 --> (http://bugs.ghostscript.com/attachment.cgi?id=6740)
partial font decode

I do not believe there is a real bug here. Before using a font in PostScript it
is necessary to first encode it, so that character codes map to the expected
glyphs. If you know in advance that a font is already encoded in a satisfactory
fashion, then this need not be done (eg the font has a /StandardEncoding).

However there is no specification for using TrueType fonts as replacements for
PostScript fonts (or use TrueType fonts natively in PostScript), since this is
not a feature of standard PostScript. So the first thing that should be done is
to encode the font suitably, this is not being done and is the basic reason for
the problem.

Ghostscript makes a 'best effort' attempt with these fonts. Taking VIArial as
an example. We decode the font's CMAP tables, and choose to use the Unicode
CMAP (its the best one of the three for us). Because PostScript only allows 256
glyphs in an Encoding, we can't use any positions in the CMAP that are beyond
0xFF, but its a good start.

In the attached file (tables.txt) is a breakdown of part of the font, this
shows that, according to the Unicode CMAP subtable, position 0x98 is not
encoded, and so we place a /.notdef in this position. Hence when character code
\230 (0x98) is used, we render a /.notdef glyph. 

This all appears to be correct and as expected.

Moving on to the Acrobat output. Acrobat seems to be trying to encode more of
the glyphs. I have no idea what criteria it is using for this, as it seems to
have altered the glyph names when creating the embedded fonts. In addition,
when compared to the encoding given in the Wikipedia article in comment #4 I
can see that there are a number of glyphs not encoded, or not encoded in the
correct position, in the Acrobat output.

Checking the Acrobat output against the Wikipedia article we see that positions
2, 5 and 6 should have glyphs. The Ghostscript output does (though position 2
makes no marks), the Distiller output does not. Position 0x80 is not encoded in
the Distiller output but is correctly encoded in the GS output. And so on.

In short *neither* output matches that given in the Wikipedia article and
therefore the Ghostscript output is not only not incorrect, its not even
sub-optimal compared to Acrobat.

This is not a bug, if you want to use these fonts in PostScript you must
correctly encode them for your intended encoding scheme before you attempt to
use them.

Configure bugmail: http://bugs.ghostscript.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

More information about the gs-bugs mailing list