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: Nikolay Sivov
Subject: Re: [ft-devel] Contribution to freetype
Date: Sun, 18 Mar 2018 10:36:10 +0300
User-agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:59.0) Gecko/20100101 Thunderbird/59.0

On 3/18/2018 10:25 AM, Werner LEMBERG wrote:
> 
>>> The difficulty is not adding support for the VF format itself but
>>> to find a good API that is generic enough for other purposes, too.
>>> I'm thinking of handling files like Microsoft's
>>> `GlobalSerif.CompositeFont'.  Apple and Android provide similar
>>> concepts.  It's probably not the job of FreeType to digest such
>>> composite fonts by itself (you'll need an external XML
>>> interpreter); however, it would be very helpful if we have a
>>> foundation to provide easy support for such composite fonts.
>>
>> Could you elaborate?  I don't see how .CompositeFont files are
>> related to FreeType mission.  They are not fonts, and have no font
>> data, but only define {range, locale} -> {family} mapping.
> 
> Technically, they are not fonts, but practically they are.  It's not
> much different to, say, a CFF that consists of a bunch of subfonts.

Okay, I guess I'll have to wait and see when this is implemented. My
understanding is that it's a way to define mapping for existing fonts,
so you still need all referenced font data (which is referenced by NAME
names by the way). If e.g. you filter all duplicate entries out, and use
resulting font array, it will have no additional information comparing
to individual font files. If freetype decided to do a "smarter" mapping,
or a fallback rather, using language/codepoint pairs, that's a different
thing that sounds higher level, and not fitting to existing API. But
again, I'm just curious that's all.

> 
> 
>     Werner
> 




reply via email to

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