> > >> the next step is `attaching' a TFM file to GF (and later on to PK), > >> i.e., providing the internal code for `FT_Attach_File' and > >> `FT_Attach_Stream' so that GF's metric data gets completed. Any > >> estimate when you are done with this? > > > > I don't think that would be necessary, > > It is *absolutely* necessary. GF/TFM (and PK/TFM) are *always* to be > used in tandem! > > > as `Vflib' already switched from using a TFM file for `gf' and `pk' > > formats, and also `gftype' does not use a TFM file. So why do we > > need to implement this? > > As your `ftview' snapshot clearly demonstrates, GF fonts don't contain > metrics – the glyphs `jump' vertically. In particular, a glyph > normally has a height, a depth, and a typographic width. The GF data > does neither contain the height nor the depth; it only holds the bbox > and the width. Only with the TFM data you can align the glyphs > vertically to sit on the baseline. > > The GF fonts also lack some metadata like the slant of the font or the > width of a (normal) space. > > BTW, `gftype' is a GF dumper, nothing else; it doesn't show how to use > GF fonts correctly. >
> > `vf' fonts are required to use TFM files for metric information and > > I am going to implement the required functions for this. > > Please finish the GF + TFM combo first. > Ok, then I have a pretty clear idea about how to accomplish it, I will create some API functions in the `tfm' driver's service code which will be used in the `gf', `pk' and `vf' drivers to extract the tfm data. I have some doubts, I have already filled all the data in `FT_Face' and `FT_Glyphslot' with the glyph data. I cannot understand which metric data is wrongly filled. Please help. Thank you Parth
_______________________________________________ Freetype-devel mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/freetype-devel
