> > >> 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. >
Thanks. > PS: Have you seen my e-mail from Fri, 20 Jul 2018 11:21:36 +0200 > (CEST)? I've discussed some more bugs in your code... > Yes, I have. Two bugs or improvements are remaining, one is adding artificial glyphs and other is allocating bitmap values only on demand. My previously attempted solutions failed and I am working on it. I will solve them soon. Thank you Parth
_______________________________________________ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
