[RFC] target font model on Freedesktop systems

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

 



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
_______________________________________________
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




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux