Nicolas Mailhot wrote:
> 2. fontconfig strives to hide all the legacy ways to designate different
> parts of this ideal font, and strives to expose a single "font" objet no
> matter what quirks exist in individual font files. We stop exposing lots
> of weird quirky bits right and left, that need manual assembling by
> users, or glue-ing with TEX macros.
>
> No foo variable, foo hebrew, foo narrow, foo caption, just a single foo
> with different available features (full variability or fixed states on
> the default axis, real upstream provided states or fakes generated by
> fontconfig at pango’s request[5], etc)
While such a model sounds really nice in theory, especially if missing
variants can be synthesized (e.g., automatic slanting to provide italic
versions where no native one is available), I am worried about some of the
practical implications:
* There is no longer a way to filter only for native high-quality variants,
excluding synthesized ones. Or in particular, to just request a bold,
thin, wide, narrow, or italic version of a font without caring about
(e.g.) how thick the bold version actually is, but preferring a native
variant over a synthesized one with some arbitrary thickness.
* The native variant may only support a subset of the characters of the base
font. See, e.g., Liberation Sans Narrow, which is stuck at an older
version because it is not part of the upstream "code" drop used as the
basis for the new version. With your approach, there is also no way to
explicitly force the use of the synthesized version. Will fontconfig or a
higher level be smart enough to synthesize from the base font characters
missing in the native variant but available in the base font?
* How will fontconfig decide which of the versions to pick as the base? If,
e.g., there is a Foo with 100% width and a Foo Narrow with 50% width,
which one would be picked for, say, Foo 71%? (Note that 71% is between the
geometric mean and the arithmetic mean of 100% and 50%.) Or, say, you have
a Foo with 100% width and a Foo Narrow with 80% width, and the user
requests Foo 160%, would the integer factor 2 from 80% to 160% potentially
lead to a better scaling? Or, say, the font provides only Foo Bold and Foo
Italic, and the user requests Foo Bold Italic, do you bolden Foo Italic or
slant Foo Bold, or even bolden and slant Foo Regular?
* I see you mentioning pango. What will happen for applications not using
pango? Qt applications come to my mind, obviously, but also applications
using neither GTK+ nor Qt (which include popular ones where fonts are
crucial, such as LibreOffice, where GTK+ and Qt support are only in
optional plugins).
* The font selectors also need to support all those settings. If an
application shows some legacy font selector that does not support them,
the user is stuck with no way to use the variants, whereas the current
approach of abusing the family name with suffixes does the job. E.g.,
Liberation Sans Narrow would just vanish from legacy applications with no
way for the user to select it.
So, to sum it up, I kinda like the idea, but I am very worried about
functionality regressions popping up in practice.
Kevin Kofler
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
