Re: [ft-devel] Contribution to freetype

[Werner LEMBERG]

>> 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).

Yes.

> 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.

Yes.

> 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.

Well, the idea is that such composite fonts *behave* like a single
font!  On an MS or Android box, such composite fonts are predefined,
using the system fonts.  On a GNU/Linux box, a small application or
script could set up composite fonts using the information delivered by
FontConfig.

Adding support to FreeType would immediately enable *all* applications
to handle them without changes.  What should a higher level do in your
opinion?


    Werner