Could fontconfig support the Composite Font Representation of ISO 14496-28? https://blogs.adobe.com/CCJKType/2012/04/cfr.html At Google, we’re considering to release CFR files for grouping the myriad of Noto fonts into a few families such as "Noto Sans", "Noto Serif", and "Noto Mono". The total number of glyphs exceeds 64K, so we cannot just ship Noto Sans etc. as one gigantic OpenType file. Instead, we need a mechanism for declaring a virtual font. CFR has the advantage of being standardized. However, as of June 2016, Apple is the only platform that implements CFR. But perhaps fontconfig could follow Apple in that regard? Anyhow, here’s a draft CFR file for Noto Sans, which might help to illustrate the CFR syntax: https://github.com/googlei18n/noto-fonts/issues/707#issuecomment-224503236 For downloading the official specification document (+errata) from ISO, search for "14496-28" on this page: http://standards.iso.org/ittf/PubliclyAvailableStandards/index.html — Sascha Brawer, sascha@brawer.ch / sascha@google.com
We have discussed a bit about CFR a few years ago and thought we've concluded we need FreeType's support as well: https://lists.freedesktop.org/archives/fontconfig/2012-July/004214.html https://lists.freedesktop.org/archives/fontconfig/2012-August/004238.html Maybe good to revisit this one but also need to talk about it with FreeType developers.
If you tell me in detail what you need I can think about an implementation :-)
Werner, it's quite simple... I'd expect freetype to deal with a CFR file directly and allow applications to use it with the minimal efforts. so FT_New_Face to open a CFR file as a single font and reflect the meta data in it to FT_Face regardless of what the original fonts has.
Hmm. First of all, the CFR format is XML, so I would need an XML parsing library as a new dependency. I'm not enthused... Second, an interface/hook to the file system of the OS is would be necessary, since the paths used in an CFR can be arbitrary URLs. Third, CFRs are aware of languages and scripts, while FreeType is completely agnostic to them. What I can imagine is that FreeType accepts CFRs, passing them immediately to other functions (which get registered as hooks) for parsing, resolving, etc. Since FreeType functions are not sufficient to handle languages and scripts we could use FreeType (driver or module) properties to control them, again implemented as hooks. Note that I'm bad at designing such interfaces, and I would be glad for assistance.
Right. similar to what I imagine to implement. so then fontconfig can use that hooks to address languages/scripts thing. let me think about it more later what is better and how we can do in both area to allow applications developers to use CFRs with the minimal efforts.
(In reply to Akira TAGOH from comment #3) > Werner, it's quite simple... I'd expect freetype to deal with a CFR file > directly and allow applications to use it with the minimal efforts. so > FT_New_Face to open a CFR file as a single font and reflect the meta data in > it to FT_Face regardless of what the original fonts has. That will, however, completely break shaping and other things. Many operations assume that each font face is a collection of tables. The "logical font" layer should be higher than FreeTypee IMO; ie. in fontconfig.
(In reply to Behdad Esfahbod from comment #6) > That will, however, completely break shaping and other things. Many > operations assume that each font face is a collection of tables. The > "logical font" layer should be higher than FreeTypee IMO; ie. in fontconfig. Well, I want to avoid adding a new API to use CFRs in applications as far as possible becausse that will makes a gap among them. just thought that it may be a good idea if we can use the existing APIs as a frontend and then do the actual work outside FreeType, rather than wrapping up FreeType's API in fontconfig or wherever we like.
How will yesterday release of FreeType 2.8 affect this bug? "CFF2 support and OpenType variation font handling is now complete" https://www.freetype.org/index.html#news
No change. Let's see what Akira or Behdad (or someone else) come up with.
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/fontconfig/fontconfig/issues/33.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.