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 > _______________________________________________ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel