Number (figure zero) Spacing vs Capital Letters - 144pt opsz - all weights all widths

[EbenSorkin]

A repeated explanation for context: Because numbers are read individually and letters are mostly not the spacing of numbers should be slightly more generous than capital letters.

This is a note about if that's happening the right amount or not

Regular width This is OK in spacing terms. However, the numbers feel quite a bit too narrow vs caps overall. Zero for sure, but the others too. This will look especially odd in a UK zip code like CB4 3EW.

wght: 100 | wdth: 100 | slnt: 0 | GRAD: 0 | opsz: 144 This is OK in spacing terms. However, the numbers feel too narrow vs caps overall too

wght: 900 | wdth: 100 | slnt: 0 | GRAD: 0 | opsz: 144 This looks OK

Narrow width wght:400|wdth:25|slnt:0|GRAD:0|opsz:144 This zero has less loose spacing than O. It should be slightly more than O.

wght: 100 | wdth: 25 | slnt: 0 | GRAD: 0 | opsz: 144 This zero has less loose spacing than O. It should be slightly more than O.

wght: 900 | wdth: 25 | slnt: 0 | GRAD: 0 | opsz: 144 This spacing looks ok

Wide width wght:400|wdth:151|slnt:0|GRAD:0|opsz:144 This looks OK but just slightly looser would be better.

wght: 100 | wdth: 151 | slnt: 0 | GRAD: 0 | opsz: 144 This looks Ok but the stroke of zero feels heavier than O - so please check that.

wght:900|wdth:151|slnt:0|GRAD:0|opsz:144 This looks OK

I am leaving out the slanted for now because Santiago asked us to wait for the update.

[dberlow]

Thank you for your comments and suggestions as this is not only helping us find our mistakes, but educating us as to what other designers have Not Faced, and have not understood.

This is not new: "... numbers are read individually ../." This is: "...spacing of numbers should be slightly more generous than capital letters..."

If the figures are proportional, the space between 00 is put by FB between OO and oo. That is how we found the proportional figs and left them that way. (there are some errors in other designspace locations that we're working on in the prop figs to refine this).

But at FB, (and linotype and bitstream before that), we didn't and don't make the 00 looser than OO. Figures used alone typically have a wordspace on both sides, so why.

Tab figs, which are the DEFAULT in Roboto Flex, have an issue with vars that no one in or out of Google has stepped up to address, except me. In a variable font containing width, weight and size axes, and tabular figures, the tab width of every weight of a given opsz and wdth must match. So, we were directed to put wght100-wght1000 on The Same Tabular Unit per size and width.

Thus, the spacing of the tab figures starts out okay at 18, 400, 100, and has a little trouble with openness at 18, 100, but hey... However, wghts above 700, wdths below 85%, we're not having fun with tab figs. Foreseeing this, I included a tabular figure width axes (XTAB) in the 2016 proposal for additional axes, and thus informed the owners and users of the format extension that there is a problem the tech has not faced. It was, and has not been supported by a single type designer. Any suggestions!?

On Sat, Feb 5, 2022 at 12:29 AM Eben Sorkin @.***> wrote:

A repeated explanation for context: Because numbers are read individually and letters are mostly not the spacing of numbers should be slightly more generous than capital letters.

This is a note about if that's happening the right amount or not

Regular width This is OK in spacing terms. However, the numbers feel quite a bit too narrow vs caps overall. Zero for sure, but the others too. This will look especially odd in a UK zip code like CB4 3EW.

wght: 100 | wdth: 100 | slnt: 0 | GRAD: 0 | opsz: 144 This is OK in spacing terms. However, the numbers feel too narrow vs caps overall too

wght: 900 | wdth: 100 | slnt: 0 | GRAD: 0 | opsz: 144 This looks OK

Narrow width wght:400|wdth:25|slnt:0|GRAD:0|opsz:144 This zero has less loose spacing than O. It should be slightly more than O.

wght: 100 | wdth: 25 | slnt: 0 | GRAD: 0 | opsz: 144 This zero has less loose spacing than O. It should be slightly more than O.

wght: 900 | wdth: 25 | slnt: 0 | GRAD: 0 | opsz: 144 This spacing looks ok

Wide width wght:400|wdth:151|slnt:0|GRAD:0|opsz:144 This looks OK but just slightly looser would be better.

wght: 100 | wdth: 151 | slnt: 0 | GRAD: 0 | opsz: 144 This looks Ok but the stroke of zero feels heavier than O - so please check that.

wght:900|wdth:151|slnt:0|GRAD:0|opsz:144 This looks OK

I am leaving out the slanted for now because Santiago asked us to wait for the update.

— Reply to this email directly, view it on GitHub https://github.com/TypeNetwork/Roboto-Flex/issues/201, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAO5VDTPLGR5U54T2BCIVLLUZSYVDANCNFSM5NTPIEKA . You are receiving this because you are subscribed to this thread.Message ID: @.***>

[EbenSorkin]

comments inline

On Sat, Feb 5, 2022 at 7:30 AM David Berlow @.***> wrote:

Thank you for your comments and suggestions as this is not only helping us find our mistakes, but educating us as to what other designers have Not Faced, and have not understood.

This is not new: "... numbers are read individually ../." This is: "...spacing of numbers should be slightly more generous than capital letters..."

If the figures are proportional, the space between 00 is put by FB between OO and oo. That is how we found the proportional figs and left them that way. (there are some errors in other designspace locations that we're working on in the prop figs to refine this).

But at FB, (and linotype and bitstream before that), we didn't and don't make the 00 looser than OO. Figures used alone typically have a wordspace on both sides, so why.

Because a number like 1976 is equivalent to four words which normally each get a workspace between for clarity. e.g. "Nine Teen Seventy Six". A little extra space helps you parse this more rapidly.

I dig that maybe you didn't do what I'm suggesting is best practice at FB, LinoType or Bitstream. Indeed MS's Corbel is like Roboto with less and a similarly narrow set of numbers. Arial kind of does a tight set of numbers too.

But this little bit of extra space around numbers thing is seen frequently

• Verdana, The Apple SF OS font, Segoe, Georgia. It is I think even more common.

But leaving aside questions of precedent - when you have a flat curve it doesn't overshoot as high as a sharp one and when you have flat sided zero it needs more space for the same reason even if the impression you want to create is that of utter evenness and not the slight loosening I am advocating for.

The reason to change this is optical/perceptual especially if the basic shape idea of zero cannot change.

There is also a pressing question of "do we need to maintain the standard given" or "do we think we have the remit to say what think works "best"." I don't know how hamstrung we are.

My question to you would be given your freedom what would you do?

I know for my part I can only advise that numbers be made slightly looser because Roboto can be made more useful if we let it. More useful = higher quality to me.

Moreover what I was told to suggest is whatever seems to me to be the highest quality solution. IDK what you & Dave will do.

Tab figs, which are the DEFAULT in Roboto Flex, have an issue with vars that no one in or out of Google has stepped up to address, except me. In a variable font containing width, weight and size axes, and tabular figures, the tab width of every weight of a given opsz and wdth must match. So, we were directed to put wght100-wght1000 on The Same Tabular Unit per size and width.

Thus, the spacing of the tab figures starts out okay at 18, 400, 100, and has a little trouble with openness at 18, 100, but hey... However, wghts above 700, wdths below 85%, we're not having fun with tab figs. Foreseeing this, I included a tabular figure width axes (XTAB) in the 2016 proposal for additional axes, and thus informed the owners and users of the format extension that there is a problem the tech has not faced. It was, and has not been supported by a single type designer. Any suggestions!?

Fixing tabular sizes is sensible until you get past bold and very nuts as soon as you explore very heavy weights. Making numbers wider in the tabular form seems like the only way to make a black tabular figure that's not awful. But also maybe black tabular figures don't matter that much. Maybe the real use is inside the RBIBI design space. Letting the tabular numbers appear lighter than you might have expected but darker slightly than Bold would be one way to retain their usefulness.

I don't think that matching the figure's width across all opsz makes as much sense. But again, an even wider default tabular width would help.

The thing that seems the most crazy of all is having the default figures be tabular. Indeed, if I could choose between A) seeing the tabular figures treated as I suggest and B) changing the default numbers to proportional lining - I would go B all the way.

On Sat, Feb 5, 2022 at 12:29 AM Eben Sorkin @.***> wrote:

A repeated explanation for context: Because numbers are read individually and letters are mostly not the spacing of numbers should be slightly more generous than capital letters.

This is a note about if that's happening the right amount or not

Regular width This is OK in spacing terms. However, the numbers feel quite a bit too narrow vs caps overall. Zero for sure, but the others too. This will look especially odd in a UK zip code like CB4 3EW.

wght: 100 | wdth: 100 | slnt: 0 | GRAD: 0 | opsz: 144 This is OK in spacing terms. However, the numbers feel too narrow vs caps overall too

wght: 900 | wdth: 100 | slnt: 0 | GRAD: 0 | opsz: 144 This looks OK

Narrow width wght:400|wdth:25|slnt:0|GRAD:0|opsz:144 This zero has less loose spacing than O. It should be slightly more than O.

wght: 100 | wdth: 25 | slnt: 0 | GRAD: 0 | opsz: 144 This zero has less loose spacing than O. It should be slightly more than O.

wght: 900 | wdth: 25 | slnt: 0 | GRAD: 0 | opsz: 144 This spacing looks ok

Wide width wght:400|wdth:151|slnt:0|GRAD:0|opsz:144 This looks OK but just slightly looser would be better.

wght: 100 | wdth: 151 | slnt: 0 | GRAD: 0 | opsz: 144 This looks Ok but the stroke of zero feels heavier than O - so please check that.

wght:900|wdth:151|slnt:0|GRAD:0|opsz:144 This looks OK

I am leaving out the slanted for now because Santiago asked us to wait for the update.

— Reply to this email directly, view it on GitHub https://github.com/TypeNetwork/Roboto-Flex/issues/201, or unsubscribe < https://github.com/notifications/unsubscribe-auth/AAO5VDTPLGR5U54T2BCIVLLUZSYVDANCNFSM5NTPIEKA

. You are receiving this because you are subscribed to this thread.Message ID: @.***>

— Reply to this email directly, view it on GitHub https://github.com/TypeNetwork/Roboto-Flex/issues/201#issuecomment-1030614036, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAQUQXL3KAIOW4X3XRJQL3LUZUJ7LANCNFSM5NTPIEKA . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

You are receiving this because you authored the thread.Message ID: @.***>

[dberlow]

‘’ Moreover what I was told to suggest is whatever seems to me to be the highest quality solution.“

That’s fine. So you know our instructions when we began: Regular is correct and complete, and all other styles of the design space are to be of the same quality as regular.

This did not suggest to us that we could change the design to something else we liked better. The only exceptions to this, were if I could prove that a Regular glyph would work better with slight changes for 14 point, it’s newly anointed optical size.

There were 3-4 of these changes, but not any figures. So, a set of figures with one square-sided glyph, zero, was required to be expanded throughout a broad design space.

When this became impossible due to the tabular width running up against the new range of the weight axis, particularly at 144 pt, Google was informed.

I thank you again for your comments and assure you that we will make all the changes you have suggested that are within our reach.

As for swapping the prop and tab figs, it’s not in my reach, but GS Flex is already done that way, so there is hope, and danger, as Material design does not use OT features as far as I can tell.

On Feb 5, 2022, at 9:33 PM, Eben Sorkin @.***> wrote:

 comments inline

On Sat, Feb 5, 2022 at 7:30 AM David Berlow @.***> wrote:

Thank you for your comments and suggestions as this is not only helping us find our mistakes, but educating us as to what other designers have Not Faced, and have not understood.

This is not new: "... numbers are read individually ../." This is: "...spacing of numbers should be slightly more generous than capital letters..."

If the figures are proportional, the space between 00 is put by FB between OO and oo. That is how we found the proportional figs and left them that way. (there are some errors in other designspace locations that we're working on in the prop figs to refine this).

But at FB, (and linotype and bitstream before that), we didn't and don't make the 00 looser than OO. Figures used alone typically have a wordspace on both sides, so why.

Because a number like 1976 is equivalent to four words which normally each get a workspace between for clarity. e.g. "Nine Teen Seventy Six". A little extra space helps you parse this more rapidly.

I dig that maybe you didn't do what I'm suggesting is best practice at FB, LinoType or Bitstream. Indeed MS's Corbel is like Roboto with less and a similarly narrow set of numbers. Arial kind of does a tight set of numbers too.

But this little bit of extra space around numbers thing is seen frequently

• Verdana, The Apple SF OS font, Segoe, Georgia. It is I think even more common.

But leaving aside questions of precedent - when you have a flat curve it doesn't overshoot as high as a sharp one and when you have flat sided zero it needs more space for the same reason even if the impression you want to create is that of utter evenness and not the slight loosening I am advocating for.

The reason to change this is optical/perceptual especially if the basic shape idea of zero cannot change.

There is also a pressing question of "do we need to maintain the standard given" or "do we think we have the remit to say what think works "best"." I don't know how hamstrung we are.

My question to you would be given your freedom what would you do?

I know for my part I can only advise that numbers be made slightly looser because Roboto can be made more useful if we let it. More useful = higher quality to me.

Moreover what I was told to suggest is whatever seems to me to be the highest quality solution. IDK what you & Dave will do.

Tab figs, which are the DEFAULT in Roboto Flex, have an issue with vars that no one in or out of Google has stepped up to address, except me. In a variable font containing width, weight and size axes, and tabular figures, the tab width of every weight of a given opsz and wdth must match. So, we were directed to put wght100-wght1000 on The Same Tabular Unit per size and width.

Thus, the spacing of the tab figures starts out okay at 18, 400, 100, and has a little trouble with openness at 18, 100, but hey... However, wghts above 700, wdths below 85%, we're not having fun with tab figs. Foreseeing this, I included a tabular figure width axes (XTAB) in the 2016 proposal for additional axes, and thus informed the owners and users of the format extension that there is a problem the tech has not faced. It was, and has not been supported by a single type designer. Any suggestions!?

Fixing tabular sizes is sensible until you get past bold and very nuts as soon as you explore very heavy weights. Making numbers wider in the tabular form seems like the only way to make a black tabular figure that's not awful. But also maybe black tabular figures don't matter that much. Maybe the real use is inside the RBIBI design space. Letting the tabular numbers appear lighter than you might have expected but darker slightly than Bold would be one way to retain their usefulness.

I don't think that matching the figure's width across all opsz makes as much sense. But again, an even wider default tabular width would help.

The thing that seems the most crazy of all is having the default figures be tabular. Indeed, if I could choose between A) seeing the tabular figures treated as I suggest and B) changing the default numbers to proportional lining - I would go B all the way.

On Sat, Feb 5, 2022 at 12:29 AM Eben Sorkin @.***> wrote:

A repeated explanation for context: Because numbers are read individually and letters are mostly not the spacing of numbers should be slightly more generous than capital letters.

This is a note about if that's happening the right amount or not

Regular width This is OK in spacing terms. However, the numbers feel quite a bit too narrow vs caps overall. Zero for sure, but the others too. This will look especially odd in a UK zip code like CB4 3EW.

wght: 100 | wdth: 100 | slnt: 0 | GRAD: 0 | opsz: 144 This is OK in spacing terms. However, the numbers feel too narrow vs caps overall too

wght: 900 | wdth: 100 | slnt: 0 | GRAD: 0 | opsz: 144 This looks OK

Narrow width wght:400|wdth:25|slnt:0|GRAD:0|opsz:144 This zero has less loose spacing than O. It should be slightly more than O.

wght: 100 | wdth: 25 | slnt: 0 | GRAD: 0 | opsz: 144 This zero has less loose spacing than O. It should be slightly more than O.

wght: 900 | wdth: 25 | slnt: 0 | GRAD: 0 | opsz: 144 This spacing looks ok

Wide width wght:400|wdth:151|slnt:0|GRAD:0|opsz:144 This looks OK but just slightly looser would be better.

wght: 100 | wdth: 151 | slnt: 0 | GRAD: 0 | opsz: 144 This looks Ok but the stroke of zero feels heavier than O - so please check that.

wght:900|wdth:151|slnt:0|GRAD:0|opsz:144 This looks OK

I am leaving out the slanted for now because Santiago asked us to wait for the update.

— Reply to this email directly, view it on GitHub https://github.com/TypeNetwork/Roboto-Flex/issues/201, or unsubscribe < https://github.com/notifications/unsubscribe-auth/AAO5VDTPLGR5U54T2BCIVLLUZSYVDANCNFSM5NTPIEKA

. You are receiving this because you are subscribed to this thread.Message ID: @.***>

— Reply to this email directly, view it on GitHub https://github.com/TypeNetwork/Roboto-Flex/issues/201#issuecomment-1030614036, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAQUQXL3KAIOW4X3XRJQL3LUZUJ7LANCNFSM5NTPIEKA . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

You are receiving this because you authored the thread.Message ID: @.***>

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.

[davelab6]

Once the main tabular advance width becomes impossible to maintain across styles, why not allow it to shifts to remain useful for the current style?

[dberlow]

Eben and I spoke about all this monday. What you are suggesting has been mostly implemented.

First: The suggestions made on prop figs were good, and I followed them to the limits of the design’s existing state.

Since proportional figs will require no special user documentation, or use, and because GS, GS flex and Roboto serif have prop default figs, Roboto flex should follow.

Tabular figures at opsz8, the unit is constant. In opsz14, the unit goes as far as it can, and then all the figs of each style remain on the same unit, but the units increase to the end of the weight range. In opsz 144 it’s dicey from 600wght up, and in wdth25 there is still work to do.

But whatever happens in the tab figs, it is going to result in stylistic behavior requiring “design-space”documentation, which I think is a less-than-optimal thing to give users in the ascii repertoire — thus the suggestion for the figure switch to prop defaults.

[EbenSorkin]

I support allowing tabular figures to follow a flexible width in interpolation above 14 opsz.

It might be nice to have a bracket to keep the tabular figures the same width to 24 pt or something but that might be a fool's errand given how narrow it gets in thin narrow and how wide it gets in Wide Black.

-e.

On Tue, Feb 8, 2022 at 10:55 AM David Berlow @.***> wrote:

Eben and I spoke about all this monday. What you are suggesting has been mostly implemented.

First: The suggestions made on prop figs were good, and I followed them to the limits of the design’s exiting state.

Since proportional figs will require no special user documentation, or use, and because GS, GS flex and Roboto serif have prop default figs, Roboto flex should follow.

Tabular figures at opsz8, the unit is constant. In opsz14, the unit goes as far as it can, and then all the figs of each style remain on the same unit, but the units increase to the end of the weight range. In opsz it’s dicey from 600wght up, and in wdth25 there is still work to do.

But whatever happens in the tab figs, it is going to result in stylistic behavior requiring “design-space”documentation, which I think is a less-than-optimal thing to give users in the ascii repertoire — thus the suggestion for the figure switch to prop defaults.

— Reply to this email directly, view it on GitHub https://github.com/TypeNetwork/Roboto-Flex/issues/201#issuecomment-1032763241, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAQUQXNKDAWDDXEFRJWTR63U2E4FZANCNFSM5NTPIEKA . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

You are receiving this because you authored the thread.Message ID: @.***>