Re: [ttf2pt1-devel] Re: FreeType front-end in ttf2pt1 - anewsnapshot

[Sergey Babkin]

Werner LEMBERG wrote:
 
> > When I start looking through the table of encodings in
> > a Type1 (.pfa font) like this:
> >
> >     for(e=0; e < face->num_charmaps; e++) {
> >         fprintf(stderr, "found encoding pid=%d eid=%d\n",
> >             face->charmaps[e]->platform_id,
> >             face->charmaps[e]->encoding_id);
> >     }
> >
> > I find two tables:
> >
> > found encoding pid=3 eid=1
> > found encoding pid=7 eid=2
> >
> > I don't know what's the platform 7 but pid=3/eid=1 is Unicode.
> 
> You should rather use face->charmaps[e]->encoding which will return
> things like `ft_encoding_unicode' or `ft_encoding_adobe_expert'.
> Don't rely on the order of returned pid/eid values!  There is no

Ah, OK.

> preference.  BTW, platform 7 is an artificial value (invented for
> FreeType) meaning `Adobe'.

Thanks for information. It does not have any definition in the 
FreeType headers.
 
> > Well, I think I see the reason for using Unicode: if the font
> > contains more than 256 glyphs but the glyphs have proper names then
> > they may be mapped to Unicode.  But if the glyph names are strange
> > then this stuff does not work.  The thing that would work for fonts
> > with a customized encoding tables is the Symbol encoding, with
> > pid=3/eid=0.
> 
> The pair (7,2) is ft_encoding_adobe_custom, and this is exactly what
> you are asking for.
> 
> I'm in the process of revising the tutorials so that I can fix that.

Thanks, that would make things more clear.
 
> > I would suggest a simple heuristic [...]
> 
> Look into the files in the directory src/psnames.  We believe that
> this module does already this job.

Apparently it does, after you explained how to understand the 
data from it :-)
 
> > > > Also I think it would be good if some other typical variables
> > > > such as version string or copyright notice would be accessible
> > > > in a format-indepent way, without using *Sfnt*.
> > >
> > > Indeed.  The very question is whether FreeType should do that or a
> > > library on top of FreeType.
> >
> > Is not one of FreeType's goals placing all these various font
> > drivers under it and being an universal interface? Or am I missing
> > something?
> 
> You've probably misunderstood me.  The question is whether accessing
> this kind of info is low-level enough to be part of FreeType or
> whether it should be put (with a universal interface, of course) into
> a yet-to-be-written Text Layout engine.  Another problem is which

Yes, probably I'm missing something here.

> information shall be returned?  Some font formats have absolutely no
> additional info, others have plenty of it...

Why not make provisions for all the reasonable information, and then
if the font format does not support a particular variable just
return a special value "not available" ?

-SB