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

[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 at 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