What Nicolas quoted is everything and the packaging policy in Fedora is somewhat relevant to this though, other distros or individual may more or less has own fontconfig config per fonts perhaps. the idea is to reduce the cost of managing those files and the priority things. this would allows users to have the convenient way to have config files without understanding complicated syntax and to manage their own default fonts easily. On Wed, Oct 17, 2018 at 11:03 AM Jerry Casiano <jerrycasiano@xxxxxxxxx> wrote: > > A link to the previous discussion? which gives this some context would be appreciated. > > > > On Tue, Oct 16, 2018, 5:41 PM Nicolas Mailhot <nicolas.mailhot@xxxxxxxxxxx> wrote: >> >> Hi Akira, >> >> > The priority number of fontconfig config files in packages is >> > hardcoded at this moment. this requires huge works to update, >> > particularly when changing default fonts say (even though it won't so >> > often happens but still when fixing config files and updating for huge >> > packages etc). so I'm pondering to manage the priority in centralized >> > package and determine it at runtime, allowing users to have own >> > ordering. >> > >> > I don't have any implementations for this but just to share an idea >> > with you. >> >> It’s great you’re looking at improving things! fontconfig has served us >> well all those years. But there are really a lot more free and open >> fonts nowadays than when fontconfig config syntax and file layout was >> defined (which is wonderful!). So things are cracking a bit at the >> seams, and not only on your side. >> >> If I may give my opinion (CC-ing the fontconfig ML since I don't think >> any of this is Fedora-specific). Probably more than what you asked, but >> such is life ;) >> >> 1. fontconfig config syntax is too low level for the everyday needs of >> 2018. It was great when fonts on freedesktop systems were a small known >> pile of semi-broken files squirrelled away by xorg and texlive, it’s not >> so great to manage today’s huge numbers of standardized opentype files. >> The current syntax allows writing excruciately precise and accurate >> rules, except no human has the time to define those rules for every >> possible font file we deploy, so we get to write precisely things we are >> not so sure about. >> >> 2. so, this precise syntax should be kept to manage special cases, and >> something simpler and higher level should be introduced, with more >> things delegated to the fontconfig engine (like priorizing, as you >> rightly noted). Something like, process special precise rule in low- >> level fontconfig syntax first, then mass-process simplified high-level >> syntax. >> >> 3. the first higher level object should be a set-of-rules object, so >> ordering can be managed independently of file layout (basically you >> would order sets, regardless if the sets are each in their own file or >> share a single file, and regardless of the naming of those files. So >> stop shuffling and renaming files around to order things. >> >> 4. set ordering would be undefined and left to fontconfig by default, >> with one explicit human-maintained per-generic sets-that-must-go- >> first ordered list, and another per-generic sets-that-must-go-last list. >> And optional per-script overrides for those lists. Everything in between >> we don’t have the time and energy to order manually (and there’s no need >> to). >> >> 5. Of course, one copy of the lists in /usr/share/fontconfig for the >> system integrator, with an override in /etc for the sysadmin, and >> another override in .config for each user >> >> 6. IMHO to keep things manageable you should have one set = one font >> family (in the WWS sense, ie do not create as many sets as there are >> font family name variations, do not create separate sets for acmefont >> armenian and acmefont greek). We can extend font family definition to >> more things than just WWS when apps learn to manage more facets than >> just WWS for one font family, but at this point of time just doing WWS >> is taxing for the average app. Things like caption fonts, math fonts, >> etc should probably be merged with the WWS stuff eventually once we have >> more experience on handling those transparently in apps. >> >> 7. that does force fontconfig to manage high-level simplified and >> unified font family naming, instead of hoping font files will come with >> clean consistent naming (they don't and they won't, stop hoping for it, >> stop relying on fontconfig config writers to fix it, stop inflicting on >> users long lists of non-merged font names and expect them to jungle with >> the result, managing technical splits in font families is fontconfig's >> job not the user job, the user should only have to specify the design >> and the style he wants). >> >> 8. if there are several set definitions for the same font family at the >> same level of config (system integrator, sysadmin or user) just merge >> them transparently with undefined ordering rules when merging >> >> 9. if one set exists in several level, allow the override levels >> (sysadmin and user) to define in their set if they want it merged with >> lower levels or if they want it to replace the lower level definitions >> >> 10. The typical set should probably just define: >> * the generic the font family belongs to (what generic should be used >> to complete the font family, and what generic should ne constructed from >> the font family) >> * the list of known font families with similar design or metrics (so >> substitute this font family to those other font families if they are >> absent or lacking coverage, and conversely use those other font families >> to complete the font family if it lacks coverage). I really don’t think >> there is much benefit in ordering those manually. If there is some >> benefit, ordering should be an explicit attribute of the list, not the >> default. >> >> 11. Eventually, the set could also contain >> * an explicit list of internal hidden font families to map to this set >> (ie hide those font families from font lists, present only the unified >> clean name, manage internally in fontconfig which font file to use >> depending on what needs to be rendered) >> * the same thing, with also a face mapping, if face needs correction >> too >> * an explicit "use this internal font family for this script" to manage >> situations when there are regional variations on how to render an >> unicode codepoint >> >> 12. though I do hope opentype tables in shipped fonts get complete >> enough over time, and fontconfig gets smart enough over time, that all >> those mappings and overrides won’t need manual declaration long term. >> * IMHO fontconfig should map automatically by default everything >> defined in the WWS whitepaper, >> * and probably all the per-script/region/language common name >> variations >> >> 13. and since people will rightfully object that naming heuristics are >> not reliable and fail in some cases >> * allow defining a set with a property that basically says "do not >> merge me, I’m different" >> * make merging the default, and not-merging an explicit exception >> >> With just that you should be able to handle 90% of what people need to >> declare to fontconfig today (handwaves). And have something easy to >> order at system, sysadmin or user level. The 10% of very specific and >> complex configuration that does not fit in this simplified model, can be >> handled with the current syntax. It’s small enough in volume that I >> doubt its causes you lots of management problems. >> >> Best regards, >> >> -- >> Nicolas Mailhot >> >> _______________________________________________ >> Fontconfig mailing list >> Fontconfig@xxxxxxxxxxxxxxxxxxxxx >> https://lists.freedesktop.org/mailman/listinfo/fontconfig -- Akira TAGOH _______________________________________________ fonts mailing list -- fonts@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to fonts-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/fonts@xxxxxxxxxxxxxxxxxxxxxxx
