Named instances all the same in Font Book about decovar

[dberlow]

That's wrong, I've been trying to correct it, they should all say "regular 48".

…

Sent from my iPad

On Feb 22, 2017, at 6:35 PM, Rob McKaughan ***@***.***> wrote: When I install Decovar on my mac (OSX Sierra), Font Book lists all the instances with the same name. TextEdit only shows one instance. Font Book: — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

[PeterCon]

Why wouldn't you want them to appear as "Regular", "Worm", "Open", etc. --- using the names given for named instances in the 'fvar' table?

Currently, the font has these names:
name ID 1: "Decovar Regular24"
name ID 2: "Regular"
name ID 16: "Decovar"
name ID 17: "Regular24"

For this font, I'd recommend:
name ID 1 = name ID 16 = "Decovar"
name ID 2 = name ID 17 = "Regular"

[robmck-ms]

Dang, and I was hoping for "Regular90210". 😄

What I was really hoping for is the named instances @djrrb added to the fvar table for #3. (Peter listed several of them above). They're in the font, yet not showing up anywhere in the UI.

I've had similar problems in fonts I generated. Sometimes it's been name table encoding issues, sometimes name ID 16 length issues causing all the generated PostScript names for the named instances to be identical (early versions of Selawik did this). I took a look through this font, though, and I couldn't find anything that might be causing this (nice short names, encoding looks right to me, ...).

[davelab6]

I think that was a failed attempt at humor, folks :)

[dberlow]

Rob, I hope you remember our conversation. Names, names, names? There are two kinds of axes. Ones with registered names, (taking programs to value systems that help solve typographic equations), and, in a "variation world", they become interoperable as I want them to be, go figure. And then, there are axes that are solvable visually. Go fish, and find your look. Right? Variation world is a world where OS, app, and page description languages can use 1.8 fonts. It is not a world where <1.8 fonts fail, but in a world where OS, app, and page description languages store the instances of a variation font that are used, and not the font, there is a clear understanding I have with my users, that names are the worst enemy of unregistered axes. They are also, beyond the axis name itself, the worst enemy of registered axis, where the naming of things along an axis is clearly harrowing to the brains of our audience. You can't name everything on the width axis, can you? What are the names of every possible width in the width axis? https://cloud.githubusercontent.com/assets/7713203/23264708/518e52d6-f9b0-11e6-8a35-b0f9540a5c18.png There are 450 some-odd widths of Amstelvar, we'd better get to work. Peter mentioned in the intro to the grades discussions, that opsz is all taken care of, having a value system everyone understands. While that's true, if there are 72 point per inch, and the opsz axis is hooked up to the size control in an app, such that the size choices a user makes are stored as values on the opsz axis, they are not named. They have values, like 48, or 22.456, right? You show to users? only in the Variation UI, not font menus, or the file names that drive my audience insane. The future of neither registered axis values, or unregistered anything, is in names. Not thinking, creating or working with designers inside of var world is difficult, I know. I've spent the last 20 years with my staff, with about two of those years collected up and spent on naming things. Amstelvar was made to prove that there are more registered axis, and how we can name and value those and will program using variation fonts. Decovar was made to show how we can't. Amstelvar was made as a "go figure" font, Decovar was made to "go fish". Now that hardly means Amstelvar is exclusively Go Figure, as nearly all type selection starts with at least one Go Fish to find the font family. And, it certainly doesn't mean Go Fish, is all you can do in Decovar, in fact, Decovar has 345,676,238 optical size axes coming. Here's one example from the upcoming work we have to show our clients.  the largest size is for a magazine logo, where the graphics of the cover need to show through everything. The middle size is programmed to be the same line weight as the logo, and so I will eventually instance these two top styles, define the size you see them shown at on an opsz axis, and Decovar begins to Go Figure, from a huge sea of fish people catch. Hope you get the idea. I'm not a big fan of names. Terminals and Skeletons are what I started with, and I think going back to that, before expanding to 1,000's and 1,000's of Decovar axes, is best.

[sberlow]

Images for above...

[davelab6]

Thanks Sam! I cleaned up Davids' email and folded in his edit, but since his message was via email I can't put the images inline, so I added them as direct link :)

David, note that commenting on github issues via email won't include attached images, you need to load the issue webpage and comment directly there (which is less ideal on an iPad, I admit...)