Re: [ttf2pt1-devel] Re: FreeType front-end in ttf2pt1 - a newsnapshot

[Werner LEMBERG]

> Still it seems that in scaled mode there is an extra right shift:
> when I played with scaled things, to get metrics in
> face->glyph->metrics right I had to use
> 
>  FT_Set_Char_Size(face,  0, face->units_per_EM, 1<<6, 1<<6)
> 
> (with only one shift left, and that seems to be what's expected
> according to the docs).

The third parameter of FT_Set_Char_Size() must be given in 26.6 format
(making it possible to have fractional point sizes), so the correct
thing would be

  FT_Set_Char_Size(face, 0, face->units_per_EM << 6, 1, 1)

> 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
preference.  BTW, platform 7 is an artificial value (invented for
FreeType) meaning `Adobe'.

> 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.

> I would suggest a simple heuristic [...]

Look into the files in the directory src/psnames.  We believe that
this module does already this job.

> > > 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
information shall be returned?  Some font formats have absolutely no
additional info, others have plenty of it...


    Werner