Thoughts on variable font hinting

[Marc Foley]

It would be great to have a discussion about this issue.

Current state:

Imo there is no suitable way to hint a vf yet. We have tried both vtt and both ttfa. Neither provided enough flexibility to control the hinting to our liking.

Matching static font hinting:

Win Chrome uses FreeType for vfs and DW for statics so matching is impossible. Matching hints from static fonts has been like playing whack-a-mole, 100% wouldn't recommend. I wonder if there would be a way to use the hinting from a static font on a vf. Yes, I get the points won't match but perhaps we could write a tool which uses a nearest neighbours approach?

Future:

We must also ask ourselves if we want to be burdened with this tedious task going forward? Screen resolutions are only increasing and Win's rasteriser produces much nicer results than the GDI days. I've released a few unhinted VF replacements for families which have over 500 million requests a week, not a single complaint.

[Jasper Terra]

Using VTT with res-hints provides for good result on high resolution screens imo. On lower resultion screens, result is a bit fuzzy but not bad either. I think this also a matter of what one is used to.

Advantage of res-hints is smaller amount of work; only the default instance needs to be hinted. This can largely be done via auto-hinter then adding refinements by hand.

Disadvantage is of course non-matching results between variable font and static version. Question is if matching is desired though; one could also use res-hinting on the static fonts although that might be not the way for lower resolution displays.

I’m also not sure how results inbetween variable font weights would render when weights are matching static font hinting. 

Perhaps the desired level of control needed to match variable and static fonts is too constraining? I can also imagine it would be very time consuming to add instructions and proof/check if everything works as expected.

Op vr 10 jan. 2020 10:42 schreef 'Marc Foley' via Google Fonts Discussions <googlefon...@googlegroups.com>:

It would be great to have a discussion about this issue so 

--
You received this message because you are subscribed to the Google Groups "Google Fonts Discussions" group.
To unsubscribe from this group and stop receiving emails from it, send an email to googlefonts-dis...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/googlefonts-discuss/a68956e5-bd9e-412b-8539-38305759b32e%40googlegroups.com.

[Nikolaus Waxweiler]

Random thought: psautohint 2.0.0 supports autohinting CFF2 variable fonts, which works for Cantarell.

[Dave Crossland]

Hi

Overall I believe we should not hint any VFs until TTFAutohint has good VF support, and then we can re-ttfautohint VF and Static releases of families that need it, so there is a 1:1 match between VF:SF, and just pay the regular regression/change cost of making an update. That cost is always worth paying to make a font family better, because the future is longer than the past, and because the fonts are libre so if people want control of their font upgrade schedule, they are free to take control. 

There's one exception to that, though: The work going on now by David Berlow and his team, including newly-freelance Mike Duggan, here: GitHub.com/TypeNetwork/Roboto - I'm waiting to see what they do to make Roboto VF as hint-render-compatible with Roboto static as possible - as our #1 family, this is the highest bar :) I also expect that since Paratype did the hinting on the static fonts for Roboto Static, they may be able to assist in the future, too. 

Ultimately if hinting VFs to match previous static releases is not possible, but still required, the nature of the API is that we serve different fonts to different user agents from the same API URL, and it's possible to make a VF, unhinted, then make offline instances and hint then I the traditional way, and then serve those to legacy non VF clients and VF clients who require hints. Obviously it's better to have a hinted VF and reap the benefits, but it's a relatively small slice of the user base who are in that boat. I think the majority of people who are using VF capable user agents do not render TT hints anyway. 

(CFF2 has many other issues, starting with less wide rendering support across browsers, so I am ignoring it, for now.)

Cheers

Dave

[Nikolaus Waxweiler]

I admit that I am in a special niche with Cantarell, the target being FreeType 2.10.1+ GNOME environments :D

Another random unproductive thought: Glyphs and probably Fontlab (7?) support a form of hinting that is less powerful than VTT, but can be properly stored in source control and may be good enough for the majority of cases. Imagine a ttfautohint that applies these hints to sources and then the compiler automatically applies them to static fonts and variable fonts. Imagine not having to deal with the brittleness of VTT TTX dumps anymore.

[Jens Kutilek]

Am 2020-01-15 12:57, schrieb Nikolaus Waxweiler:
>
> Another random unproductive thought: Glyphs and probably Fontlab (7?)
> support a form of hinting that is less powerful than VTT, but can be
> properly stored in source control and may be good enough for the
> majority of cases. Imagine a ttfautohint that applies these hints to
> sources and then the compiler automatically applies them to static
> fonts and variable fonts. Imagine not having to deal with the
> brittleness of VTT TTX dumps anymore.

Neither FontLab 5 nor 7 produce hints that can be made variable. The
main problem with FontLab 5 is that the stem definitions (sizes at which
stems change their pixel width) are in the prep table, which has no
variable counterpart. FontLab 7 has other TT hinting bugs which make it
unusable at the moment.

Glyphs uses a proprietary compiler from graphical hints to assembly
code, so to be compiled outside of Glyphs, Georg would have to
open-source that, or an alternative implementation would have to be
built.


In my opinion, for run-of-the-mill cases, excluding variable deltas and
axis-position-specific instructions, a relatively simple way to hint
variable fonts would be this:

- Autohint the master font which has the most diverse stem widths, so
probably the heaviest weight
- Instead of only noting the absolute cvt values, save them as
references to font measurements/outline points, e.g. for a stem: "CVT 15
is the vertical distance between points 1 and 26 in glyph C", or for a
"zone": "CVT 5 is the vertical position of point 7 in glyph f".
- Measure the corresponding points in all other masters and build only a
cvt table for each master
- Transfer the font-level hinting and glyph-level hinting from the
hinted master to the default master
- Build a variable font with fonttools.varLib which will take the font
and glyph programs from the default master, and compiles the cvt tables
from all non-default masters into a cvar table

I have the goal to do it like this in my Python VTT reimplementation,
but am not at that point by far yet.

Cheers,
Jens