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.
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.
Freetype-devel mailing list