Case sensitive forms

Martin Silvertant

Thanks for the recommendation. I added this kind of feature in a stylistic set to replace /x with a multiply symbol in certain contexts for a typeface I did for a client but I realize when the typeface is changed, everything reverts back to all the things I want to avoid. I guess a type designer shouldn't exert control over the errors the end user will make. It's better to use the multiply symbol in the first place.

Jackson Showalter-Cavanaugh

FWIW, it's common typographic practice to use a plain 'x' instead of the multiplication symbol in text.

Martin Silvertant

What do you mean by it's common practice? I know I see it everywhere in shopping windows, but it's wrong. Mind you, the feature I made for it only turned on when an x is preceded by a number and space and followed by a space and a number. When there is no space after the number, it could as well be an x instead of a multiply symbol in a mathematical context. I did give the client a warning for its use, but I've actually made up my mind about it; I have a meeting planned with the client next week when he will get the full set of fonts and an update on the ones he already had, so I will make sure the feature is removed.

David Somers

Just because its common, it doesn't mean its right... it like people using inch and foot marks instead of real quotes (my pet peeve of sloppy typography). Of course, this leads to the dilemma of whether features should be added to a font to allow for the lack of ability in the end user use the right glyphs.

Martin Silvertant

That's why I made the features, but on second thought it's just not a proper solution. It has some adverse effects, like the fact that the end user may feel he can continue using incorrect typography because his typeface fixes his sloppiness anyway, just like some if not most people care less about the accuracy of typing in at least some contexts because spell check fixes their sloppiness anyway. If all typefaces did that it might come closer to a proper solution, but I don't think it's the type designer's job to prevent the mistakes the end user might make.

Jackson Showalter-Cavanaugh

Hucholi 40:52

Martin Silvertant

I just don't agree with that. Besides, I feel the extra emphasis is absolutely not obtrusive in this context. From my perspective, the second example just looks amateurish.

Martin Silvertant

Also, who or what's Hucholi and why is this an authority on the subject?

Kent Lew

I think Jackson mistyped. He probably meant “Hochuli” — as in Jost Hochuli.

Jackson Showalter-Cavanaugh

≥≤

Albert_Jan_Pool

Although I think that Hochuli is a very, very good typographer, I do not agree with his statement on the use of x for the multiply sign ×. In his example the × is a bit too large, too obtrusive indeed. At Scangraphic the mathematical signs were originally far too large and centered on the cap height. When Volker Küster (Today Sans Serif) became type director he decided that the mathematical signs should be made a little bit smaller than the x-height and they were centered on the x-height. I continued his system and found out that it is difficult to match them with the weight of the figures and the lower case characters, especially for typefaces with stroke contrast. After some trials we thought it was a good idea to start from the e-bar and/or the en-dash. Finally we ended up with a multiple master like tool, programmed by Jelle Bosma. It interpolated a range of mathematical signs to the desired weight and width. The width was identical with that of the table figures, which worked out fine with most typefaces. We made an exception for some of the condensed faces, here the mathematical signs on the figure width appeared too small, so we chose a larger width for them.
Creating an extra set of mathematical signs which is centered on the cap height and making them available through the case feature is not a good idea, I think. Maybe it would work better within a lining figures feature, but in many cases, even lining figures will usually be set within a typographic structure that is dominated by mixed setting. Lining figures are already obtrusive enough with in such a structure. Adding larger and higher positioned mathematical characters to that destructs such structure and makes things worse. Yes, one could think of all caps typography in which larger mathematical signs centered on the cap height would look nice, but I think these cases are rare. And, first of all, I would rather question that kind of typography before investing additional efforts in again another variation of characters that should rather be used for mathematics instead of polluting our typographic environment ;–)

ondrejtregler

Mark Simonson said:

A simple way to do it is as a substitution. Create alternate glyphs designed to look good in all caps settings using copies of the default glyphs, and then do something like this: feature case { sub hyphen by hyphen.case; ...etc. It's also possible to do it by modifying the positions of the glyphs rather than doing substitutions, but I've never tried it.

That is exactly what I did but it doesn't work. I'm new to this so I'm probably doing something wrong but can't figure out what. Am I supposed to have defined classes before I start making features?

Mark Simonson

How is it not working? Can you expand on this?

Regarding classes, you don't need them when you make features, but they are more convenient in situations where the feature involves more than single glyphs.

For instance, for the case feature, you might do something like this:

   sub hyphen by hyphen.case;
   sub endash by endash.case;
   sub emdash by emdash.case;

Instead you could do this:

   sub [hyphen endash emdash] by [hyphen.case endash.case emdash.case];

Or you could turn these lists into classes like this:

   @dashes = [hyphen endash emdash];
   @dashes_case = [hyphen.case endash.case emdash.case];

...and then do this:

   sub @dashes by @dashes_case;

For what it's worth, I don't usually use classes for the case feature. I usually do it like the first example.

ondrejtregler

In case feature I did exactly this:

sub endash by endash.case;

I did some more reading and I figured (if I understood) that this feature is supposed to work when you apply a paragraph style to the text but it's not working when you change the case in type menu in Indesign or you just write it with Caps Lock on. Is that right? 

Now I have tested it and it's working with the paragraph style in ID but still not working in Word.

Thomas Phinney

Ondrej has perhaps figured that out, but for others wondering: the 'case' feature works in InDesign when you format text as uppercase. Not when you change the case permanently, not when you write with caps lock on.

Nick Shinn

All-caps formatting (Apple keyboard): Select the text and apply command-shift-k

Also useful—
Small-caps formatting: Select the text and apply command-shift-h