Re: [Fontconfig] [RFC] target font model on Freedesktop systems
by Nicolas Mailhot
Le 2019-07-24 13:49, Akira TAGOH a écrit :
Hi Akira
> On Tue, Jul 23, 2019 at 10:45 PM Nicolas Mailhot
> <nicolas.mailhot(a)laposte.net> wrote:
>> 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)
>
> Such family name issue should be more likely a font issue. it could be
> worked around but there are a lot of patterns to drop such things
> heuristically and that may be huge costs to be automated; well, that
> may depends what the level of support you expect on it.
> Having something more or less would be useful though, I hope some
> moves happens in fonts side for that too.
I've given up on font creators cleaning up their mess. Microsoft and
Adobe have been trying for a decade to get them to adopt common
conventions, and they continue not fixing old projects, and diverging
randomly on new projects. Each font tooling author and each font creator
thinks he knows best.
If we agree that this OpenType theorical definition is our target to
enable freedesktop apps to do interesting text things, the logical
consequence is to perform naming fixing at the fontconfig level (and
make sure text libs like Pango do not re-expose accidentally the
upstream broken naming to apps).
Fixing at the fontconfig level means lots of naming heuristics (that
you've started working on thank you very much). But, an heuristic is not
a 100% solution by definition. So we’ll also need you help to define the
fontconfig grammar, to tell fontconfig things, it can not guess alone.
This is also linked to Peng Wu’s request for an API to tell fontconfig
what faces to fake using variable font axis. Because:
– such faking needs to persist on disk to be convenient
— the persisting needs to be done fontconfig-side, otherwise the faked
faces are not shared with apps that do not use pango
— the next logical step is to preset convenient faked faces directly in
the font package, so you don't need to redo-them in a GUI on all the
computers one uses
So what Peng Wu sees as a fontconfig API need, I see as a fontconfig
config file need.
Also, once variable fonts become more common, I'm sure everyone will get
sick of faking the same font faces in all variable fonts, so someone is
bound to ask for a generic fontconfig heuristic, that takes available
axes, and auto-segment them at useful points (probably, using all the
segmentation levels defined by Microsoft in the WWS whitepaper)
That’s why I’m requesting a formal agreement on the target. Lots of
things become evident and easy to plan once the exit point is known.
And, it will probably take years to get there (getting everyone on
harfbuzz was defined as a target in the 2006 text summit IIRC, we’re
finishing it now) but at least we’ll be all pushing in the same
direction.
Regards,
--
Nicolas Mailhot
4 years, 4 months
- 1
- 0
[RFC] target font model on Freedesktop systems
by 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/vari...
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
4 years, 4 months
- 1
- 0
Default variable fonts in Google Noto
by Akira TAGOH
Hi,
I'm planning to write a Change proposal for things as subject, to have
more variants and styles without increasing disk spaces and/or to
reduce disk spaces.
We have a few languages or someone who potentially be impacted by this change.
- Sinhala
- Punjabi (from f31 AFAIK)
- In case Noto has already been installed and explicitly used in applications.
Does anyone has any concerns on this change?
Well, even if not, that would be nice to try and give me feedbacks if any. :)
Otherwise I'll make a proposal for f31.
TIA,
--
Akira TAGOH
4 years, 4 months
- 2
- 2
- ← Newer
- 1
- Older →