Closed davelab6 closed 5 years ago
I very much appreciate the concern the PM offered, but I object on the following grounds:
With that said, because of the potential opacity of the names for users, how users interact with Lexend in UI clearly needs the proper structure and design to communicate effectively.
What we can do is assign width values within the named instance fonts. This will ensure font menu interfaces will at least order the named instances in the correct ordinal order. Assigning inside the font table progressive width values will work because font menu UIs order by Weight, Width, and Slope as reported on Glyphs tutorial page
The change of width values does not have to be stated in the font name; We just need the font menu UI's to understand the ordinal order of the named instances. See attachment
Sorry to say, Google Docs (a) doesn't support Variable Fonts, neither axes or named instances, (b) doesn't support width styles within a family, only weight (and roman/italic), (c) orders weights by number, and ignores the style names within a family.
What Docs does support is a set of single-style families, where all non-weight style information is baked in the family name. And family names are sorted alphabetically in Docs' font menu interfaces.
The only way for the Docs font menu UI to understand the ordinal order of the named instances is to name them in a way that an alphabetical sort matches the ordinal order. Eg,
Is there a reason we are focusing on Google Docs? Was the PM with the initial suggestion from the Google Doc team?
The majority of fonts available in GSuite are from Google Fonts, with a minority licensed (eg Comic Sans), and working well in GSuite is important to Google Fonts :)
Fair enough. I see how this is handled with fonts like Roboto:
This would be a fair expectation if how users would select Lexend in the same manner. That is not the case. Users need the context of being prescribed a personalized setting that fits best for them based on fluency.
Especially in the context of a lack of VF support in Google Docs, this points to the need for a plug-in or API to give users the proper context to find the right Lexend font and have it apply to to GSuite. In the Lexend Arabic proposal, I spoke about this need/ direction in creating a fluency calibrator.
As you can tell, we will need way more discussions to see if this is even possible. And naturally, if such API or plug-in solutions are untenable, the naming solution will have to be reconsidered.
I believe to give users the best experience using Lexend, we need a more robust solution than to strip down the font names because of Google Doc built in limitations.
Sadly that's not viable as a blocker. I want to publish the font in Google Fonts this month, and while a Docs Extension can indeed act as a progressive enhancement to offer a fluency calibration UX (and @micahbrich should be capable to produce that as its all web stack stuff) it can't block the launch or be assumed to be available.
How about this?
Lexend Lexend 1 Deca Lexend 2 Mega Lexend 3 Giga Lexend 4 Tera Lexend 5 Peta Lexend 6 Exa
After talking it out with Bonnie and exploring other naming options, we have decided to stick with the orders of magnitude names, but order based on alphabet:
Deca (Regular) Exa Giga Mega Peta Tera Zetta
Oooooooh Zeta, that one's cute. ✨ -- Micah Rich https://micahrich.com
Great! This will annoy some nerds, but that's better for me. Please make this update so @m4rc1e can onboard them :)
@ThomasJockin is it "Zetta" or "Zeta"? I'll change the names today.
Build updated
A product manager interested in this project is keen to have the static family (or the list of named instances in the variable font) be ordered logically when they are ordered alphabetically. I can see the value in that especially as most people don't know the order of the scale words used....