Re: fontconfig priority management

Le 2018-10-17 13:43, Akira TAGOH a écrit :
> Hi,
> 
> On Wed, Oct 17, 2018 at 6:16 AM Nicolas Mailhot
> <[email protected]> wrote:
>> 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 ;)
> 
> Sure. well, this should eventually be merged and maintained in
> fontconfig upstream though, I have to research what the sort of config
> other distros uses and can be templated in general. so just thought
> starting on Fedora as pilot program would be good start, but anyway.
> more feedbacks from the wider audience would be great.

You seem to be thinking about generating current fontconfig syntax from 
templates in rpm macros. I definitively don't want to go there in Fedora 
font packages. Such generators are quite brittle and hell to 
debug/maintain. They're sort of ok for third party tools that try to 
coax fontconfig on doing things, they're not ok as distro core 
infrastructure. If you want to generate from rpm macros, you need to 
define something that can be generated simply (and current fontconfig 
syntax is not that).

If we agree on some form of simplified syntax, sufficient for the needs 
of the average font packager, I want the result to be read by fontconfig 
natively without intermediary generation. Even if it's in an 
experimental config namespace only activated on Fedora, that we agree 
can be dropped later if the experiment fails.

> For individuals, majority requirements should be satisfied by a tool
> such as fonts-tweak-tool. for system-wide and complicated scenarios,
> we need a handy way to get things done. for Fedora specific thing, I
> eventually want to integrate this into rpm macro and prepare an
> environment to have config files without any knowledge or minimal.
> that would helps a lot for packagers.

Well I wrote down what I though minimal knowledge could be: identifying 
the generic (that's definitely something a human can do better than 
fontconfig), listing down font families that the font family can serve 
as substitute for/can be substituted with (fontconfig can not have any 
opinion on fonts families not present on system) and listing down all 
the font family name variations that should be merged, if fontconfig is 
not smart enough to identify them itself.

The merging part is hugely important from a usability POW, because the 
OFL has created a situation where forks lead to renames, and because 
font designers suck at font naming.

They will rename every possible variation of their fonts so they can 
wash their hands on metric compatibility, or just for marketing purposes 
(acmefont new better), or to enable subsetting, or to sell a pro 
version, but the average user is not going the have every possible font 
variation on his system.

So it's much better to present all the variations on acmefont as a 
single acmefont font family, and have fontconfig manage internally those 
variants, than have fontconfig fallback to an unrelated font, because 
the original document didn't use the same variant as the current system. 
These days displaying all acmefont family names in selectors is about as 
useful as displaying the font version embedded in the font files. Sure 
it allows disambiguation. But who except the original font designer 
cares about this? If you have the exact match on-system for one of the 
font other names, by all means have fontconfig return data from this 
file, but don't force users to do the untangling manually. They don't 
care enough to do it. They will just (rightly) say fontconfig font 
selection sucks.

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