Workflow query: two instances: 1) .sc as lowercase, 2) normal lowercase

Glyphs
1

Scenario:

  • Have a typeface that uses small caps (.sc glyphs) as both small caps and lowercase.
  • Creating a normal lowercase addition.
  • Want to export instances that include:
    Original version with .sc for both small caps and lowercase.
    New version with .sc for small caps and the normal lowercase.
  • Features remain the same for both, in this example.

What’s a recommended workflow to managing that scenario?

It seems like the best method, for now, might be to do the following:

  • Start with current .glyphs file that has lowercase using .sc glyphs as components, i.e., /a is made up of simply the /a.sc component.
  • Rename the current lowercase glyphs (that are really small caps) to .lowersc and set to not export.
  • Put new lowercase designs in lowercase glyphs.
  • New instances (with typical lowercase design) will be similar to original instances.
  • Change old instances (that want small caps as lowercase) to use the Rename Glyphs custom parameter to swap the .lowersc with the actual lowercase slot, e.g., a.lowersc=a.

Part of the reason to move the current small caps acting as lowercase glyphs to .lowersc is that there are some variants that don’t exist in the typical lowercase design, e.g. /i.hist.

Though I’m not yet sure if this is reasonable, if a Copy Glyphs custom parameter existed, then I could consider the following workflow:

  • Master with .sc, normal lowercase designs, and no extra non-exporting glyphs.
  • For the instances with small caps also acting as lowercase, include a Copy Glyphs parameter with things like a.sc=a in it.
2

Why do you you need small caps glyphs of the default lowercase already look like small caps? I would build a font with regular lowercase and small caps and then use two instances. One exports the font as is and the other removes the lower case, renames the small caps and removes the smsp feature.

3

Some software loses the applied OpenType feature when switching to a font that doesn’t support that feature. So, this is partially to make things simpler for the user. If they’ve formatted text with a selection in small caps, switch to the small caps instance of this font (that doesn’t have the smcp feature) then switch back to their prior font, that selection of text will no longer be set in small caps. TextEdit is one example.

There’s a part of me that likes to preserve the semantics when possible.

Thanks for the suggested workflow.

4

But why do you ship the small cap instance I think the first place. It might be an option for the web, where OpenType support is still spotty. But for desktop fonts?

5

The historical inspiration was an all caps typeface. Also, when the font is used in console terminals and historical computer/operating system emulators, there’s no use of OpenType. Many of those users want the caps design. The lowercase design is also a new addition, long after the original release.