> > >> 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. >> > >> > 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. >> >> Check the `T1_Read_Metrics' files as described in my previous e-mail >> and look up the used interface calls. Start with a `tfm_module_class' >> (modelled after `psaux_module_class') and set up a module-specific >> `tfm_interface' (modelled after `psaux_interface'), which collects all >> necessary functions to parse a TFM. I can imagine that you need, say, >> >> tfm_open >> tfm_read >> tfm_parse_metrics >> tfm_parse_kerns >> tfm_close >> >> In the GF module, you have to define a function for the `attach_file' >> interface (modelled after `T1_Read_Metrics') which in turn checks that >> the TFM module interface is available, and which then calls the >> necessary functions to handle a TFM file.[...] > > I found out `T1_CONFIG_OPTION_NO_AFM' option, should we have such an option like `TEX_CONFIG_OPTION_NO_TFM' for our tfm driver? What do you suggest.
Thank you Parth
_______________________________________________ Freetype-devel mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/freetype-devel
