First run commentary - required columns missing

[dberlow]

The sheet needs to remain self-explanatory, and contained.

Columns must be added to contain:

1. The glyph ID from where the parameter comes
2. The index point(s) of the glyph being measured

[djrrb]

Information about the measurements taken is in the "Measurements" sheet, which allows the "Sources" sheet to focus exclusively on measurements for each source.

I can add these columns to the "Sources" sheet as well if you want, but wanted to double-check before making the sheet more complicated by including different data types and redundant data.

The glyph ID from where the parameter comes

I think by Glyph ID you mean Unicode value, right?

The script currently works by deriving the unicode value from the reference glyph. If it is a single character, it uses the unicode value for that character. If it is multiple characters, it interprets the value as a glyph name.

Did you still want me to include unicode value columns when it is already implied?

[dberlow]

The sheet is here; https://docs.google.com/spreadsheets/d/1r0oqR3ic8qQJycGgmZW-kqKEzgoPIIiKxt4MhOJFu7U

Measurements = an input to the program, a list of axes + a 1, and then the axis measure, between what points, in which direction, on what glyphs.

Axes = not sure what this is for, but it’s a list of some axes, and their def, min and max values

Sources = output of the program, with the unique data being upm and per mill measures of all of the sources enlisted by a single designspace that match the axes listed on the “axes” page?

Are you sure the sheet names of measurements and sources are not swapped?

As for the identity of what glyph’s to be measured, I leave it to you for now, but eventually the glyph’s index value, is the target. If it’s an input character, that is easy; going from input, to cmap to Unicode to glyph index. If we need to include a YT value for a tildecombcasestacked, or an oldstyle figure 0, let me know the plan.

[djrrb]

Are you sure the sheet names of measurements and sources are not swapped?

Ha yeah I see the issue here. To avoid confusion, I have renamed the sheet names:

Inputs - where we define what measurements will be taken
Measurements - a list of source UFOs and their measurements

Does that make sense?

Axes = not sure what this is for, but it’s a list of some axes, and their def, min and max values

Since this doesn’t seem useful to you, I have omitted this from the sample spreadsheet. The script still generates the CSV, just in case.

As for the identity of what glyph’s to be measured, I leave it to you for now, but eventually the glyph’s index value, is the target. If it’s an input character, that is easy; going from input, to cmap to Unicode to glyph index.

AFAIK the UFO format does not have an official GID field like OpenType fonts do. The closest thing is public.glyphOrder, which is an optional list of glyphs which doesn’t feel like it’s as "archival" as GID (I could be wrong here).

So we can use the glyph’s position in public.glyphOrder, but my feeling is that this is liable to change more often than glyph name, and is liable to be different than the GID list in the resulting TTF (as some glyphs like .notdef can be generated upon export and shift the order). Let me know if I’m misunderstanding here.

If we need to include a YT value for a tildecombcasestacked, or an oldstyle figure 0, let me know the plan.

When a unicode character will not suffice, I figured that listing the glyph name would be the best way to identify a glyph in a UFO.

I’m leaving this issue open until I hear from you.

[dberlow]

On the sheet naming, I brought up my initial impressions knowing a lot of type designers have trouble naming things, and are sensitive to their names for things. I’m sure your name reconsideration here is fine, thanks so much. On glyph index, names, etc, I hear and obey whatever is adept enough now. The aptitude I’m thinking of with GID, is based on a fool-proof way that any glyph of a final vf will have, because that’s the way to find, along with the PID, points to a DID. A glyph ID, pointing to point IDs, pointing to a delta ID (of a gvar), is, I think, the actual target of my understanding and planning. This understanding is to provide the current missing link for proper production of: MVAR GVAR CVAR (https://docs.microsoft.com/en-us/typography/opentype/spec/mvar ..; just read the 1st 2-3 paragraphs. That takes you to here: https://docs.microsoft.com/en-us/typography/opentype/spec/otvarcommonformats, Which I don’t Recommend reading any of, but DIDs are there.) And also value-finding for unregistered axes that need to be used for designspace definition of those unregistered axes values, and perhaps more in OT1.9, when those values can be non-orthoganal, making it possible for parametric axes to be represented accurately relative to all other axes, as opposed to the current orthoganality. And values that are going to be kept from blending today, can be used later for on-the-fly blending when that’s possible. Future designspace files can then use this higher level font info to define registered axes. So the results are targeted, long term, to help the type developer without measuring all day, to see and analyze numerical relationships over a design space, and leave all kinds of trouble, getting from there to a designspace file, behind. That in turn, if we need to, will also allow production to approach making proper MVAR tables, and TN/FB and others to better facilitate hinted vfs, which requires control over the CVT, that makes cvar from gvar via DIDs. Hope this is helpful. On Aug 7, 2019, at 8:08 AM, David Jonathan Ross <notifications@github.com> wrote: Ha yeah I see the issue here. To avoid confusion, I have renamed the sheet names: Inputs - where we define what measurements will be taken Measurements - a list of source UFOs and their measurements Does that make sense? Axes = not sure what this is for, but it’s a list of some axes, and their def, min and max values Since this doesn’t seem useful to you, I have omitted this from the sample spreadsheet. The script still generates the CSV, just in case.