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
