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