[Fontconfig] [RFC] target font model on Freedesktop systems

[Nicolas Mailhot]

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]:

> Things, that share a common design, and vary only in
> — Optical size
> — Slant (Italic axis is some weird legacy way to specify Slant in 
> another way)
> — Width
> — Weight

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] https://fedoraproject.org/wiki/Changes/VariableNotoFonts

[2]
https://developer.microsoft.com/en-us/microsoft-edge/testdrive/demos/variable-fonts/
https://docs.microsoft.com/en-us/typography/opentype/spec/dvaraxisreg

[4]
https://pagure.io/fork/nim/packaging-committee/commits/fonts-rpm-macros
https://pagure.io/fork/nim/fonts-rpm-macros
https://copr.fedorainfracloud.org/coprs/nim/fonts-rpm-macros/builds/
https://copr.fedorainfracloud.org/coprs/nim/fonts-rpm-macros-noreg/builds/

[5]
https://lists.freedesktop.org/archives/fontconfig/2019-June/006546.html

-- 
Nicolas Mailhot