OT examples of case-sensitive italics?

eliason's picture

Some italic cap designs are swashier than others, and often the more cursive/fluid ones do not look good in all-cap settings.

Are there any instances of traditional-looking typefaces with alternate forms for italic caps based on case context? That is, caps would take one form in normal use and a different one in all cap settings (through a case and/or contextual alternates feature)?

I know that there are typefaces with two entirely different italic sets (one more cursive than the other), but here I'm referring to alternates contained in the same font file and triggered by OpenType.

Cristobal Henestrosa's picture

In some Adobe fonts (such as Minion Pro Italic), if swashes are selected and you try to set a text in all caps, they take the default form, ignoring the swashes order.

But probably you are referring to typefaces where the swash caps are the default.

Nick Shinn's picture

I've made a couple of types with italic “all-swash cap” designs, where the intent is to produce a full set of lightly flourished capitals for use in both mixed case and all-cap settings. But these are triggered by the Swash feature, not the Case feature. (Oneleigh, Scotch Modern)

kentlew's picture

As I recall, Bill did something like this with the italic A in Williams Caslon Text. Download the OT Features PDF from the features tab at FB’s site and check the Case features (not in {calt} ).

hrant's picture

ATF's Baskerville.

hhp

riccard0's picture

I remember at least one thread where different caps styles for all-caps vs. mixed case were discussed. But it was about size and colour ("normal" caps looking too big/dark compared to lowercase, especially in context where the former are abundant, like in German). And the design was a (neo) grotesque. But maybe it could be useful for evaluating the right OT feature.

William Berkson's picture

Here's the treatment of the A's that Kent mentioned. The "falling over" A of Caslon's italics works as an initial letter, but in the middle in all-caps it creates distracting holes. The alternative A for all caps fixes that. And of course you can always choose it if you don't like the traditional A. The All Caps instruction also spaces them out a bit.

John Hudson's picture

Bill, what happens if you set the word AACHEN?

William Berkson's picture

John ALICE italic above is without 'all caps' turned on. If you set AACHEN without all caps turned on you will get both 'falling over A' versions. If you have all caps on, they will both be the more upright version. Of course you can also mix and match from the glyphs palate and track out to your taste, kern as well for titles...

Cristobal Henestrosa's picture

> The All Caps instruction also spaces them out a bit.

Bill: For achieving this effect the font includes two set of capitals, right? Just curious.

eliason's picture

Bill, none of this hinges on contextual code that determines the case of an ensuing letter, right? It's simply case/stylistic set features that are either on or off by choice of the user?

Frode Bo Helland's picture

Cristobal:

feature cpsp { # Capital Spacing
# Latin
pos @cpsp1 <5 0 10 0>;
} cpsp;

dezcom's picture

You can also use contextual alternates and set up classes that will or will not allow a substitution. For instance, if a glyph would crash with a certain swash, it would be part of a class of similar glyphs.

Here is a snippet where the class "No_dcndr" are all glyphs without a decender:

sub @No_dcndr @No_dcndr y' by y.tail.long;
sub @No_dcndr y' by y.tail.short;

William Berkson's picture

Cristobal, I used the 'cpsp' to space them out, as Frode says. You don't need another set of caps just to track them out. Though I don't know, another set of caps might be more ideal because then you could kern the more widely spaced set of caps to one another differently in the wider setting than in the narrower. I've never explored that possibility.

Craig, yes I just used the 'case' feature to turn on the alternative A, like the alternative dashes, Spanish exclamation points, etc. I did a lot of stuff with CALT, but here I thought there were so many possibilities of how to mix the alternates that I figured just a simple 'on' or 'off' for all caps was best. Then if the typesetter wanted to get more fancy they could use the glyph pallet.

dezcom's picture

Craig, Cristobal and Bill,

I don't use cpsp anymore. I now positive kern my caps with each other using classes so that you will get the desired spacing even if the user does not select "All Caps" from the output software. There are not really any more kern pairs because I set right sidebearings of caps to fit lowercase thereby reducing some kerns there. Letters with gaps like T,V,Y, etc. need to be kerned anyway with lowercase so I set right sidebearings for them to fit caps.

kentlew's picture

Yes, the issue with {case} and {cpsp} is that, in current implementations, they both rely on users applying an All-caps styling.

In practical reality (in my sphere, anyway), many times all-caps text comes already set in capitals in manuscript; and most designers don’t think/care to go through and apply a redundant All-caps styling to them. So both {case} and {cpsp} features have no effect on those settings.

To this extent, other approaches — like additional kern classes instead of {cpsp}, or {calt} rules instead of {case} — are more robust solutions. But these are not fool-proof either. And figuring reasonable contextual rules for case-sensitive punctuation (many of which come in pairs — e.g., parens, braces, brackets, guillemets) can be quite complex.

Cristobal Henestrosa's picture

Thanks, Frode, I wasn’t aware of that possibility.

I guess I am with Chris on this one, positive kerning may be a very good option. I’ll give it a shot someday.

William Berkson's picture

Chris's solution will work well, unless the publication or user doesn't have kerning, or kerning turned on, in which case the all caps will look bad. Since that does happen pretty often, I don't think there's an obvious one best way. They all seem to have drawbacks.

dezcom's picture

If kerning is not turned on, any method will look bad. I am assuming the people who actually buy type have enough knowledge to use it well. If they don't, there is nothing I can do to help them.

Florian Hardwig's picture

Related:
Yanone’s Antithesis consists of three styles, a slab, a bolder sans, and a connected script – latter with seriffed caps. If you choose all-caps with the script, you get unseriffed italic caps. See figures 14 and 15: http://www.typemedia2011.com/yanone

William Berkson's picture

>If kerning is not turned, any method will look bad ... If they don't [have enough knowledge], there is nothing I can do to help them.

Well, there is something you can do to help, and note that the problem is often with the software, like older Word and some publication programs that don't even allow kerning, especially if I've got it right, open type class kerning, to be turned on.

Also are significantly different degrees of badness, so I still think there are trade-offs.

To analyze the trade-offs, let me call the one method "space caps first" and the other "positive caps kern."

First, notice that neither method is a "pure" method. At least the way I did it, I first had the right side bearings of the caps work decently with the n, o, and l. Then I adjusted the left side bearings of the caps to each other. And then I kerned the caps to one another, as well as of course caps to lower case. This results in a decently smooth spacing, with kerning off, and better with kerning on, but tighter than ideal for all caps.

The way you did the 'positive kern' method, you basically started the same way, but relied on kerning to make all the caps with visually even, wider spacing to each other. I'm not clear what you did about the right side bearings of the caps-were they all wider, to work with caps, or just the TVWY?

Without kerning you are either way going to have noticeable problems with T, V, W, Y to lower case, but with your approach, since you've given them wider right side bearings to start with, they are going to be maybe still worse.

But with the 'space caps first' method you are going to get the same kind of spacing you had in the metal type days. And that I think is going to look acceptable to most people, and better than the method you followed, if kerning is off.

The drawback of 'caps first' is that without the "all caps" turned on, the caps will be a little too tight. But note that if the person is really knowledgeable, and knows to use 'all caps', they will probably get as good a result as your method. Or they may not know about 'all caps' but will apply tracking to all caps words, and get the same result. So the drawback of 'caps first' is that the user will have to do an extra key stroke to get the wide spacing.

The drawback of the 'positive kern' method is that if the kerning is off, whether because the user doesn't know to turn it on or because of software, it will look worse. Also note that if they want to space out the caps in titles, they will lose all your kerning, and have more work custom kerning to get them right. So for that case the knowledgeable user will have more work with 'positive kern' method.

Another question is whether the tighter spacing plus tracking will be as good a result as kerning to the wider spacing. Kindersley thought so, but it may be that he's wrong and you can get a better default result the 'positive kern way.'

What do you think?

So, summing up the pluses and minuses:

Space caps first, user turns on 'all caps' or tracks caps:
+ without kerning you get 'metal' spacing, which is acceptable to most readers
+ with a knowledgeable user you get the same or nearly the same result as positive caps kerning
- the knowledgeable user has to do an extra key stroke for all caps.

Positively kern caps:
+ default caps setting looks good without extra key strokes for all caps or tracking. —Possibly better than space caps first method.
- if kerning is off all caps looks bad
- if caps are letter spaced, extra work kerning for knowledgeable user.

So I think there are significant drawbacks to either method. I was inclined to use the positively kern caps method, as you have, but a certain individual I will call the 'Vineyard Yoda' declared that if you don't space caps first you will never get them right. And being Yoda, I figured he knew about a few more pluses and minuses.

After all this analysis, it occurs to me that you could combine both methods: space caps to each other at the tighter intervals dictated by caps-to-lower case, but then use kerning to space out all the caps. Would this be the best?

I still don't see a conclusive case for one approach.

dezcom's picture

@ Bill >>After all this analysis, it occurs to me that you could combine both methods: space caps to each other at the tighter intervals dictated by caps-to-lower case, but then use kerning to space out all the caps. Would this be the best?
---

That is exactly what I do.

By setting only the right sidebearing to fit with lower case, I minimize the bad possibilities.

The issue is that I prefer to aim my production to the users of more current software and assume the old stuff will fade away.

You can't please everybody so you might as well please your best customers first. They are the ones who notice and appreciate it.

The Jedi foundry of which Yoda is "founder", has many decades of customer-base to please and accommodate so it is much harder for them to do. I am such a FNG that I don't have customers before the 21st century ;-)

Though I greatly admire it, the Force is not with me, I am sad to say. I am klinging-on to the Millennium Falcon with duct tape and fed by Java without the hut :-)

William Berkson's picture

>That is exactly what I do.

Ok, that makes sense. Next time around, I'll see what Yoda proclaims :)

hrant's picture

> You can't please everybody so you might
> as well please your best customers first.

Bingo.

hhp

Syndicate content Syndicate content