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

[Sergey Babkin]

Werner LEMBERG wrote:
> 
> [I've CC'ed the devel list; the latest version of the ttf2pt1
> converter (TTF->PS) now contains FreeType support.]
> 
> > > May I ask that you give us a list of what you need, what disturbs
> > > you, what fails, etc.?
> >
> > One of the things that still fails is that FT_Glyph_Get_CBox()
> > ignores the flag FT_LOAD_NO_SCALE used when loading the glyph.  Also
> > apparently the fixed point arithmetic in it has a bug, shifting
> > right by extra 6 bits. So to get things properly scaled I have to
> > use
> >
> >   FT_Set_Char_Size(face,  0, face->units_per_EM<<6, 1<<6, 1<<6)
> >
> > (note that both point size and resolution are shifted by 6 bits).
> 
> It's a bug in the documentation (I've fixed it right now).  Here a
> small example how to get the CBox in FUnits:
> 
>   (void)FT_Init_FreeType(&library);
>   (void)FT_New_Face(library, "pala.ttf", 0, &face);
>   (void)FT_Load_Glyph(face, 788, FT_LOAD_NO_SCALE);
>   (void)FT_Get_Glyph(face->glyph, &glyph);
>   (void)FT_Glyph_Get_CBox(glyph, ft_glyph_bbox_unscaled, &cbox);
> 
> ft_glyph_bbox_pixels should only be used for scaled glyphs (this info
> is missing); for unscaled glyphs, 0 is the right value.  I've
> introduced a new enum `ft_glyph_bbox_unscaled = 0'.

Thanks, it worked. 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 Type1 loader by some reason finds the Unicode encoding
> > which just can't be in a plain Type1 font.
> 
> Please give more details.

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

I would suggest a simple heuristic: 

- if a font does contain an explicit encoding table and has no more than
256 glyphs in it then represent it as a Symbol encoding, with
code-to-glyph mapping done by this table.

- if a font does not have an explicit encoding table (i.e. it
uses ISOLatin1Encoding or AdobeStandardEncoding) then represent it
as a Unicode encoding, as is done now.

- if a font contains an explicit encoding table and over 256 glyphs
then list both Symbol and Unicode encodings for it, with Symbol
encoding listed first in the table.

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

-SB