> I am thinking of some possible ways in providing multiple font > support,
What exactly do you mean with `multiple font support'? > first one can be to use the available converters for conversion of > font formats, the second one can be to use the Freetype approach by > modifying `FT_DRIVER_H`, `FT_OPEN_DRIVER` to support the tex font > drivers as well, another can be the VFlib approach i.e to define a > new font database file on the lines of vflibcap and then using the > Kpathsea library for searching TEX fonts. > > I ruled out the first one as we must convert many font files in > advance and also we don't have converters available for all types of > fonts. OK (but I don't know exactly to what it refers). > I am currently more inclined towards the VFlib approach. You mean something like `vflibcap'? I think this is the wrong approach. Please bear in mind that FreeType is a font rendering engine, working at the lowest level – actually, there is no other font-related library on a lower level (in a font stack that uses FreeType, that is). `vflibcap', for example, provides a much higher-level access to fonts; it handles kpathsea issues, encoding conversion files, etc., etc. All this stuff doesn't belong to FreeType. FreeType takes a font file, opens it, selects a glyph, and rasterizes it. That's it! And such low-level functions the GSoC project should provide. The exception is VF files, which probably needs a new interface: For example, a new function could return a list of the necessary `raw' fonts (in TeX speak). An alternative could be a callback function that receives a font name and returns a handle to FreeType. This is what a GSoC student should research. Werner _______________________________________________ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel