MVAR for Panose Values

[davelab6]

While PANOSE values haven't been used much in the past, I am interested in reviving this technology.

A few years ago I commissioned a Devanagari schema (https://github.com/googlefonts/panose-devanagari)

One of the challenges of VF is that a family can now span many PANOSE values across its design space.

On a call today, @simoncozens suggested perhaps the MVAR table should update PANOSE values too.

[Lorp]

I like the idea, but it’s compromised in a few ways.

• PANOSE uses its 10 digits differently according to the design of the font: Latin Text, Latin Hand Written, Latin Decoratives, Latin Symbol. Not necessarily a deal-breaker.

• Even for just Latin Text, the digits are recorded in the OS/2 table as unsigned bytes with no fractional part, so the calculated parameters are severely quantized. It’s just about possible to deliver such quantization with variable maths, but it prevents us providing accurate values for each master, and interpolated values (being based on the quantized values for the masters) will also be faulty. We can’t easily use a higher resolution because we only have one byte. For example, the third digit (Weight) determines a WeightRat ratio (stem width / cap height) which is interpreted thus:

  • …
  • 3: Light………………… 18 ≤ WeightRat < 35
  • 4: Thin……………………10 ≤ WeightRat < 18 // unusual meaning of Thin, but we’ll let that pass
  • 5: Book ………………….7.5 ≤ WeightRat < 10
  • …

• Each PANOSE digit typically gives 0 and 1 a special meaning. So Weight uses values from 2 (Very Light) to 11 (Extra Black) but 0 means “Any” and 1 means “No fit”. It is not obvious how to make use of these values.

Reference: the PANOSE spec

[Lorp]

A related idea would be to use the STAT table to record locations in the Type Network parametric system. Start with the Named Instances, but there shouldn’t be a limit in how many STAT records you include.

[simoncozens]

What I actually said in the meeting was “does PANOSE even make sense for a variable font?” - a question clearly expecting the answer “no”. ;-)

[davelab6]

Haha! Sorry for misquoting you there Simon :)

I think the whole OS/2 table has to go, so, no worries about the undue quantization of that representation.

If the definition or use of 0 and 1 need clarity, we can ask Ben Bauermeister to explain.