Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Following FontBakery style naming requirements can yield excessively long names #2793

Open
tphinney opened this issue Mar 12, 2020 · 2 comments
Assignees

Comments

@tphinney
Copy link

tphinney commented Mar 12, 2020

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.

InDesign font menu

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:

Screen Shot 2020-03-12 at 12 05 28 PM

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.

Screen Shot 2020-03-12 at 12 11 35 PM

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

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

@m4rc1e
Copy link
Collaborator

m4rc1e commented Mar 12, 2020

Thanks for posting this.

I'll raise this issue again tomorrow. Since "Expanded Bold Oblique" we need a solution.

@felipesanches
Copy link
Collaborator

related to #2254

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants