Variable fonts: Do we really need so many instances?

[Marc Foley]

We're going to release several multi axis variable fonts very soon. I'm starting to believe that having too many instances is a terrible idea. From a user perspective, the choice is just overwhelming and the scrolling is a pita.

There's more...

Personally, I'd just like Thin-Black + Italics + 2 widths as instances (that's already a max of 54). If I want to tweak the x-height or play with opsz, I should be able to adjust sliders.

The maths is also hilarious. If we take a family which is Thin-Black that's 9 instances, throw in Italics that's 18, now add an opsz that's 36, and x-height that's 72, ahh let's add 5 widths that's 360 instances. 

How are other people handling this?

Dave, have we done any UX tests for this issue?

[Dave Crossland]

Because some applications like Microsoft Office can only access named instances, And because named instances will be used as fallbacks for documents which are specified with design spaces, then unfortunately we do need to have hundreds of names instances. The open types back probably needs an addition to allow some of them to be starred, And until that happens the likelihood is that catalog UIs will only show a subset of them.

[Dave Crossland]

Different types back does allow type designers to flag axes as recommended to be only shown to users under progressive disclosure, I'm potentially we can drop the named instances for those axes. Unfortunately the opsz instances shown here don't make sense. Those would need to be named with the point size that they are designed for.

[Dave Crossland]

Is there a theoretical limit to how many named instances that can be used?

[Marc Foley]

Dave Crossland

11:54 (5 minutes ago)

Because some applications like Microsoft Office can only access named instances, And because named instances will be used as fallbacks for documents which are specified with design spaces, then unfortunately we do need to have hundreds of names instances. 

That's going to make the font menu a complete mess so I'm strongly opposed to this. Just because we can do it doesn't mean we should.

More than happy to make a testcase and you can witness the pain yourself.

[Dave Crossland]

The font menus have to be redesigned. The fonts are going to last a lot longer than the software. 

[Marc Foley]

I'd also like to point out that for non-RIBBI styles/instances in Word, they're included as separate font families. If we have 500 instances, the font menu dropdown is going to be filled with these instances.

[Dave Crossland]

I'd be grateful if you could post some screenshots

[Micah Stupak-Hahn]

Can I agree with both of you? That menu is a nightmare but the only way to work around it is at the very end (application) or beginning (OT spec). I also think it's confusing for non-expert users to be like "okay, I heard about variable fonts, this font is one, let's look at all the many weights I now have" [opens cleaned-up menu of weights] "this is the same number I used to have" 😑

[Jacques Le Bailly]

That's going to make the font menu a complete mess so I'm strongly opposed to this. Just because we can do it doesn't mean we should.

More than happy to make a testcase and you can witness the pain yourself.

Isn't there a way to sub group them ? Or export the Instances with the axe in the name ? 

[Dave Crossland]

On Thu, Feb 27, 2020 at 11:45 AM Jacques Le Bailly <fonth...@gmail.com> wrote:

That's going to make the font menu a complete mess so I'm strongly opposed to this. Just because we can do it doesn't mean we should.

More than happy to make a testcase and you can witness the pain yourself.

Isn't there a way to sub group them ?

No.

 

Or export the Instances with the axe in the name ? 

That is what we are doing. 

If you have just 3 axes, weight width optical size, in Roman and Italic, and you take 10 instances along each, that is 10x10x10x2 = 2,000 named instances. 

There's no way around it, other than to sample the space at a lower resolution, sg 7 weights, 5 widths, 3 sizes, 2 styles = 210 named instances.

"Many styles in 1 file" has a dark side. 

 

[Stephen Nixon]

But *isn’t* there a way to subgroup instances, at least theoretically? Foundries have done this for static fonts for a long time. Often by width, then weight. But, doing this variable fonts would probably require an addition the OT spec, *and* better design in MS font menus.

But, I would argue that sampling at a lower resolution onlymake sense. No user can tell the difference between 10 units of optical sizing – most might have trouble understanding “text” from “display.” Of course, they’ll see the result of reflow, but is anyone really trying to open advanced magazine layouts in MS Word?

--
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/CAOgqPYdKgVGyUqsR16%2B1HuNzZRd04viOzpD5p3gvdAmu8yzJ2g%40mail.gmail.com.

--

——

Stephen Nixon 

stephennixon.com

[Fonthausen]

Or export the Instances with the axe in the name ? 

That is what we are doing. 

If you have just 3 axes, weight width optical size, in Roman and Italic, and you take 10 instances along each, that is 10x10x10x2 = 2,000 named instances. 

I get that. But I meant something else. 

Now you have: Fontname - Expanded Black. Would this be a plausible workaround ?: Fontname Expanded - Black.

[Dave Crossland]

On Thu, Feb 27, 2020 at 11:56 AM Stephen Nixon <ste...@thundernixon.com> wrote:

But *isn’t* there a way to subgroup instances, at least theoretically?

If the names are programmatically generate, they will appear as 'groups' when sorted alphabetically. Is that what you mean?

 

Foundries have done this for static fonts for a long time. Often by width, then weight. But, doing this variable fonts would probably require an addition the OT spec, *and* better design in MS font menus.

:)

 

But, I would argue that sampling at a lower resolution onlymake sense. No user can tell the difference between 10 units of optical sizing – most might have trouble understanding “text” from “display.” Of course, they’ll see the result of reflow, but is anyone really trying to open advanced magazine layouts in MS Word?

What do you propose as the minimum sample rate for an opsz from 8 to 144? 8, 14, 144? 

[Dave Crossland]

I believe the latter is actually what MS Word does, whereas Adobe/Apple apps do the former. But the issue is still the same - one file, 100s of new items in  a 1980s font menu UI.

[Eben Sorkin]

RE: Fontname Expanded - Black

I agree with you. That's what we did with the pre-variable Halyard. Promotionally we treated it as a superfamily but in font menus the optical sizes are their own "folders". And theoretically if we ever made widths each width+optical size would also be its own folder. I also think as a practical matter people are trained to select weights and italics within a mentally group of 6-18. because that's the existing culture and we are already bringing something new we should probably preserve at least that part of the experience for most font families. I am interested in counter arguments though.

On Thu, Feb 27, 2020 at 12:06 PM Fonthausen <fonth...@baronvonfonthausen.com> wrote:

--
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/BCC4E745-2A7C-43A2-8A35-5FA392160A29%40baronvonfonthausen.com.

[Dave Crossland]

On Thu, Feb 27, 2020 at 12:13 PM Eben Sorkin <sorki...@gmail.com> wrote:

RE: Fontname Expanded - Black

I agree with you. That's what we did with the pre-variable Halyard. Promotionally we treated it as a superfamily but in font menus the optical sizes are their own "folders". And theoretically if we ever made widths each width+optical size would also be its own folder. I also think as a practical matter people are trained to select weights and italics within a mentally group of 6-18. because that's the existing culture and we are already bringing something new we should probably preserve at least that part of the experience for most font families. I am interested in counter arguments though.

Does the STAT table allow style-familiy packing like "Family OpSz Width - Weight" for Adobe/Apple apps?

[Stephen Nixon]

What do you propose as the minimum sample rate for an opsz from 8 to 144? 8, 14, 144? 

For a range as big as Roboto Extremo, maaaybe people could handle 4 steps of opsz. Maybe something like 8, 24, 72, 144. Or maybe 8, 12, 64, 144, if we really feel like the stadard text-size value is important to keep (it probably is). We could call it something like "Micro, Text, Display, Banner."

 

——

Stephen Nixon 

stephennixon.com

--
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/CAOgqPYe1NoW0o54y1ZjD6H914R613z%2BkH0vKk%2BDLi2yejdhnCg%40mail.gmail.com.

[Thomas Linard]

Word for Windows (and yes, that can make menus very long). But Word for macOS groups everything in the same family.

[Thomas Linard]

Why not take inspiration from what Adobe has done in the past (which originally came from MultiMaster fonts, by the way): Caption (6 to 8 pt), Regular (9 to 13 pt), Subhead (14 pt) and Display (25 to 72 pt)?

http://creativepro.com/typetalk-optical-and-size-specific-fonts/

[Eben Sorkin]

So I can follow along; you mean if you have a variable font installed - correct?

--

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/06b01923-3648-4850-987e-d74c770dee60%40googlegroups.com.

[Eben Sorkin]

Having one more category acknowledges that type for Display headlines and type for large scale display ( Stephen's Banner) are meaningfully different. 

The argument for leaving a good number of optical categories in is that 

• Headline, 

• large scale display ( Banner) 

• Caption/Micro 

will not exist in the library very often. 

So 90% of the time you are left with a very manageable pair just Text or Display/Headline or maybe the two together.

Put differently, I think that the extremity of Roboto's optical axis should not drive what is possible for the whole library even if Roboto is quite important.

-e.

--

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/3b155763-bfea-4aa2-a804-69525e189ac0%40googlegroups.com.

[Thomas Phinney]

The problem with splitting up a family is, it breaks mapping working across families. I can't change "Family A" to "Family B" and have the styles match up, because each does things in its own way. One splits by optical sizes (Halyard). Another by widths (Acumin). As a user, I just want to kill all the foundries, argh!

Then again, I strongly suspect some common apps will break with >256 instances. Unfortunately, our upcoming Science Gothic is 9 weights * 5 widths * 3 Contrast * 2 Slopes = 270 instances ... if we don’t censor some of them.

T

On Thursday, February 27, 2020 at 9:13:35 AM UTC-8, Eben Sorkin wrote:

RE: Fontname Expanded - Black

I agree with you. That's what we did with the pre-variable Halyard. Promotionally we treated it as a superfamily but in font menus the optical sizes are their own "folders". And theoretically if we ever made widths each width+optical size would also be its own folder. I also think as a practical matter people are trained to select weights and italics within a mentally group of 6-18. because that's the existing culture and we are already bringing something new we should probably preserve at least that part of the experience for most font families. I am interested in counter arguments though.

On Thu, Feb 27, 2020 at 12:06 PM Fonthausen <fonth...@baronvonfonthausen.com> wrote:

Or export the Instances with the axe in the name ? 

That is what we are doing. 

If you have just 3 axes, weight width optical size, in Roman and Italic, and you take 10 instances along each, that is 10x10x10x2 = 2,000 named instances. 

I get that. But I meant something else. 

Now you have: Fontname - Expanded Black. Would this be a plausible workaround ?: Fontname Expanded - Black.

--
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-discuss+unsub...@googlegroups.com.

[Dave Crossland]

On Thu, Feb 27, 2020, 12:55 PM Thomas Linard <thli...@gmail.com> wrote:

Why not take inspiration from what Adobe has done in the past (which originally came from MultiMaster fonts, by the way): Caption (6 to 8 pt), Regular (9 to 13 pt), Subhead (14 pt) and Display (25 to 72 pt)?

http://creativepro.com/typetalk-optical-and-size-specific-fonts/

take a look at Roberto Extremo and Amsterdam's 25 and 72 on 144 point designs... It's a big difference especially a long the weights and width axes' min and max

[Dave Crossland]

Yes

To view this discussion on the web visit https://groups.google.com/d/msgid/googlefonts-discuss/CAOduwwtK7-Mk8MyWnQ4zKkj4ozxFr498qUcNzqEszuHgr0KeHQ%40mail.gmail.com.

[Dave Crossland]

On Thu, Feb 27, 2020, 2:32 PM Eben Sorkin <sorki...@gmail.com> wrote:

Having one more category acknowledges that type for Display headlines and type for large scale display ( Stephen's Banner) are meaningfully different. 

The argument for leaving a good number of optical categories in is that 

• Headline, 

• large scale display ( Banner) 

• Caption/Micro 

will not exist in the library very often. 

So 90% of the time you are left with a very manageable pair just Text or Display/Headline or maybe the two together.

Put differently, I think that the extremity of Roboto's optical axis should not drive what is possible for the whole library even if Roboto is quite important.

But we have like a dozen families coming with that size range.

-e.

On Thu, Feb 27, 2020 at 12:55 PM Thomas Linard <thli...@gmail.com> wrote:

Why not take inspiration from what Adobe has done in the past (which originally came from MultiMaster fonts, by the way): Caption (6 to 8 pt), Regular (9 to 13 pt), Subhead (14 pt) and Display (25 to 72 pt)?

http://creativepro.com/typetalk-optical-and-size-specific-fonts/

On Thursday, February 27, 2020 at 6:30:03 PM UTC+1, Stephen Nixon wrote:

What do you propose as the minimum sample rate for an opsz from 8 to 144? 8, 14, 144? 

For a range as big as Roboto Extremo, maaaybe people could handle 4 steps of opsz. Maybe something like 8, 24, 72, 144. Or maybe 8, 12, 64, 144, if we really feel like the stadard text-size value is important to keep (it probably is). We could call it something like "Micro, Text, Display, Banner."

 

——

Stephen Nixon 

stephennixon.com

On Thu, Feb 27, 2020 at 12:15 PM 'Dave Crossland' via Google Fonts Discussions <googlefon...@googlegroups.com> wrote:

On Thu, Feb 27, 2020 at 12:13 PM Eben Sorkin <sorki...@gmail.com> wrote:

RE: Fontname Expanded - Black

I agree with you. That's what we did with the pre-variable Halyard. Promotionally we treated it as a superfamily but in font menus the optical sizes are their own "folders". And theoretically if we ever made widths each width+optical size would also be its own folder. I also think as a practical matter people are trained to select weights and italics within a mentally group of 6-18. because that's the existing culture and we are already bringing something new we should probably preserve at least that part of the experience for most font families. I am interested in counter arguments though.

Does the STAT table allow style-familiy packing like "Family OpSz Width - Weight" for Adobe/Apple apps?

--
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/3b155763-bfea-4aa2-a804-69525e189ac0%40googlegroups.com.

--

You received this message because you are subscribed to a topic in the Google Groups "Google Fonts Discussions" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/googlefonts-discuss/XCHD21yi4KI/unsubscribe.
To unsubscribe from this group and all its topics, send an email to googlefonts-dis...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/googlefonts-discuss/CAOduwwsAp%2Bs8LWZdYK52n3x7Lawz_BOyV29NG6OmHbcV-dydyQ%40mail.gmail.com.

[Adam Twardoch (Lists)]

With TTC for desktop fonts, you can create multiple “virtual” fonts or VFs that have the same content except fvar & name tables, then merge them into a TTC. 

In fvar and name, you can move some of the style attributes from the style name to the family name. So instead of 1 font family menu entry and 360 style entries, you might have 6 family entries with 60 sttyles each. 

Many foundries have produced traditional font families this way. 

[Adam Twardoch (Lists)]

And that's not even any hack, it's the perfectly legitimate use of TTC.

Source Han has been done this way, but with different name & cmap. fvar is a logical candidate. The cmap, fvar & name tables are all "user interface font API tables", and providing multiple scenarios for them makes sense. 

For the web delivery, it doesn't matter, because browsers support features (no need for different cmaps), and they don't really use predefined instances or the font naming.

A.

[Pablo Impallari]

Same discuccion?

Do we really need so many fonts? so many Icecreams? So many Drugs?  So many Music? So many girls?

Technically we don't, but we are robots man... and the mans from the statistics decisions tells us to keep doing, and taking them to new places (where they become new again).

So, yes, we keep growing, we change tastes, we make mistakes, we learn (or maybe not) but we keep always growing, until that day when we day.

Fonts are good for the net... ;)

And developers that know what they are doing wont even instal them.

--
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/CAG32G7Pdoi7do5av%3Dy94aJu1_9ZwuuzjiHdH8B_5yM0brQUCQA%40mail.gmail.com.

--

Un Abrazo
Pablo Impallari

[Stephen Nixon]

No one here is arguing against adding new typefaces to the world, as far as I can tell. We are just wondering whether the average MS Word user (probably a large portion of the GF user base) will be able to handle a font menu with hundreds of extra items, or how we might make that experience better for them (while still giving experts a full palette of new creative possibilities).

To make a metaphor of my own, I am glad that the world has hundreds of different beers, but I don’t expect every bar I visit to have every possible option on tap. Some bars are best with just a few options.

To view this discussion on the web visit https://groups.google.com/d/msgid/googlefonts-discuss/CACpgx%3DNn1X54_-KPCfug%3DyMBsXNT0cKoiJ5vG7xUxcOWZaLuYQ%40mail.gmail.com.

--

——

Stephen Nixon 

stephennixon.com

[Thomas Phinney]

Agree with Stephen.

In my personal case, I'm concerned that:

- there are likely some app-specific limits at 256 styles

- even if 200+ styles doesn’t break a given app, it is still pretty hard to work with

If apps have bugs or unreasonable limits, those issues should be flagged and fixed.

But even aside from such issues, I want users to have a good experience and be able to work comfortably with the font. I'm starting to think that more than 120 or 150 predefined instances is just getting too darn big.

T

On Saturday, February 29, 2020 at 12:36:13 PM UTC-8, Stephen Nixon wrote:

No one here is arguing against adding new typefaces to the world, as far as I can tell. We are just wondering whether the average MS Word user (probably a large portion of the GF user base) will be able to handle a font menu with hundreds of extra items, or how we might make that experience better for them (while still giving experts a full palette of new creative possibilities).

To make a metaphor of my own, I am glad that the world has hundreds of different beers, but I don’t expect every bar I visit to have every possible option on tap. Some bars are best with just a few options.

On Sat, Feb 29, 2020 at 14:43 Pablo Impallari <impa...@gmail.com> wrote:

Same discuccion?

Do we really need so many fonts? so many Icecreams? So many Drugs?  So many Music? So many girls?

Technically we don't, but we are robots man... and the mans from the statistics decisions tells us to keep doing, and taking them to new places (where they become new again).

So, yes, we keep growing, we change tastes, we make mistakes, we learn (or maybe not) but we keep always growing, until that day when we day.

Fonts are good for the net... ;)

And developers that know what they are doing wont even instal them.

El vie., 28 feb. 2020 a las 14:08, Adam Twardoch (Lists) (<list...@twardoch.com>) escribió:

And that's not even any hack, it's the perfectly legitimate use of TTC.

Source Han has been done this way, but with different name & cmap. fvar is a logical candidate. The cmap, fvar & name tables are all "user interface font API tables", and providing multiple scenarios for them makes sense. 

For the web delivery, it doesn't matter, because browsers support features (no need for different cmaps), and they don't really use predefined instances or the font naming.

A.

On Fri, 28 Feb 2020 at 18:01, Adam Twardoch (Lists) <list...@twardoch.com> wrote:

With TTC for desktop fonts, you can create multiple “virtual” fonts or VFs that have the same content except fvar & name tables, then merge them into a TTC. 

In fvar and name, you can move some of the style attributes from the style name to the family name. So instead of 1 font family menu entry and 360 style entries, you might have 6 family entries with 60 sttyles each. 

Many foundries have produced traditional font families this way. 

--
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-discuss+unsub...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/googlefonts-discuss/CAG32G7Pdoi7do5av%3Dy94aJu1_9ZwuuzjiHdH8B_5yM0brQUCQA%40mail.gmail.com.

--

Un Abrazo
Pablo Impallari

--
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-discuss+unsub...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/googlefonts-discuss/CACpgx%3DNn1X54_-KPCfug%3DyMBsXNT0cKoiJ5vG7xUxcOWZaLuYQ%40mail.gmail.com.

--

——

Stephen Nixon 

stephennixon.com

[Pablo Impallari]

Microsoft word is something thay will always be bothering us with limitations.

Naming a single family with more than the typical 4 RIBI stylre is already a pain in the ass.

I stopped worrying about Word long ago if the font are not intend for Body text.

If MW can manage perfectly valid font that follows the standards is their product bug. All I can do is file a bug report and encorage trobled users to do the same. What else?

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/CAG32G7Pdoi7do5av%3Dy94aJu1_9ZwuuzjiHdH8B_5yM0brQUCQA%40mail.gmail.com.

--

Un Abrazo
Pablo Impallari

--
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/CACpgx%3DNn1X54_-KPCfug%3DyMBsXNT0cKoiJ5vG7xUxcOWZaLuYQ%40mail.gmail.com.

--

——

Stephen Nixon 

stephennixon.com

--
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/80e81f71-5523-4f07-be77-c2f1d1df5cff%40googlegroups.com.

[Dave Crossland]

On Sun, Mar 1, 2020, 1:06 AM Pablo Impallari <impa...@gmail.com> wrote:

I stopped worrying about Word long ago if the font are not intend for Body text.

Optical Size makes this less clear... All the families with large opsz ranges are intended for both body and display...

Overall, the most important axes are weight and width and optical size... 

A limit of 256 means 128 Roman/Italic, and with Weight from 1..1,000 then we can add meaningful instances at 1, 50, and 1,000 to the 9x 00s, so that's 12... which means 10 or less samples of one other axis, or samples that multiply to less than 10.6... say Width min, default and max and opsz min, default and max...

But maybe the new/additional weights only make sense in the larger opsz region... And at the opsz-min region, even the 100, 200 and 800, 900 aren't so useful... 

I guess we need something like https://github.com/w0rm/elm-font-dimensions for plotting the sample rates per axes and seeing the cross product results 😅

[Adam Twardoch (Lists)]

One thing to consider: 

1. Make many STAT instances

2. Make much fewer fvar instances, a controlled number

A.

--

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/CAOgqPYcfaA%2BeDKk9no_ODdp7PKspa-jtLoOZSQqvz_LVEwxXRw%40mail.gmail.com.

[Eben Sorkin]

I agree and moreover if you are looking at what you font can do you should be noticing where the sweet spots in the design are. In other words the places where in your variable design you think people will find the most typographic utility and and the most meaningful contrasts within the design. 

It might even be that even you have a large number of axis' that you think you have just 8 or 16 or 24 or 36 particularly useful destinations in the possible design space they provide. 

From the point of view of the releasing entity ( Google, Microsoft, Adobe or whoever) I think it makes sense to look at samples settings with the designer/s to come to a consensus about what the samples show and therefore how many styles make best sense to be highlighted for users. Typographic testing should drive this.

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/CAG32G7Pdoi7do5av%3Dy94aJu1_9ZwuuzjiHdH8B_5yM0brQUCQA%40mail.gmail.com.

--

Un Abrazo
Pablo Impallari

--
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/CACpgx%3DNn1X54_-KPCfug%3DyMBsXNT0cKoiJ5vG7xUxcOWZaLuYQ%40mail.gmail.com.

--

——

Stephen Nixon 

stephennixon.com

--
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/80e81f71-5523-4f07-be77-c2f1d1df5cff%40googlegroups.com.

[Adam Twardoch (Lists)]

It would be useful to standardowe od propose lists of STAT names. I think it might make sense to put e.g. 18 or more STAT instances for wght, not just 9, and similarly for other axes.

We should work on recommendations for naming — for new fonts. Designers will happily embrace it. 

Then fvar instances should be a combination of the "more important" axis locations. Primary instances, you could say. But STAT can have both primary and secondary instances, since the envisioned UIs for STAT let users pick each design aspect separately. 

Naming for STAT is a new thing and I'd love to collaborate on this. Let's just this opportunity to clean up ancient practices, and to propose some lingo for the 21st century. :) 

To view this discussion on the web visit https://groups.google.com/d/msgid/googlefonts-discuss/CAOduwwv24B7w7KXvA-Nm0aA6oh-6Vp%3Dqt4S%2BmVBrW3yE5Ne27Q%40mail.gmail.com.

[Dave Crossland]

On Sun, Mar 1, 2020, 3:42 AM Adam Twardoch (Lists) <list...@twardoch.com> wrote:

One thing to consider: 

1. Make many STAT instances

2. Make much fewer fvar instances, a controlled number

What are the real implications of that? :)

I'm guessing that it means that I need the latest software which reads the stat table will make use of those many instances, I wasn't aware of software which could read fvar and not stat... So I'm not quite sure what you mean :)

[Dave Crossland]

On Sun, Mar 1, 2020, 10:46 AM Adam Twardoch (Lists) <list...@twardoch.com> wrote:

It would be useful to standardowe od propose lists of STAT names. I think it might make sense to put e.g. 18 or more STAT instances for wght, not just 9, and similarly for other axes.

Do you mean with step instances of 50, which would then be 20 rather than 18 for a Roman, and matching 20 for Italic?

We should work on recommendations for naming — for new fonts. Designers will happily embrace it. 

And with fontbakery, we now have an easy way to check for these recommendations being implemented by new additions to the Google Fonts library, and with the front bakery dashboard and easy way to check the entire library and process upgrades at library scale across the entire dispatchment process from an upstream repo to production API. 

Then fvar instances should be a combination of the "more important" axis locations. Primary instances, you could say.

I think that is definitely a need for what we might call "star instances" which is a flag on named instances, however they are encoded, that is arbitrarily limited to say 10. Essentially it's like a musical bands best of album. Top of the Font's Styles, you might call Adam ;)

But STAT can have both primary and secondary instances, since the envisioned UIs for STAT let users pick each design aspect separately. 

Where can I read more about "the envisioned UIs"? 

Naming for STAT is a new thing and I'd love to collaborate on this. Let's just this opportunity to clean up ancient practices, and to propose some lingo for the 21st century. :) 

Want to make a proposal on Github.com/OpenType? :)

To view this discussion on the web visit https://groups.google.com/d/msgid/googlefonts-discuss/CAG32G7Oi4gQxH_LPjW6nwFY0cDyaCR8uvrwoD%2BUvo0Lp20wwiw%40mail.gmail.com.

[Adam Twardoch (Lists)]

There are currently no shipping apps, I think, that have a STAT-based style selection GUI. But since Microsoft defined the table *and* made it required, I imagine that they are working on such a GUI. 

The principal idea behind it is that you'll have as many dropdown lists as there are STAT axes, and each dropdown will only show and change the given style attribute. 

So in a font with wght, wdth and ital, you may have: 

- 18 STAT instances for wght, and their names will show in the "Weight" dropdown

- 10 STAT instances for wdth, and their names will show in the "Width" dropdown

- 4 STAT instances for ital, and their names will show in the "Italic" dropdown. 

And that's fine, none of these dropdowns will be crowded. 

But if we were to make a permutation, that would give us 18*10*4 = 720 fvar instances that would appear in an oldstyle "Styles" dropdown. That's overkill. 

So instead, it’d be better to pick the "primary" STAT instances to create the permutation: 9 out of the 18 

--

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/CAOgqPYf9zm4f3NhAeNpG1gU5a%2Bzz1-RmpG%3DmO0Hn7KO_RUAn6Q%40mail.gmail.com.

[Adam Twardoch (Lists)]

...weights, 3 of the 10 widths and 2 of the 4 italic values. Then permute to 9*3*2=54 fvar instances. And have those as fvar instances, so in traditional GUIs that have one big list of style names, the VF would "only" have 54 entries. 

But then, still, in those yet-to-come STAT-based GUIs, there would be 3 "style" dropdowns for a 3-axis font, and those can give the user more fidelity in name-based style selection. 

Less fidelity than sliders, but that's the idea: sliders are overkill for most users (too many choices), a massive style list made via permutation is also too many choices. The STAT-based GUI is supposed to serve as a sweet spot. 

STAT is also supposed to make global formatting changes easier: you may have text with emphasized portions made with a different weight and italicization, then you select all text and you see "mixed" in Weight, "Normal" in Width, "mixed" in Italic dropdown. Change Width to "Semi-condensed" and all width changes, but the emphasis remains. 

With the style-based single dropdown, this is currently impossible — it's a problem that has existed for many users who use Adobe’s big families in InDesign etc. 

Semi-standardization of primary and secondary axis instance names (style "words") would make it even easier. I imagine that some document formats will store the STAT names in the text, just like .docx stores PANOSE today. 

A.

[Thomas Phinney]

My comments about the unwieldiness of hundreds of styles was for fvar, which is normally displayed as a single list. Contrary to Pablo, that is not just about Microsoft Word, but about traditional style menus in general. And even without any app bugs, I have found having 200+ styles troublesome to work with. If that is my experience, even while knowing the typeface very well, I suspect that an average user will have much more difficulty.

I totally agree with Adam as regards with big multi-axis designs: plenty of STAT stop-points, fewer fvar instances. I'd love to have more than three stops on the Y-opaque (contrast) axis, but it would be madness to do that in fvar for this typeface.

T

You received this message because you are subscribed to a topic in the Google Groups "Google Fonts Discussions" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/googlefonts-discuss/XCHD21yi4KI/unsubscribe.
To unsubscribe from this group and all its topics, send an email to googlefonts-dis...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/googlefonts-discuss/CAG32G7M07u94%2BThK0ErkafLf%3D9vZ%2BftojrZmavrHwqBPG7FBWg%40mail.gmail.com.

[Stephen Nixon]

Might tiered font style menus help to solve many of these problems? For example, see how macOS toolbars can have multiple tiers if folders are used, as in Chrome bookmarks.

As a thought exercise, would anything need to be added to OpenType to allow UI categorization like this?

On Thursday, February 27, 2020 at 6:21:10 AM UTC-5, Marc Foley wrote:

We're going to release several multi axis variable fonts very soon. I'm starting to believe that having too many instances is a terrible idea. From a user perspective, the choice is just overwhelming and the scrolling is a pita.

There's more...

Personally, I'd just like Thin-Black + Italics + 2 widths as instances (that's already a max of 54). If I want to tweak the x-height or play with opsz, I should be able to adjust sliders.

The maths is also hilarious. If we take a family which is Thin-Black that's 9 instances, throw in Italics that's 18, now add an opsz that's 36, and x-height that's 72, ahh let's add 5 widths that's 360 instances. 

How are other people handling this?

Dave, have we done any UX tests for this issue?

[Thomas Phinney]

Although that tiered-menu UI is fine with just two axes, imagine it with three, four... or six or more. It will rapidly become unusable. I think even three would be pretty rough, and I expect three-axis fonts to be ... not too uncommon. I’m in the late stages on a four-axis font right now.

Cheers,

T

--

You received this message because you are subscribed to a topic in the Google Groups "Google Fonts Discussions" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/googlefonts-discuss/XCHD21yi4KI/unsubscribe.
To unsubscribe from this group and all its topics, send an email to googlefonts-dis...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/googlefonts-discuss/eee78f5f-29c0-4f9d-867a-4fb3c02d9518%40googlegroups.com.

[Stephen Nixon]

True, for some fonts, this could potentially get unwieldy if the designer *really* goes all out and gives instances along every possible axis. However, this could simplify a few important ones:

• Italic/Oblique instances (slnt/ital) would go with weight instances.

• Optical sizes could be automatic in apps like Word, PowerPoint, etc.

It wouldn’t replace sliders, just allow most fonts to be sane in the font style menu.

What are the instances in Science Gothic, again?

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/CAO6Fj1XSC1DHB1EmajCpuXB-DPfiRmL20Q%3DVxBfti214pTi8Qg%40mail.gmail.com.

--

——

Stephen Nixon 

stephennixon.com

[Stephen Nixon]

Or rather, what are the axes?

--

——

Stephen Nixon 

stephennixon.com

[Thomas Phinney]

Weight, width, slant, and y-opaque (contrast)

To view this discussion on the web visit https://groups.google.com/d/msgid/googlefonts-discuss/CABPmd4kiNYLD8dK%3D6zS4H7id9GP4uP1qAryhKQEuyi-MBymaQw%40mail.gmail.com.

[Stephen Nixon]

Yeah, so I guess that might have one extra tier, if you have contrast instances.

Science gothic

- width

  - contrast

    - weight & slant

Depending on how many widths and contrasts you have, though, maybe those two tiers could work in one menu.

To view this discussion on the web visit https://groups.google.com/d/msgid/googlefonts-discuss/CAO6Fj1VhW-WHKrMN%3DcAsM%2BEKjWCUm-XDjEvqMiNQQfRVCedB%2BQ%40mail.gmail.com.

--

——

Stephen Nixon 

stephennixon.com

[Thomas Phinney]

I think the tiered-menu model is just not a good one, because it will break with too many fonts. 

It would be improved slightly by adding font data that specifies how the axes are handled in the tiers, to yield fewer tiers. But that would make fonts behave differently even when they have the same axes, so it feels pretty chaotic to me. As a user, I would hate that.

One menu per axis seems reasonable to me. No extra data required.

T

To view this discussion on the web visit https://groups.google.com/d/msgid/googlefonts-discuss/CABPmd4mzmBmA_aeQjS4omR2WTHgGkVX9xL06Lz1b%2BzgBLLMggQ%40mail.gmail.com.

[Stephen Nixon]

Hmm, “one menu per axis” is a really interesting idea, and could indeed help limit the explosion of menus.

Two l possible issues I see with that approach:

1. It would shift the conceptual model of finding the font you want. It would go from the current “filter for a single specific style” to “apply multidimensional properties,” similar to axis sliders. 

2. Font menus often show each font name with its own style applied. This would be possible in a tiered menu, but possibly much harder and less easy to understand if each axis had its own menu (the style previews would have to depend on the current selection, rather than being preset).

The one-menu-per-axis concept would be simpler to use than sliders in that it would at least constrain options.

Something brought up in a conversation was the idea of sliders with specified stopping points, which would align to instance locations. Names could appear based on the slider location. Basically, this segmented slider might be akin to one-menu-per-axis.

To view this discussion on the web visit https://groups.google.com/d/msgid/googlefonts-discuss/CAO6Fj1WnNyCQqm6mkXE3n6v4-s5_j%3DCKhmdyUn_L-fR3Oz_P_A%40mail.gmail.com.

--

——

Stephen Nixon 

stephennixon.com

[Pablo Impallari]

each font familly will be en up being like a little app...

To view this discussion on the web visit https://groups.google.com/d/msgid/googlefonts-discuss/CABPmd4novp2ydjZS2jBo-4g%3Dj3m1UVPdAXoz%2BMw29J9ML3SWpQ%40mail.gmail.com.

[Thomas Phinney]

One complication is that the primary instances are only defined in one place, so that’s what shows up in all interfaces. Thus at the font level I feel stuck defining a set of primary instances I expect to work well across all interfaces, and not *only* in especially clever ones.

I am not convinced there exists any really good solution for this, at least with the current OT spec. I can imagine a future OT spec might allow a more extensive set of instances for savvy interfaces, but that isn’t something we could do today....

T

To view this discussion on the web visit https://groups.google.com/d/msgid/googlefonts-discuss/CABPmd4novp2ydjZS2jBo-4g%3Dj3m1UVPdAXoz%2BMw29J9ML3SWpQ%40mail.gmail.com.

[Adam Twardoch (Lists)]

Well, that's **exactly** what the STAT names are for. 

The STAT table has a list of axes (in a particular order), and has named points on those axes. An app can easily build tiered submenus from that. 

And the OT spec makes STAT mandatory for variable fonts and optional for static fonts. So a static font family may include naming that is organized exactly the same way, and can be easily represented in tiered submenus. 

A.

To view this discussion on the web visit https://groups.google.com/d/msgid/googlefonts-discuss/CABPmd4novp2ydjZS2jBo-4g%3Dj3m1UVPdAXoz%2BMw29J9ML3SWpQ%40mail.gmail.com.

[Adam Twardoch (Lists)]

If a font's STAT table first lists the wght axis with 7 entries, then the wdth axis with 3 entries, then the first submenu could list the 7 wght entries, and when you hover over one, then the 2nd submenu could list the 3 wdth entries. If the font’s STAT has the axes in a different order, then the first submenu would list the widths, and then the 2nd-level submenu would list the weights. 

Whether nested submenus are good UX is another matter, but spec-compliant variable OpenType fonts have this data, and font makers can also add this data to static fonts. 

[Adam Twardoch (Lists)]

Note: the real limitation of the current OT spec is that all its machinery works well only with orthogonal user locations, i.e. where, in the user-facing axis values, all numeric axis locations map to names in the same way, regardless of values of other axes. 

So with STAT, you can say "Black" is always 900 and "Condensed" is always 80.  FontLab 7 calls these named locations "axis instances".

You can vary the interpolation speed using the avar table, but also only uniformly per axis. 

In the fvar named instances, you can say Black Condensed is 900,80 but Light Condensed is 300,85. That's something you cannot do with STAT, and it's something STAT should not really let you do. 

In type design, you listen need to tweak various axis combinations (distort a multidimensional mesh) for good optical results, but all that should be done inside the font. 

We do need an avar version 2 table that will map a perfectly orthogonal mesh onto the distorted one, and that would support all kinds of distortions. But all this should be done transparently to the user. 

Without avar v2, the font vendor needs to produce a font with quite a few intermediate masters — which is already perfectly possible, you just need a skilled font engineer.

IMO, the user should ALWAYS be able to use 80 for Condensed and 600 for Semibold throughout the entire design space. 

And for that, STAT already gives you axis instances — a neat mechanism for giving names to points of interests along each axis. And STAT lets you do style linking. And it works per family (so you may have 2 or 5 or 9 variable and/or static fonts, each doing something, and all names show up in one well-organized UI).

For more info about STAT:

- 

https://docs.microsoft.com/en-us/typography/opentype/spec/stat

- 

https://github.com/daltonmaag/statmake/blob/master/README.md

- 

http://help.fontlab.com/fontlab/7/manual/Variable-Fonts/

- http://help.fontlab.com/fontlab/7/manual/Working-with-Font-Variations/

A.

[Dave Crossland]

On Sun, Mar 8, 2020 at 6:04 PM Adam Twardoch (Lists) <list...@twardoch.com> wrote:

IMO, the user should ALWAYS be able to use 80 for Condensed and 600 for Semibold throughout the entire design space. 

This isn't possible. 

https://docs.microsoft.com/en-us/typography/opentype/spec/dvaraxistag_wdth says,

Scale interpretation: Values can be interpreted as a percentage of whatever the font designer considers “normal width” for that font design.

But this is impossible to implement across a range of opsz: In Roboto Extremo, today, if you go to 600/80 at opsz default and max, you'll see very different amounts of narrowing; the percentage of the normal is completely off. 

600/80/14

600/80/144

If you go to 600/25, the problem is even worse. 

600/25/14

600/25/144

[Adam Twardoch (Lists)]

In theory it's alwsys possible. We just need a table that maps one set of numbers to another.

I mean: the notion that wdth is "percentage" is silly. This is a special case, I always voices my opposition towards this way of writing the spec. Because... percentage of what? "m" may change its width very differently than "l".

So — I think we need to give up on the strong idea of % anyway. But the user should still be able to have the "Condensed" named component be expressed as 80 or whatever, regardless of other axis settings, rather than the numeric value jumping around. And that's something avar2 should deliver.

:)

--
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/CAOgqPYcvev2Pz45eqNO_TnDg2d%2B9CAyiJX1Jap7vdSDRZhaX2w%40mail.gmail.com.

[Dave Crossland]

On Mon, Mar 9, 2020 at 11:23 AM Adam Twardoch (Lists) <list...@twardoch.com> wrote:

In theory it's alwsys possible. We just need a table that maps one set of numbers to another.

But that table isn't part of the OT1.8 spec, right?

So — I think we need to give up on the strong idea of % anyway.

Fair enough :)

 

But the user should still be able to have the "Condensed" named component be expressed as 80 or whatever, regardless of other axis settings, rather than the numeric value jumping around. And that's something avar2 should deliver.

I don't understand how this makes sense, at all. 

I think the user should be able to have the "Condensed" named component be expressed as the correct numeric value, whatever the value system, which means 'jumping around' - because the range of width (and weight) is necessarily much longer at 144pt than 14pt. 

Cheers

Dave 

[Adam Twardoch (Lists)]

On Mon, 9 Mar 2020 at 16:47, 'Dave Crossland' via Google Fonts Discussions <googlefon...@googlegroups.com> wrote:

On Mon, Mar 9, 2020 at 11:23 AM Adam Twardoch (Lists) <list...@twardoch.com> wrote:

In theory it's alwsys possible. We just need a table that maps one set of numbers to another.

But that table isn't part of the OT1.8 spec, right?

No, absolutely not, and that is indeed a problem for quite a few projects. 

 

But the user should still be able to have the "Condensed" named component be expressed as 80 or whatever, regardless of other axis settings, rather than the numeric value jumping around. And that's something avar2 should deliver.

I don't understand how this makes sense, at all. 

I think the user should be able to have the "Condensed" named component be expressed as the correct numeric value, whatever the value system, which means 'jumping around' - because the range of width (and weight) is necessarily much longer at 144pt than 14pt. 

Ah :) 

Now, you do raise a valid point. 

Actually, opsz is a good example. Let's take opsz a wght (weight). A very realistic case: you have a family with opsz that goes from 6 to 144. And there is also a wght axis. 

A sensible designer might design the 144 opsz end so that you can go on wght from Thin 100 to Black 900, right? In large sizes, the family can vary in weight for display purposes. 

At the 6 opsz end, Thin or Black have no place. A sensible designer might want to give you the range of, say, Regular 400 to Bold 700 only. 

This gives a design designspace that is trapezoid. 

The non-existent avar2 also plans to allow you to make trapezoid designspaces, so you could have the min-max of wght at the 6 opsz between 400 and 700 but the min-max of wght at the 144 opsz end could go between 100 and 900.

That's what everybody would want, because that would be predictable. And somehow (don't know how), a "Semibold" should always be 600, no matter what I choose on opsz.

But that's not really possible. Today, we have to cheat. Min-max (fvar), and the "speed change of interpolation" (avar) are per axis. 

So if you design your own trapezoid designspace (100-900@144 to 400-700@6), you need to orthogonalize it in the VF: 

Your design wght Regular 400 master at 6 opsz must become VF wght Thin 100, and your design wght Bold 700 master at opsz 6 must become VF wght Black 900. 

So you go from a trapezoid design designspace to a rectangular VF designspace by STRETCHING (pulling apart) the narrow end of the trapeze. 

And from here, you have TWO strategies: 

Strategy 1. Put well-named predefined instances at non-spec-conformant location and, well, screw STAT. This is the simple way that you would use if you just made a static family, and can still work with VF 

Make fvar instance "Caption (Regular)" at opsz 6 wght 100 (!) and the fvar instance "Caption Bold" at opsz 6 wght 900. Dont make "Caption Thin", "Caption Light", "Caption Black" at all. 

Then at the opsz 144 end you make fvar instances "Poster Thin" at wght 100, "Poster Light" at 300, "Poster (Regular)" at 400, "Poster Bold" at 700, "Poster Black" at 900. 

Since Caption Bold is at 6 900 and Poster Bold is at 144 700, for all the intermediate fvar instances along opsz, you need to skew the numbers (Subhead Bold would be at 24 832 or something)

With this, you cannot make a sensible STAT, because in STAT, the Bold axis instance always needs just one number (700, or any other if this was a different axis).

Strategy 2. Make the UX better but bloat the font.

As we discussed, if your design designspace is trapezoid, you must make a rectangular VF designspace by pulling the narrow end apart. Your design wght Regular 400 master at 6 opsz must become VF wght Thin 100, and your design wght Bold 700 master at opsz 6 must become VF wght Black 900. 

But! Now, you could insert a 2nd master at opsz 6 wght 400 that is IDENTICAL to your opsz 6 wght 100 master, and you insert a master opsz 6 wght 700 that is identical to your opsz 6 wght 900 master. 

Therefore, at the opsz 6 end, you get no movement between wght 100 and 400, and no movement between wght 700 and 900. 

With today's tools, you cannot easily add intermediate VF masters that have a finite region (VF allows them but .designspace format does not). So you need those "counterbalances": 

At opsz 144 wght 400 and at opsz 144 wght 700, you have to insert masters that are pure interpolations between your really designed opsz 144 wght 100, and opsz 144 wght 900, in those wght coordinates. Let's call them "virtual masters". 

So you start with a trapezoid design designspace with 4 masters, and you go to a rectangular VF designspace with 8 masters: 4 at corners (identical to your design masterz), 2 at the opsz 6 end that are IDENTICAL to the outer masters there, and 2 at the opsz 144 end that are INTERPOLATED. 

This way, you effectively have a rectangle that has your design trapezoid inside, and then has two triangle "fillers" that are DEAD. They do not cause a change. 

With this setup, you can make a nice STAT where Thin is at 100, Light at 300, Regular at 400 etc. If I choose a STAT-based opsz Caption, I get opsz 6, and then I'll be able to choose STAT-based Regular (400) but also Light (300) and Thin (100), but they'll give me the same visual result. So it's OK. 

And you can make fvar instances that are still orthogonal in their principle, but you simply OMIT any fvar instances from the dead filler triangles. So there will be no "Light Caption" or "Thin Caption" fvar instance. 

There will be a "Thin"+"Caption" STAT-based combination, but it'll be OK since it'll yield the same result as "Regular"+"Caption", which would be your "Caption" fvar instance. 

Now — is that more less clear? 

:) 

Best,

Adam

[Adam Twardoch (Lists)]

Here is a very simplified analogy between the two strategies I mentioned and world map projections. 

Left: Strategy 1, stretch to fill, just 4 corners but the coordinates change as you travel towards the shorter edge of the designspace, and STAT is problematic. VF has worse UX but is smaller.

Right: Strategy 2, make dead filler triangles, needs extra masters but the coordinates are kept and STAT works nicely. VF has better UX but is bigger. 

Adam

[Sam Berlow]

From a user perspective, is opsz option necessary in a font menu?
Wouldn’t it be easier for a user if opsz was selected by font size?

[Johannes Neumeier]

Hey,

For example Wordpad will use STAT table defined locations and display them in the font menu as if they were distinct fonts. So offloading the problem off too many fvar instances to the STAT table does not really work.

As I understand the real advantage of the STAT table would be to define names for on-axis ranges and have apps automatically generate a predefined name for any axes location combination (e.g. see where on the wght, wdth, and opsz axes we are and generate the order and most appropriate value for each as the generated font name, like “Acmefont Subhead Condensed Medium”). Not that I am aware of any implementations of this...

On 1. Mar 2020, at 17.59, 'Dave Crossland' via Google Fonts Discussions <googlefon...@googlegroups.com> wrote:



To view this discussion on the web visit https://groups.google.com/d/msgid/googlefonts-discuss/CAOgqPYfN3UHmjPshT7CGDcK0NjA2G1rtZuB_CKo2_um82%2Bx7aw%40mail.gmail.com.

[Johannes Neumeier]

On Thursday, 27 February 2020 19:15:52 UTC+2, Dave Crossland wrote:

Does the STAT table allow style-familiy packing like "Family OpSz Width - Weight" for Adobe/Apple apps?

Adobe apps seem to ignore the STAT table altogether.

If you leave the fallback accessibility aside, my personal take would be predefined instances as a way to show the design space extremes or essential stops, rather than a matrix of all axis possible stops. E.g.:

• Text (Regular)
• Display (Regular)
• Condensed (Regular)
• Expanded (Regular
• Regular
• Italic
  

Either the axes UIs become accessible and familiar in apps eventually, or users will feel confused about what is so variable in a font anyway. The instances work as a shortcut to set one axis to a location of interest, the sliders are used to set stops the "secondary" etc. dimension.

The way the STAT table should work is that you get a generated name for your font based on your axes selection — not just the other way around.

[Laurence Penney]

Thinking of these areas as dead zones seems to assume that the glyph should resolve to the same visual instance all around the perimeter of the zone: a single point (instance) in real designspace expands into a defined area in user designspace.

Yet if we look at the “dead zones” in the classic Univers chart (italics removed for clarity), this is not the case, is it? The question for the undefined zones of Univers is, I think, “in which direction should they clamp”? Thinking of Frutiger’s digits as weight and width in a STAT table, is Univers “89” the same as Univers 59 or Univers 83? Or, does the old chart make more sense if we visualize Frutiger’s instances as nodes rather than squares and use diagonal edges to mark the perimeter?

- L

On 9 Mar 2020, at 19:44, Adam Twardoch (Lists) <list...@twardoch.com> wrote:

Here is a very simplified analogy between the two strategies I mentioned and world map projections. 

Left: Strategy 1, stretch to fill, just 4 corners but the coordinates change as you travel towards the shorter edge of the designspace, and STAT is problematic. VF has worse UX but is smaller.

Right: Strategy 2, make dead filler triangles, needs extra masters but the coordinates are kept and STAT works nicely. VF has better UX but is bigger. 

<IMG_8830.jpg>

-- 
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/CAG32G7PbdB%2BaaJXYr068AFmPVYSeLuPLi5HZs11ZRnhP5mWP3A%40mail.gmail.com.

[David Berlow]

Adam,

‘’A sensible designer might design the 144 opsz end so that you can go on wght from Thin 100 to Black 900, right?’’

Right.

‘’At the 6 opsz end, Thin or Black have no place.” 

We don’t agree, and the spec does not really allow the two ends of opsz to have different os/2 wght ranges.

As we can only make a designspace where the parameters are trapezoid but the values are orthogonal, we have made it so. The typographer has 100-900 at all sizes, and they all work at all sizes. 

This allows the programmatic use of all wghts, as well as a predictable set of matching wghts at all sizes, which has virtues when a style ramp needs to be abbreviated for mobile, e.g.

[Thomas Phinney]

For a “normal” or “average” app, automatic is good enough. Everyday text editor. Maybe even MS Word.

Especially savvy apps (InDesign, Illustrator), or apps with odd sizing needs (PowerPoint, Photoshop), should offer some way to set it manually.

T

On Mon, Mar 9, 2020 at 4:47 PM Sam Berlow <samuel...@gmail.com> wrote:

From a user perspective, is opsz option necessary in a font menu?
Wouldn’t it be easier for a user if opsz was selected by font size?

--
You received this message because you are subscribed to a topic in the Google Groups "Google Fonts Discussions" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/googlefonts-discuss/XCHD21yi4KI/unsubscribe.
To unsubscribe from this group and all its topics, send an email to googlefonts-dis...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/googlefonts-discuss/d8b2cde4-71a2-4cf4-b122-7923bcb5a4b5%40googlegroups.com.

[Dave Crossland]

On Mon, Mar 9, 2020, 9:05 PM Thomas Phinney <tphi...@cal.berkeley.edu> wrote:

For a “normal” or “average” app, automatic is good enough. Everyday text editor. Maybe even MS Word.

Especially savvy apps (InDesign, Illustrator), or apps with odd sizing needs (PowerPoint, Photoshop), should offer some way to set it manually.

People make posters with word processors all the time. 

There probably needs to be a simple "freeze automatic axis adjustment" button that works to pause not just font-optical-sizing:auto but anything that adjusts any axis automatically. 

[Adam Twardoch (Lists)]

You’re right, there is an ambiguity 

In my example where the designer has made these design masters:

- opsz 144 wght 100 (Poster Thin)

- opsz 144 wght 900 (Poster Black)

- opsz 6 wght 400 (Caption Regular)

- opsz 6 wght 700 (Caption Bold)

and we make dead triangles, the legitimate question is what the opsz 6 wght 100 master should be a duplicate of: 

- opsz 6 wght 400?

- opsz 144 wght 100? 

Both are possible on theory. So we need to sort axes by UX importance, and pick the most important (most expected) result. 

I’d argue that in the axes combination opsz 6 wght 100, the opsz axis should triumph, so opsz 6 wght 400 should be duplicated there. Basically a more useful "fallback" for the non-existent "Caption Thin" is "Caption Regular", not "Poster Thin". 

So we choose to preserve optical size and relax on weight. 

In case of Univers, I’d argue that preserving width and relaxing weight is more important, so 43 should = 53 (not 45), and 89 should = 59 (not 83). 

As a general rule, in a multiaxis design, the fallback in dead triangles should preserve the parameter that is most dramatically changing the nature of the text, or, to say it differently, the parameter which the user would least likely vary within one line of text or even a word. 

Weight is flexible, it's used within one line. An unwanted weight change is not considered a strong deviation from the user's intent. 

But unwanted change of optical size, width and italicization or slant is a stronger deviation. So in a font with wght & ital, I’d preserve ital. In a font with wdth & ital, I’d preserve wdth. 

I’d sort the registered axes: opsz > wdth > slnt > ital > wght. The earlier ones have higher priority of preservation. 

Another way of looking at this is: what is the order of choices when you’re styling particular text? 

Opsz is first, because text always has some size. 

Then is wdth, because that's usually dictated by size and available space, and you rarely mix widths within one line. 

Then, slnt & ital (you really want to preserve italicization or slant if it's needed for emphasis — in some cases that's almost orthographic). 

And then wght — in most cases, while some variation in wght is emphasis, the overall choice of wght is purely aesthetic. If under some combinations of axes the ultrathins and ultrablacks aren't available, the user will settle for the next-best thing. 

There may be project-specific deviations from this way of thinking, but I propose this as a sensible default direction of thought.

A.

To view this discussion on the web visit https://groups.google.com/d/msgid/googlefonts-discuss/822A4B58-5C03-4C60-8965-B9393E387231%40gmail.com.

[Dave Crossland]

But Adam, there ought to be a opsz 6 wght 100 that is lighter than the 400 - as light as makes sense for that pt size. 

[Pablo Impallari]

The thing is that for Variable Fonts....

we no longer have "The User".....

Now we have "The User".... and "The User".

I meand... now IOS are users of the fonts... Apps, Menus, Uis, automated-whatever-shit--- will be "The User" of the fonts.....

And we also have "The Users"... as always.... human people.

I'm right?

El lun., 9 mar. 2020 a las 23:55, 'Dave Crossland' via Google Fonts Discussions (<googlefon...@googlegroups.com>) escribió:

But Adam, there ought to be a opsz 6 wght 100 that is lighter than the 400 - as light as makes sense for that pt size. 

--

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/CAOgqPYdu2p2FnN_wJG8VPWF0%2BtdP0_jAki-6ku1OCAS4-0zqvw%40mail.gmail.com.

[Adam Twardoch (Lists)]

As I said, this is for a scenario where the design is so that at opsz 6 there is only a designed range of wght 400-700, and at opsz 144 there is a designed range of wght 100-900. You can replace the 400 with 200, 300, that doesn't matter. 

Let's say you have designed an opsz 6 Regular at 400 and an opsz 144 Regular at 400. Then you also envision, at opsz 144 a Light at 300, an Ultralight at 200 and a Thin at 100. And you also want a Light at opsz 6, which is 300. But you don't want anything lighter. 

When the user chooses STAT Light, he should get your designed Light (300) whenever the point size changes with font-optical-sizing: auto or when the user moves an optical size slider. 

But when the user chooses STAT Thin, at 144 aka large point sizes he should get your designed Thin (100) but at small sizes there is no design lighter than what you've designed as Light for that size. 

So at 6 pt, with STAT Thin (100) you should get the same effect as with STAT Light (300), and you'll get that with the dead triangle.

Same goes for wght+wdth: 

At wdth 150 (STAT Ultrawide) you may get a real wght range from Thin 100 to Black 900. But at wdth 75 (STAT Ultracond) the designer may have designed a weight that is visually consistent with Ultrawide’s Extrabold (800), and nothing bolder, because the design dictates so. 

So you make a dead triangle between {wdth 150 wght 900}, {wdth 75 wght 900} and {wdth 75 wght 800}. You duplicate {wdth 75 wght 800} and insert it as {wdth 75 wght 900}, and at {wdth 120 wght 800} you insert an appropriate interpolation that comes from between {wdth 120 wght 900} and {wdth 120 wght min}.

That's how you deal with different visual ranges at different axis combinations. 

If you go with the method 1, i.e. put your very very black thing at {wdth 150 wght 900} but a not-so-black thing at {wdth 75 wght 900}, then when the user chooses STAT Semibold (600) and changes the width, he’ll get a visual weight reduction that may be undesired. 

With static instances, designers solved it differently — they just choose appropriate interpolation values. 

They were doing this: 

( This is from Łukasz Dziedzic’s app  

https://github.com/typoland/InstancesCalculator/blob/master/README.md )

But you cannot really do this in VF, not without avar2. Right? 

BTW, there is no "ought to". Some VFs cover only the wght range 300-700 or 400-700 or 400-600, some will cover 200-800 or 100-900. 

There is no reason why a VF cannot, visually, cover a wght range 100-900 at high point sizes but only 300-700 or even 400-700 at low point sizes. In fact, this is true for most existing designs with optical sizes. Look at Slimbach’s work. 

A.

On Tue, 10 Mar 2020 at 03:55, 'Dave Crossland' via Google Fonts Discussions <googlefon...@googlegroups.com> wrote:

But Adam, there ought to be a opsz 6 wght 100 that is lighter than the 400 - as light as makes sense for that pt size. 

--

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/CAOgqPYdu2p2FnN_wJG8VPWF0%2BtdP0_jAki-6ku1OCAS4-0zqvw%40mail.gmail.com.

[Adam Twardoch (Lists)]

Ps. with static fonts, vendors simply shipped more weights for the high opsz and fewer weights for the low opsz. But you cannot do that with VF.

E.g. Carter’s Miller Text has 3 weights but Miller Banner has 5 weights: 

https://store.typenetwork.com/foundry/cartercone/series/miller?family=miller-text,miller-banner

Because that’s the designer’s intent, and because it makes sense. Provided the designer is making an actually useful design, not extrapolating senselessly to “fill a grid plan”. ;) 

[Adam Twardoch (Lists)]

Much of Slimbach’s earlier work was gridaxed because the fonts were released as MMs. But his OT-only work is different: 

Garamond Premier goes Regular to Bold in Caption opsz but Light to Bold in Display opsz (and you can easily imagine it going further out):

https://fonts.adobe.com/fonts/garamond-premier

Arno also goes light (and could go black) only in high opsz: 

https://fonts.adobe.com/fonts/arno

Brioso was issued as MM, so it is gridaxed. It has light weights even in Caption, and aptly shows that gridaxing can work, of course — if that is the designer’s intention. In Brioso, the Caption opsz varies in weight moderarely while the Poster opsz varies more (though I also cannot shake the feeling that it could go bolder). 

https://fonts.adobe.com/fonts/brioso

The point is that we need to employ different strategies depending on the design. 

This is especially important with opsz — with automatic font-optical-sizing, the fonts at small sizes should, above all, be readable. I should be able to choose Light or Thin as my general weight, and when the text scales, get readable results. If the distinction between Thin and Light goes away at small sizes for the reasons of readability — that’s fine. That’s what happened with metal type and with other quality methods. 

The numbers are secondary. The reader is paramount. 

A.

[Adam Twardoch (Lists)]

My specific recommendations for the original auestion about desktop font naming: 

1. Ship the multiaxis desktop VFs as TTCs. This way you can even put separate upright & italic VFs into one file, and you have flexible control over naming. 

2. Consider the most optimal ordering of axes. In my view, for desktop naming, it should be opsz > wdth > wght > slnt/ital.

3. Each TTC subfont should have a separate 'fvar' and 'name' table. In the fvar, the axis definitions should be identical but the predefined instances should not. 

4. Put the opsz names into the family name is each TTC subfont, and possibly even the wdth name. Only put wght, slnt/ital names into fvar instance names. This is what most foundries do for statics (Font Bureau, FontFont etc.). Even Adobe have done it with Minion 3, after years of cramming huge numbers of styles under one family name. 

5. All TTCs should have a common STAT. The axes should be ordered the same way there as above. 

6. Make a generous list of STAT axis instances per each axis (e.g. 18 weights instead of 9) but limit the number of TTC subfonts (families) and the fvar instances per subfont to a slightly lower resultion so you don't overwhelm the users who use old-style style-name-based font section mechanisms. 

7. Think about how people use desktop fonts. 

A.

[Laurence Penney]

À propos of STAT, this thread might be interested in trying Samsa’s new STAT controls, which went live earlier today. Load a font, open the STAT panel, choose instances by selecting from one menu per axis, click “Add instance” if you want to save it in the Instances list. I’m still prettying up the UI.

Works well with IBM Plex Roman, for example.