Does Samsa support v2 STAT tables? about samsa HOT 11 CLOSED

This font does not need Format 4 Axis values tables, as far as I can tell.

All your SemiBolds are at 600, all your UltraExpandeds are at 200, etc. In other words, the instances in the design space are on an orthogonal grid, and therefore Inconsolata is best served by 17 (=8+9) Axis values tables in format 1, 2 or 3 (see table), rather than 72 (=8*9) in format 4. You in fact have 76 Axis value tables including 4 duplicates (e.g. AxisValue indices 2 and 70, both UltraExpanded ExtraLight).

BTW you mean format v1.2, which is the latest on the Microsoft STAT spec and in your font.

In any case, Samsa GUI should still support Format 4 :)

from samsa.

Do you know if MS Office rejects all format v1.2 STAT tables, or only the Format 4 Axis value tables inside them? /cc @robmck-ms

from samsa.

The samsa-core.js STAT parser does work with Format 4, in case you want to hack. Type GLOBAL.vf.tables["STAT"].data into the console to see the data. Here’s an extract from Inconsolata[wdth,wght].ttf:

from samsa.

Related, a couple of weeks ago @twardoch wrote an interesting post about non-orthogonality and STAT, googlefonts-discuss, Re: Variable fonts: Do we really need so many instances, referring to @typoland’s nice diagram in his repo Instances Calculator.

from samsa.

On Windows, I recommend using FontSetViewer (https://github.com/fdwr/FontSetViewer) to see how the various APIs are enumerating the font. I agree that this font doesn't need format 4 - that format was created for something like DecoVar where the instances don't really group in any particular way, and the axes are more visual parameters.

Regarding office: The responsibility for STAT is below Office. For font enumeration, Office calls GDI, which relies on DirectWrite for much of the work, but also does it's own STAT table parsing. DWrite supports format 4; GDI doesn't yet.

from samsa.

Ugh. I can't keep up with all the threads on all the discussion forums. The intention of the weight axis user coordinates is that they are orthogonal and you use avar to map them to whatever normalized coordinate you want to get the right interpolation you want. Unfortunately, avar has it's problems... (cue XVARr/ avar2, all of which I wanted to get into the original v1.8 spec, but...)

from samsa.

Thank you both for your answers.

Apologies, I've been a complete idiot. After rereading the spec

The axis record provides information about a single design axis.

I always assumed the STAT wasn't for each axis but for all axes that make up an individual style. @Lorp I'll adopt your suggestion and yes I meant v1.2.

@robmck-ms thank you for the link to FontSetviewer. I'll check it out.

Feel free to close this issue if supporting format 4 lookups is out of scope.

from samsa.

All good. The check of what Samsa was doing with Format 4, using your sample font, made me see a bug where it wasn’t being parsed correctly :) Fixed in 75d313f.

Here are the first two records from Inconsolata in Samsa’s font.tables["STAT"].data. In formats 1, 2 and 3 the axisIndex and value properties are numeric, in format 4 they are arrays of numerics.

I’ll leave the issue open until Samsa GUI supports Format 4.

from samsa.

The intention of the weight axis user coordinates is that they are orthogonal and you use avar to map them to whatever normalized coordinate you want to get the right interpolation you want.

Should this clarification be added to the ot spec?

Unfortunately, avar has it's problems...

Where are these documented? :)

from samsa.

The intention of the weight axis user coordinates is that they are orthogonal and you use avar to map them to whatever normalized coordinate you want to get the right interpolation you want.

Should this clarification be added to the ot spec?

Perhaps. It's broader than the wght axis. All axes are supposed to be independent axes (e.g. you can hold all axes constant and move one and only the feature that one controls should move). With wght, there's the added constraint that the numbers correspond to specific semantics. 400 is Regular, 700 is Bold, etc. So, if you set to wght=700, that should be the bold for whatever you have the rest of the axes set to. (or, flipside: if you keep wght=700, and move other stuff, you should always get the Bold of whatever the other axes are set to, and moving wght to 400 gives you the corresponding Regular).

So, my what I described in my previous message is implicit in the details, but this is clearly something people are stumbling on. (I've seen wdth axes that have 100 as bold and 0 as light).

Unfortunately, avar has it's problems...

Where are these documented? :)

https://github.com/Microsoft/OpenType-XVAR-proposal#the-problem plus discussions in several places about XVAR & avar2.

from samsa.

Samsa GUI now supports format 4 axisValueTables, from this commit d8830ee

Also in that commit, the STAT panel now gets amended as you move around the designspace.

from samsa.