Le 2018-10-17 13:43, Akira TAGOH a écrit :
Hi,
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
Fontconfig@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/fontconfig
