Re: [Devel] A new CFF encoding bug

[Werner LEMBERG]

> >Well, this font doesn't contain an encoding!  Most of the glyphs
> >can only be accessed by glyph names.
>
> But if there is no encodind available (i.e. custom encoding) we
> can't access glyphs by names either ?

As George has already stated, glyph names are stored separately.

> >Anyway, I've added support to recognize `uXXXX[X[X]]' glyph names so
> >that a few glyphs get proper entries in a synthesized Unicode charmap.

> I think that in this case there should be at least a custom encoding
> (in addition to an optional Unicode encoding).

Why?  What order shall I use?  The glyphs in the font are all
unencoded.  In the sample PDF file you've sent to me the glyphs are
(re)encoded anyway.

> I am right or wrong that a font (Type1, CFF) should always have at
> least a custom encoding.

You are wrong.  Similar to Type 1, a CFF font can contain only
unencoded glyphs: Either it has an /Encoding array which contains only
/.notdef (this is Type 1), or (as with your font) it denotes
AdobeStandardEncoding but without a single corresponding SID.

> >Note that the glyph names in the font are probably buggy too: There
> >are glyphs named like `u069' or `u064' -- it seems the last
> >character is missing.
>
> See http://partners.adobe.com/asn/developer/type/unicodegn.html for
> a detailed algorithm on how to map new glyph names to Unicode.

I know this very well.  Glyph names starting with `u' to denote a
Unicode character code must have at least four hexadecimal digits, not
three.  Consequently, FreeType doesn't include those glyphs into the
Unicode map.


    Werner