DevHeads.net

target font model on Freedesktop systems

Hi,

Now that things are starting to move fonts-side[1], I’d like the various
actors to agree on a common font model target.

Without a a common target, we’ll end up working at odds with one
another. Upstream font files can not serve as a an officious target.
They are full of quirks, you end up with a different model per file-set.

My understanding of the state of the art is that OpenType is now
hegemonic. So it’s useless to target anything not specified in OpenType
specs. The latest OpenType enhancement is variable fonts.

Therefore, I’d like to propose that the target font model on freedesktop
systems, is the functional unit defined in variable fonts[2]:

That’s pretty much the same thing as WWS fonts as OpenType defined them
10 years ago, with optical size added. Add optical size is not intended
to be exposed in font selectors, it’s supposed to be auto-applied by
apps at need. I hoped we could ignore it at first, but we already have
things like PT Sans caption in Fedora.

Practical consequences of agreeing on a common model:

1. the unit of deployment (in rpm packages and software catalogs)
becomes all the files contributing to such an ideal font[4]

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)

3. the API between fontconfig and pango manipulates this kind of unit

4. the thing that end up in font selectors is also this unit.

Is this something we can agree on?

If we continue to special-case complex fonts like Noto, and bolt on
features without any form of master plan, I fear we’ll never get
anywhere.

If the agreement exists, can it be traced in a short fontconfig
document, that serves as coordinating references?

Regards,

[1] <a href="https://fedoraproject.org/wiki/Changes/VariableNotoFonts" title="https://fedoraproject.org/wiki/Changes/VariableNotoFonts">https://fedoraproject.org/wiki/Changes/VariableNotoFonts</a>

[2]
<a href="https://developer.microsoft.com/en-us/microsoft-edge/testdrive/demos/variable-fonts/" title="https://developer.microsoft.com/en-us/microsoft-edge/testdrive/demos/variable-fonts/">https://developer.microsoft.com/en-us/microsoft-edge/testdrive/demos/var...</a>
<a href="https://docs.microsoft.com/en-us/typography/opentype/spec/dvaraxisreg" title="https://docs.microsoft.com/en-us/typography/opentype/spec/dvaraxisreg">https://docs.microsoft.com/en-us/typography/opentype/spec/dvaraxisreg</a>

[4]
<a href="https://pagure.io/fork/nim/packaging-committee/commits/fonts-rpm-macros" title="https://pagure.io/fork/nim/packaging-committee/commits/fonts-rpm-macros">https://pagure.io/fork/nim/packaging-committee/commits/fonts-rpm-macros</a>
<a href="https://pagure.io/fork/nim/fonts-rpm-macros" title="https://pagure.io/fork/nim/fonts-rpm-macros">https://pagure.io/fork/nim/fonts-rpm-macros</a>
<a href="https://copr.fedorainfracloud.org/coprs/nim/fonts-rpm-macros/builds/" title="https://copr.fedorainfracloud.org/coprs/nim/fonts-rpm-macros/builds/">https://copr.fedorainfracloud.org/coprs/nim/fonts-rpm-macros/builds/</a>
<a href="https://copr.fedorainfracloud.org/coprs/nim/fonts-rpm-macros-noreg/builds/" title="https://copr.fedorainfracloud.org/coprs/nim/fonts-rpm-macros-noreg/builds/">https://copr.fedorainfracloud.org/coprs/nim/fonts-rpm-macros-noreg/builds/</a>

[5]
<a href="https://lists.freedesktop.org/archives/fontconfig/2019-June/006546.html" title="https://lists.freedesktop.org/archives/fontconfig/2019-June/006546.html">https://lists.freedesktop.org/archives/fontconfig/2019-June/006546.html</a>

Comments

Re: target font model on Freedesktop systems

By Kevin Kofler at 07/24/2019 - 08:37

Nicolas Mailhot wrote:
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

Re: target font model on Freedesktop systems

By Vitaly Zaitsev ... at 07/24/2019 - 14:40

Le mercredi 24 juillet 2019 à 14:37 +0200, Kevin Kofler a écrit :

Hi, Kevin

Thank you for taking the time to answer,

Those are all real problems, but not directly related to the proposal.

The core of the proposal is agreeing to expose existing font file
capabilities to apps and users in an uniform way, instead of blindly
relaying whatever custom capability ID mix each font project came up
with.

From an end-user point of view that manifests as applying uniform font
naming conventions. But, that also has consequences on the way we
structure fontconfig config files, on API design between font-using
libs, where we split font packages, how we present them in software
catalogs, etc

It will not magically add missing coverage to font files. As you
pointed out we already have fonts where narrow has less coverage than
bold italic for example. We also have fonts were coverage regressed
after updates (Cantarell dumped cyrillic some years ago for example; it
sucked to have existing Russian documents using Cantarell).

It will not magically add good font selectors to all apps. We’ve been
shipping DejaVu Sans as one of our main font families for a dozen year
at least and some apps have still not bothered with a font selector
able to handle it.

It will be surprising to humans, that expect everything to be neat and
tidy. Things have not been neat and tidy for quite a long time fonts-
side. It’s obscured by the naming mess in current fonts, if we fix the
mess the un-tidiness will become obvious to everyone.

Yet, breaking (bad) habits is sometimes necessary. People objected
stridently to fontconfig, because it enabled substituting missing
glyphs, and that was breaking their mental model. Now even Microsoft is
doing it in Windows.

Humans will just have to get used that, a clean convenient uniform
naming, does not imply that the font file themselves are free of holes,
that different faces of a font may have different coverage levels. We
can fix the naming at the lib level we can not fix the coverage, except
by substitution and interpolation. It’s no different from how migration
to vector fonts was managed twenty years ago. Vector and bitmap fonts
appeared the same in selectors. Vector fonts allowed selecting any size
you wanted, bitmap fonts only a specific subset.

While synthesis is an obvious next step (after all variable fonts are
just interpolating internally between fixed points) it is not included
in the proposal.

The proposal is just to agree on a common exposition format, regardless
of the mess original font files are, regardless of the mess the app-
side of font handling is. If you want to be fancy you can decline the
exposition format at several levels of tech (pretend everything is
Postscript, with a single face per font, pretend everything is first-
gen TrueType, with just Normal/Bold/Italic/Bold Italic, pretend
variability does not exist, etc). That‘s for fontconfig maintainers to
decide. (IMHO, it’s pretty pointless to add fake old-style naming APIs
to fontconfig, apps that won't bother supporting new fonts, are not
going to use new API calls, even to keep in the past.)

Agreeing on a common exposition format, at the fontconfig level, means
that interested apps target this format in their devs, instead of
waiting for the font catalog to magically become coherent (it never has
been and never will be).

It means that users do not have to remember "I want to write in
Syldavian script, in A font it’s included in “A Syldavian”, in B font
it’s in “B not-Bordurian”, in C font it’s directly named C, except for
last year’s C where it was stashed in C phantasyeuropean. And app X
names them all some way, and app Y another way."

With an uniform exposition format fontconfig collects all the A B and C
fragments available and presents them as A B or C, hiding the mutable
fragment names.

If it is not handled at the fontconfig level, workarounds will start
appearing at app or lib level. Or, we'll have more and more of
proposals like “make variability work for noto in pango, let other
fonts libs and apps fend for themselves”.

And getting it all done right is years of work at all levels of the
text stack. Some fonts will get fixed faster. Some apps and libs will
take advantage of the result before others. Some wierd corner case will
take a lot of time to get right (I think fontconfig is still adding
bitmap-related quirks for example).

But, it won’t get done faster if we don’t agree now on the end target.

One thing the last decade convinced me of, it that neither font
projects, nor apps, are going to handle us this target on a platter. It
needs to be driven by fontconfig and integrators.

Regards,

Re: target font model on Freedesktop systems

By Dominik 'Rathan... at 07/24/2019 - 08:13

On Tuesday, 23 July 2019 at 15:45, Nicolas Mailhot via devel wrote:
I am no font expert, but the above sounds reasonable to me.
I maintain just one font package, though.

Regards,
Dominik