encoding vectors: different ones returned from GS vs Adobe Distiller

[douglas mcallaster]

Folks,

The encoding vectors for fonts are different in Adobe and Ghostscript.
I ran this postscript on Adobe (Distiller) and then Ghostscript:
/LucidaBright 12 selectfont
currentfont
/FontName get =
currentfont
/Encoding get
dup
type =
{=} forall

Below are a couple of the many differences in the returned vector:
(1) bullet is not in the GS vector
(2) germandbls is in both vectors but in position 224 in GS and 252 in Abobe

I thougth the above postscript code would read the vector from the font itself.
Thus, I expected the same vector from either distiller and GS.

Is there a way to get the same vector?
Otherwise, using the (octal) position code to show a glyph will return different glyph if the postscript is run under GS verses Adobe Distiller.

Thx, Doug

[ken]

In article <cdc04d05-9855-40e1...@googlegroups.com>,
douglas.m...@gmail.com says...

>
> Folks,
>
> The encoding vectors for fonts are different in Adobe and Ghostscript.
> I ran this postscript on Adobe (Distiller) and then Ghostscript:
> /LucidaBright 12 selectfont
> currentfont
> /FontName get =
> currentfont
> /Encoding get
> dup
> type =
> {=} forall
>
> Below are a couple of the many differences in the returned vector:
> (1) bullet is not in the GS vector
> (2) germandbls is in both vectors but in position 224 in GS and 252 in Abobe

Which tells you that Adobe has used StandardEncoding and Ghostscript has
used ISOLatin1Encoding. Assuming the actual positions are decimal 223
and 251 that is, the first element in the Encoding array is 0.

According to the Latin character set, bullet is present in
StandardEncoding but not in ISOLatin1Encoding.

> I thougth the above postscript code would read the vector from the font itself.
> Thus, I expected the same vector from either distiller and GS.

There is no requirement that fonts should have a specific Encoding, if
you need a specific Encoding for a font then you are expected to apply
it yourself.

Beyond that, LucidaBright is not one of the base 35 fonts, so both
interpreters will be either:

1) Using a substitute font
or
2) Using a system font.

Exactly which will depend on the OS you are running and the fonts
installed, as well as how you have Ghostscript configured.

If they are using substitute fonts then they could easily be using
different substitutions (eg Helvetica instead of Courier).

One not unlikely scenario is that you are on Windows, Ghostscript has
been installed so that it can use the Windows/Fonts directory and
LucidaBright is available there as a TrueType font.

In that case both Ghostscript and Acrobat Distiller willl load the
TrueType font and return that.

But.....

PostScript doesn't permit the use of naked TrueType fonts, they should
be Type 42 fonts. In order to load a TT font both interpreters must
create the missing information which includes the Encoding vector. Since
there is no specification for loading a TT font, there is no defined way
this should be done.

So its no real surprise that they should differ.

> Is there a way to get the same vector?

Yes, encode the font the way you want it.

> Otherwise, using the (octal) position code to show a glyph will return different glyph if the postscript is run under GS verses Adobe Distiller.

You can validate the Encoding before you start, to see if it's what you
want. You can also check the CharStrings dictionary of the font to see
if it includes the glyphs you want and encode the font the way you want
it.

But you shouldn't really be using random fonts off disk. If you are
using a font other than the base 35 standard fonts then you should embed
the font in the PostScript program.

This is why PostScript programs generally contain the fonts they need.



Ken