You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I know we are in a new age when there may no longer be common apps/environments that actually fail* when confronted with style names of >31 characters. And yet ... extremely long style names are still problematic for numerous reasons.
FontBakery enforces the idea that style names are not allowed use abbreviations, but must always use fully expanded names, even with variable fonts, regardless of the number of axes. But a style such as “MaximumContrast UltraCondensed ExtraLight Oblique” is a pretty darn long string. Obviously I could abbreviate the parts that FontBakery does not even recognize, but that still isn’t always enough for pleasing results.
Even if apps did not have problems with super-long strings (see below), after extensive use of the same font built both ways, I can attest that moderate abbreviations are a major enhancement to usability. It is much easier to visually scan and distinguish the list of styles in a pop-down menu or other list, when each item has half as many characters.
Actually, MS Word does have some issues still, which I have not fully studied. But they don’t seem to be what I would call a complete failure to work with the styles affected.
Observed behaviour
Many app interface elements display the font style in a box of limited width, until/unless a pop-down is clicked on. This initial width cannot accommodate extremely long style names, even for apps that have generous limits.
When style names are truncated, there can be sets of font styles that are impossible to fully distinguish in the menu listing, because all you can see is the first n characters, which are the same.
Adobe InDesign has a generous style width, but it is still not enough to contend with fully-expanded names.
Even in the pop-down listings and font menus, there can be a maximum width for the style name in the menu, in some apps. Microsoft Word on the Mac is especially bad in this regard:
Font Playground does not allow arbitrary fonts to be dynamically added by users. But even though it is specifically designed for variable fonts, it would clearly overflow when presented with longer names.
Axis-Praxis does accommodate the longest names in Science Gothic in the menu display, albeit only barely:
Of course, another option is to not have premade styles, or restrict which ones are put in the font, because of FontBakery’s requirements. I found myself doing that when deciding which styles to instantiate in 'fvar'; surely that should not be driving these decisions.
Allow sensible abbreviations. It would be OK to dictate what abbreviations are allowable, just so long as they exist. I would be happy to help come up with some guidance.
Fonts with more axes might benefit from (relatively) more extreme abbreviations—although I am not certainly suggesting a return to the days of "BI" as an abbreviation for Bold Italic.
I know we are in a new age when there may no longer be common apps/environments that actually fail* when confronted with style names of >31 characters. And yet ... extremely long style names are still problematic for numerous reasons.
FontBakery enforces the idea that style names are not allowed use abbreviations, but must always use fully expanded names, even with variable fonts, regardless of the number of axes. But a style such as “MaximumContrast UltraCondensed ExtraLight Oblique” is a pretty darn long string. Obviously I could abbreviate the parts that FontBakery does not even recognize, but that still isn’t always enough for pleasing results.
Even if apps did not have problems with super-long strings (see below), after extensive use of the same font built both ways, I can attest that moderate abbreviations are a major enhancement to usability. It is much easier to visually scan and distinguish the list of styles in a pop-down menu or other list, when each item has half as many characters.
Observed behaviour
Many app interface elements display the font style in a box of limited width, until/unless a pop-down is clicked on. This initial width cannot accommodate extremely long style names, even for apps that have generous limits.
When style names are truncated, there can be sets of font styles that are impossible to fully distinguish in the menu listing, because all you can see is the first n characters, which are the same.
Adobe InDesign has a generous style width, but it is still not enough to contend with fully-expanded names.
Even in the pop-down listings and font menus, there can be a maximum width for the style name in the menu, in some apps. Microsoft Word on the Mac is especially bad in this regard:
Font Playground does not allow arbitrary fonts to be dynamically added by users. But even though it is specifically designed for variable fonts, it would clearly overflow when presented with longer names.
Axis-Praxis does accommodate the longest names in Science Gothic in the menu display, albeit only barely:
![Screen Shot 2020-03-12 at 12 11 35 PM](https://user-images.githubusercontent.com/6548266/76558997-8dadca80-645b-11ea-9c15-b17e5ed1384d.png)
Of course, another option is to not have premade styles, or restrict which ones are put in the font, because of FontBakery’s requirements. I found myself doing that when deciding which styles to instantiate in 'fvar'; surely that should not be driving these decisions.
(Parallel issue, for my reference: googlefonts/science-gothic#241)
Expected behaviour
Allow sensible abbreviations. It would be OK to dictate what abbreviations are allowable, just so long as they exist. I would be happy to help come up with some guidance.
Fonts with more axes might benefit from (relatively) more extreme abbreviations—although I am not certainly suggesting a return to the days of "BI" as an abbreviation for Bold Italic.
Resources and exact process needed to replicate
See current font at https://github.com/tphinney/science-gothic/blob/master/fonts/variable/FontLab/ScienceGothic%5BYOPQ%2Cwdth%2Cwght%2Cslnt%5D.ttf
The text was updated successfully, but these errors were encountered: