Re: fontconfig priority management

A link to the previous discussion? which gives this some context would be
appreciated.



On Tue, Oct 16, 2018, 5:41 PM Nicolas Mailhot <[email protected]>
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
> [email protected]
> https://lists.freedesktop.org/mailman/listinfo/fontconfig
>

_______________________________________________
Fontconfig mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/fontconfig