Le mercredi 24 juillet 2019 à 14:37 +0200, Kevin Kofler a écrit : Hi, Kevin Thank you for taking the time to answer, > Nicolas Mailhot wrote: > > 2. fontconfig strives to hide all the legacy ways to designate > > different > > parts of this ideal font, and strives to expose a single "font" > > objet no > > matter what quirks exist in individual font files. We stop exposing > > lots > > of weird quirky bits right and left, that need manual assembling by > > users, or glue-ing with TEX macros. > > > > No foo variable, foo hebrew, foo narrow, foo caption, just a single > > foo > > with different available features (full variability or fixed states > > on > > the default axis, real upstream provided states or fakes generated > > by > > fontconfig at pango’s request[5], etc) > > While such a model sounds really nice in theory, especially if > missing > variants can be synthesized (e.g., automatic slanting to provide > italic > versions where no native one is available), I am worried about some > of the > practical implications: Those are all real problems, but not directly related to the proposal. The core of the proposal is agreeing to expose existing font file capabilities to apps and users in an uniform way, instead of blindly relaying whatever custom capability ID mix each font project came up with. >From an end-user point of view that manifests as applying uniform font naming conventions. But, that also has consequences on the way we structure fontconfig config files, on API design between font-using libs, where we split font packages, how we present them in software catalogs, etc It will not magically add missing coverage to font files. As you pointed out we already have fonts where narrow has less coverage than bold italic for example. We also have fonts were coverage regressed after updates (Cantarell dumped cyrillic some years ago for example; it sucked to have existing Russian documents using Cantarell). It will not magically add good font selectors to all apps. We’ve been shipping DejaVu Sans as one of our main font families for a dozen year at least and some apps have still not bothered with a font selector able to handle it. It will be surprising to humans, that expect everything to be neat and tidy. Things have not been neat and tidy for quite a long time fonts- side. It’s obscured by the naming mess in current fonts, if we fix the mess the un-tidiness will become obvious to everyone. Yet, breaking (bad) habits is sometimes necessary. People objected stridently to fontconfig, because it enabled substituting missing glyphs, and that was breaking their mental model. Now even Microsoft is doing it in Windows. Humans will just have to get used that, a clean convenient uniform naming, does not imply that the font file themselves are free of holes, that different faces of a font may have different coverage levels. We can fix the naming at the lib level we can not fix the coverage, except by substitution and interpolation. It’s no different from how migration to vector fonts was managed twenty years ago. Vector and bitmap fonts appeared the same in selectors. Vector fonts allowed selecting any size you wanted, bitmap fonts only a specific subset. While synthesis is an obvious next step (after all variable fonts are just interpolating internally between fixed points) it is not included in the proposal. The proposal is just to agree on a common exposition format, regardless of the mess original font files are, regardless of the mess the app- side of font handling is. If you want to be fancy you can decline the exposition format at several levels of tech (pretend everything is Postscript, with a single face per font, pretend everything is first- gen TrueType, with just Normal/Bold/Italic/Bold Italic, pretend variability does not exist, etc). That‘s for fontconfig maintainers to decide. (IMHO, it’s pretty pointless to add fake old-style naming APIs to fontconfig, apps that won't bother supporting new fonts, are not going to use new API calls, even to keep in the past.) Agreeing on a common exposition format, at the fontconfig level, means that interested apps target this format in their devs, instead of waiting for the font catalog to magically become coherent (it never has been and never will be). It means that users do not have to remember "I want to write in Syldavian script, in A font it’s included in “A Syldavian”, in B font it’s in “B not-Bordurian”, in C font it’s directly named C, except for last year’s C where it was stashed in C phantasyeuropean. And app X names them all some way, and app Y another way." With an uniform exposition format fontconfig collects all the A B and C fragments available and presents them as A B or C, hiding the mutable fragment names. If it is not handled at the fontconfig level, workarounds will start appearing at app or lib level. Or, we'll have more and more of proposals like “make variability work for noto in pango, let other fonts libs and apps fend for themselves”. And getting it all done right is years of work at all levels of the text stack. Some fonts will get fixed faster. Some apps and libs will take advantage of the result before others. Some wierd corner case will take a lot of time to get right (I think fontconfig is still adding bitmap-related quirks for example). But, it won’t get done faster if we don’t agree now on the end target. One thing the last decade convinced me of, it that neither font projects, nor apps, are going to handle us this target on a platter. It needs to be driven by fontconfig and integrators. Regards, -- Nicolas Mailhot _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
