User opinions on an encoding dilemma

cerulean's picture

While poking at the unfinished parts of a face that is still not ready for release, I'm taking another look at the core alphabets and wondering if they need to be reorganized. It's a unicase which has cap and lower forms for A/a, E/e, N/n, U/u, and Y/y, and caps for the rest. These are all lining. But I also have descending swash-tailed versions of J, Q, and R, which at present reside in the capital slots. Should I move them? Because this is my thinking:

1. Users may want to set it as no-nonsense allcaps, and will want that to be as easy as turning on capslock.
2. Still, most users who want the unicase will probably want solid lining, too, as easily as not pressing shift or capslock.
3. But duplicating the first J, Q, and R and relegating the second to an Opentype feature is just erecting barriers to people who aren't using InDesign — still a significant part of the market, I think.

What do you think? How would you want it if you were using it?

riccard0's picture

Descenders on lowercase: the discerning user of a unicase doesn’t always want solid lining (and can easily hit caps-lock).
Plus, if one of those letter is in the name, it makes a nice showing.

Frode Bo Helland's picture

The case feature kicks in with Caps Lock or selecting all capitals, but not when using the Shift button. That’s nice for OT savvy application, but surely not bulletproof. You could write a calt feature that checks if the pre- and proceeding characters are capitals (or punctuation/spaces), and swap the swash variant for a straight capital variant. The downside is: what if someone wants to write a word in all caps including your swash?

cerulean's picture

Thanks, I think I'm convinced. I'll move the tails to the lowercase. Then, to use them with capslock on, shift would still work. For those who want to try the face on a longer piece of normal text and not accentuate every single r, I can make an OT alternate set of the lowercase.

Syndicate content Syndicate content