freetype-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [ft-devel] Contribution to freetype


From: Parth Wazurkar
Subject: Re: [ft-devel] Contribution to freetype
Date: Fri, 16 Mar 2018 04:50:59 +0530

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 <address@hidden> 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 <address@hidden> 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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]