Hi all, I am unable to figure out the working of `FT_Face_InitFunc` in the `ftdrv.h` file. particularly, how does the call to `init_face` function invokes the particular font format's driver. Please help.
Regards Parth On Wed, Mar 7, 2018 at 9:23 PM, Parth Wazurkar <parthwazur...@gmail.com> wrote: > Ok > Seems like I messed up some things. > Thank you for the reply, now I have understood where I was going wrong. > I will work on that and get back soon. > > Thank You > Regards > Parth > > > On Wed, Mar 7, 2018 at 9:01 PM, Werner LEMBERG <w...@gnu.org> wrote: > >> >> > 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
