Case sensitive forms in calt or case?

Hi all,

I have read this older thread about including case sensitive forms of certain glyphs (that thread veered a bit off-topic, and my question is a bit tangential to it, so I’m starting a new thread); it got me wondering: Is it common practice to put case specific substitutions (like for parens, dashes) into the CASE feature? I worry that this approach would be pretty fragile, considering that many people may never actually use the CASE feature but just TYPE IN ALL-CAPS, which would then not trigger the substitutions.

How about a CALT feature instead that substitutes these glyphs if they have nothing but caps, punctuation and spaces around them (or; no lowercase). Does anyone do this? Thinking it might be a bit hairy to determine the exact permissible trigger sets, but if that can be worked out such an approach could be more bulletproof? Curious to hear opinions.

Comments

  • Chris LozosChris Lozos Posts: 1,458
    I do this with hyphens so that the hyphen height is determined by the preceding character's case.
  • kupferskupfers Posts: 259
    edited August 2015
    I remember there was a thread or discussion somewhere about the calt feature for this in relation to Apple’s new SF fonts and it raising the : between numerals. (Oh wait, it was on Twitter and Kai Bernau was in involved. I’ll try to find it.) I remember he came up with some pretty good examples why calt is not really a bullet proof way. But I agree that most people will never use the case feature either : /

    Somewhere around this tweet it was 
  • Interesting, Indra, thanks. Yurgh, yeah, the up-and-down bouncing is no good – to be honest I had been thinking about just not doing case sensitive forms at all, but… but… at least the at seems almost compulsory.
  • Chris LozosChris Lozos Posts: 1,458
    Even though {case} is not used by everyone, perhaps it is used often by those who care most about their typography. Since type is no-longer only set by trained typographers, I think we must include the tools for those who would use them and hope we can educate the others who care to know?
  • Mark SimonsonMark Simonson Posts: 1,652
    The case feature is enabled when you apply the “all caps” style in InDesign (cmd/ctrl-K).
  • The case feature is enabled when you apply the “all caps” style in InDesign (cmd/ctrl-K). 
    True. But it isn’t applied when changing the text to all caps via the Type > Change Case > UPPERCASE option. And the same goes for the <cpsp> feature. How two different options that claim to do the same in InDesign produce such different results is beyond me.
  • attarattar Posts: 209
    edited August 2015
    That’s not a problem, it’s up to the user to decide whether the composition justifies the use of case-sensitive forms. e.g. sometimes when you don’t use caps on the whole line you might want to leave it off
  • Mark SimonsonMark Simonson Posts: 1,652
    edited August 2015
    Well, using the change case option is like applying formatting to text (size, weight, etc.) directly instead of using style sheets. It's sort of the dumb way to do it. There may be use cases where it makes sense*, but generally, the "all caps" style is smarter and more flexible. It's right on the character format palette, whereas the convert option is in a submenu. Plus, it can be part of a style sheet.

    * In the past, I've used the change-to-lowercase option to undo a client's gratuitous use of all caps text, for example.

    Even if the text is entered in all caps, applying the all caps style will invoke the case feature. Of course you need to know it works that way to know to do it.
  • How two different options that claim to do the same in InDesign produce such different results is beyond me.”

    They don't claim to do the same thing. That's why there are two different options. One of them formats text as uppercase. The other converts text to uppercase character codes. Generally the former is preferable, but occasionally the latter, depending on what one is doing.
  • Paul van der LaanPaul van der Laan Posts: 242
    edited August 2015
    Thomas – technically you are correct. But from a UX point of view this kind of ambiguity should be avoided, don’t you think?
  • I wonder if this is something the Adobe typography interface people have addressed. I’d bet (/hope) it is.
Sign In or Register to comment.