> > >> Please have a look how AFM files are attached to Type 1 fonts; it > >> basically does the same, namely to add more metric information. I > >> suggest that you use this as a template. > > > > If we use this as a template, then there is no need to have a > > separate TFM driver, as VFlib's TFM driver only provides functions > > to extract the TFM metric data for the `vf' format, which we can > > constitute like in the `afm' files. > > A separate TFM module makes sense IMHO, since exactly the same code > will be used for the PK module also. And VF will need this, too. > Compare this to the `psaux' module which provides routines for CFF, > Type1, Type42, and CID fonts. >
Yes. Can you please tell me which files should I look upon in the `psaux' module to get an understanding of its structure so that the `tfm' module can be constructed on its lines. > The AFM code handling is restricted to Type1 fonts; it thus doesn't > make sense to have a separate module. > Ok. > > Although, this driver computes some glyph metric data using this tfm > > data, which essentially draws some glyph only having bounding box. > > I am confused like if we proceed with the `afm' style should there > > be TFM driver or not? > > Well, the TFM driver will be a *passive* module, similar to the AFM > handling code. This means that it won't be called in the loop that > tries to find out an input font's file format; instead, it becomes > only active if a TFM gets attached to a GF or PK file. > Yes Indeed! This will be another auxiliary module which will facilitate the `gf', `pk' and `vf' formats. > The job of the TFM module is to parse a TFM file and to fill metrics > and/or kerning structures (cf. `T1_Read_Metrics', lines 266-282). If > everything's OK, it will overwrite and/or add data to `GF_Face' or > `PK_Face' (cf. `T1_Read_Metrics', lines 296-316). > > Does this help? Yes. Thanks. Parth
_______________________________________________ Freetype-devel mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/freetype-devel
