Re: fontconfig priority management

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


Le 2018-10-17 13:43, Akira TAGOH a écrit :

On Wed, Oct 17, 2018 at 6:16 AM Nicolas Mailhot
<nicolas.mailhot@xxxxxxxxxxx> 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

[Index of Archives]     [Fedora Fonts]     [Fedora Users]     [Fedora Cloud]     [Kernel]     [Fedora Packaging]     [Fedora Desktop]     [PAM]     [Gimp Graphics Editor]     [Yosemite News]

  Powered by Linux