Shouldn't italic be an OpenType feature?

Adam Jagosz

Imagine an upright design that relies heavily on precise spacing. As in, spaced really tight. A black design, a condensed design, doesn't matter. Now how do I go about designing an adequate italic companion? Obviously I will have plenty negative sidebearings which will one way or another collide when set immediately next to an upright glyph.

In practice, italic is set in isolation, so the most of an issue is collision with punctuation. Italic and upright in a single word happen mostly in logotypes and are kerned manually.

But I can imagine a discrete italic axis in a variable font so that the kerning can be included within the font. Has that been done?

Mark Simonson

And then no one will ever use italics because they will be buried in a submenu of a submenu. (Kidding, but not totally.)

Adam Jagosz

That is true about all OpenType features. Tough world. The font technology is messed up like everything in this world.

Small capitals work this way. You can either use the fake ones, or make the effort of digging the submenus for the real thing. With italics, things could be doubled to provide quick italics for most needs and polished italics for nerds. Of course, you are right that it's a waste of time and effort because no one will make the effort and use it.

Programs in the future might detect if a font has real small capitals, real subscript and superscript and use that instead of the faked ones. The problem with that is, that most fonts don't provide a full character set for these features. So the "fake" features must remain independent.

George Thomas

"...provide quick italics for most needs and polished italics for nerds."

As if the world needs something else to add to the degradation of typography -- as practiced by those with typographic knowledge, or as you refer to them, "nerds".

Kent Lew

Italic in the same font as Roman is a conceptual component of the variable font format.

David Jonathan Ross recently explored this in an interesting way: https://djr.com/notes/roslindale-variable-italic-font-of-the-month/

Mark Simonson

Currently, if you click on the small caps button in InDesign (at least), it will enable the OT small caps, if present. Otherwise it fakes it. I think the same is true of superscripts, subscripts and a few other things. Presumably, the same could be true with italics, but I wouldn't hold my breath.

John Hudson

Italic in the same font as Roman is a conceptual component of the variable font format.

Weeeeell...

The existence of italic as a registered OT variation axis is a byproduct of the STAT table design. The STAT table is intended to replace the name table as the mechanism by which the relationships between members of a font family are defined, which is why the OT 1.8 spec not only introduced this table as a requirement for variable fonts but also recommended it for static fonts. The idea is that in future we won't need to keep adding new fields to the name table every time software makers come up with some new family model or font makers come up with new design relationships.

Some common aspects of conventional font family relationships, such as weight and width, can now be handled either in separate fonts or via variation axes, and in the STAT table these are identified as Axis Records, even if the STAT table is being used to define relationships between static font family members. It may be a little unintuitive, but the STAT table sort of applies the concepts of internal variable font relationships to non-variable fonts, so each static font is treated as if it were an instance of a variable font.

On this basis, the working group decided that it would be a good idea for every STAT table axis record tag to have a corresponding variable font axis, so in a WWS (weight, width, slope) family model as used by e.g. Microsoft's DWrite text library, not only the weight and width would have registered axes, but also the slope. Hence, the Italic and Slant axes.

I'm not sure anyone in the working group really expected anyone to use the Italic or Slant variation axes. If we had, we would probably have spent more time checking whether the trigonometry worked.  

Adam Jagosz

Mark Simonson said:

Currently, if you click on the small caps button in InDesign (at least), it will enable the OT small caps, if present. Otherwise it fakes it.

You’re right, I forgot. That’s good. But superscript and subscript were faked and separate OT counterparts were in the OT submenu (at least in the 2015 version).

George Thomas said:

"...provide quick italics for most needs and polished italics for nerds."

As if the world needs something else to add to the degradation of typography -- as practiced by those with typographic knowledge, or as you refer to them, "nerds".

I'm having a hard time interpreting what you are trying to imply. All I meant was that the current implementation of italics is limiting, but it’s impossible to change that overnight. You did correctly decipher what I meant by “nerds”, though.

Denis Moyogo Jacquerye

There’s an 'ital' feature tag defined in the OpenType specification.

It’s UI suggestion is: “When a user selects text and applies an Italic style, an application should check for this feature and use it if present.” But I don’t know if this is implemented much.

George Thomas

@Adam Jagosz -- Not pointing any fingers at you. "Quick italics", or obliques/slants in my mind, are a pet peeve. Straight quote marks, especially in national ads, are another.

Andreas Stötzner

Why making things ever more complicated? I.m.h.o. the concept of variable fonts is good for nerds, perhaps only for them. The idea of putting small capitals into the main font is a bad one also, because when I select a name to set it in sc, also the initial capital gets changed – a mess. In practice, I don’t see any benefit arising from the change of the way we use Italics now.

Jens Kutilek

Adam Jagosz said:

But I can imagine a discrete italic axis in a variable font so that the kerning can be included within the font. Has that been done?

Kerning does not work between different instances of a variable font, sorry.

k.l.

Denis Moyogo Jacquerye said:

There’s an 'ital' feature tag defined in the OpenType specification.

It’s UI suggestion is: “When a user selects text and applies an Italic style, an application should check for this feature and use it if present.” But I don’t know if this is implemented much.

Exactly. A simple solution for a simple problem. Kerning between regular and italic glyphs is possible, too. (Addressing Adam Jagosz's question.)

Years ago I was told that this feature is meant for CJK fonts only. Possibly it is time to rethink this unnecessary restriction.

Thomas Phinney

It was intended for CJK fonts, in the sense that *existing* CJK fonts pre-OpenType already had both roman and italic western glyphs in a single CJK font. So being able to access these by a feature was seen as a useful thing. (CJK fonts don't need separate italic styles for anything else, so duplicating the rest of the font doesn’t necessarily make sense.)

So, I am not sure it is a “restriction”—but the existence of the feature is motivated by the history of how CJK fonts have been built.

k.l.

The OTL feature is there, regardless of how it came about, and is as easy to support as could be.
Variations and STAT, for something as trivial as the requested functionality, is more than over the top.

Khaled Hosny

TeX has a glyph metric called italic correction, which is value to be inserted between italic and non-italic text to compensate for the negative right side bearing of italic glyphs. OpenType does not have something equivalent (TeX engines that support OpenType fonts approximate it by using the difference between glyph bounding box and its advance width).

Jasper de Waard

Khaled Hosny said:

TeX has a glyph metric called italic correction, which is value to be inserted between italic and non-italic text to compensate for the negative right side bearing of italic glyphs. OpenType does not have something equivalent (TeX engines that support OpenType fonts approximate it by using the difference between glyph bounding box and its advance width).

I don't know about others, but I always center the lc italic 'o', so a fixed compensating value would not help. I think the problem occurs mostly when an italicized word is followed by an upright punctuation mark (usually period or comma), like @Adam Jagosz already pointed out.

Mark Simonson

The rule I learned (and maybe this is not true in all languages) was that punctuation should match the italicization (or not) that precedes it. I'm sure there are exceptions, but this will avoid the issue normally.

Adam Jagosz

@Denis Moyogo Jacquerye  Thanks, that's actually more of what I was asking about And to think I could've just googled that one. I only mentioned variable fonts because it's all the rage now, I don't personally have any experience with them, as Jens pointed out.

@George Thomas My wording was misleading, sorry. I didn't have in mind a fake italic slanted mechanically (I'm with you on that one); as quick italics I meant the true italic instance of the font in a separate font file (as usual), and for demanding users, buried in the submenu of a submenu, an OT solution with appropriate kerning.

There would be an issue in some designs with (j and f). I usually go for a contextual alternate rather than intrusive kerning, but how to do that between font instances? The alternate would have to be the default.

karstenluecke said:

Kerning between regular and italic glyphs is possible, too. (Addressing Adam Jagosz's question.)

I'd like to hear more about that.

k.l.

If regular and italic glyphs are included in the same font, then you are able to kern them against each other. This is what I did in Litteratra where regular lowercase and italic lowercase share the same regular uppercase – note the value -20 between regular T and italic o.it in this screenshot from FLS5’s Metrics Window.
(The font has an ital feature, which substitutes regular lowercase by italic lowercase, like o by o.it, but due to lack of support in applications I also added a stylistic set feature which does the same thing.)

Kent Lew

Contrary to what Mark learned, the scheme advocated by The Chicago Manual of Style (15th Edition, 2003, anyway; not sure if they changed in the 17th) is that “all punctuation marks should appear in the same font — roman or italic — as the main or surrounding text, except for punctuation that belongs to a title or an exclamation in a different font.” (§6.3)

Which means that text that is primarily roman with italic elements will have punctuation in roman, even if immediately adjacent to an italic element, unless the punctuation is actually a part of the title or quote or whatever is being italicized.

Some of the examples given:

Consider also that for possessive plurals of italicized terms in an otherwise roman context, the ’s is to be set in roman (§7.30):

The same is prescribed for the plural of an italicized term.

In a traditional situation where roman and italic are separate fonts, since kerning cannot be dictated between the two fonts, it is worthwhile to consider the strategy one adopts for fitting the italic in this context. Certainly for any workhorse text family.

John Hudson

@Denis Moyogo Jacquerye wrote

There’s an 'ital' feature tag defined in the OpenType specification.

@Thomas Phinney responded

...the existence of the feature is motivated by the history of how CJK fonts have been built.

Specifically, to how CJK fonts were made by Adobe, Morisawa, and some others in the absence of a PS/CFF equivalant of the TrueType Collection format, which is how Apple and Microsoft solved the same situation. In a CJK TTC, a single glyf table containing both upright and italic subsets is shared, with independent cmap and name tables. This has the advantage that upright and italic appear and function exactly like typical font styles. I know Ken Lunde pushed for a CFF equivalent OpenType Collections format, which was added to the OT spec in the last couple of years. I'd be interested to know whether he still considers the <ital> OTL feature worthwhile, or superseded by the OTC method.

_____

@Khaled Hosny

TeX has a glyph metric called italic correction, which is value to be inserted between italic and non-italic text to compensate for the negative right side bearing of italic glyphs. OpenType does not have something equivalent

It does within the MATH table, but not for general OT layout.

Mark Simonson

To Kent: That makes sense. Perhaps I misremembered. Or the editors I worked with were misinformed.

Maybe what we need is family kerning. Or maybe a universal kerning table that includes all existing fonts and sizes! I can hardly wait to build those billions of pairs.

I've mentioned this before, but I think the real solution is a spacing model that isn't based on simple advance width and therefore doesn't need kerning exceptions to get proper spacing. I don't expect it to happen (and I'm not even sure if it would work as well as I imagine), but that's my dream.

k.l.

Specifically, ...

Well, as entertaining as this may be, just some action would be more useful, especially as ital is a low hanging fruit.

It does within the MATH table, but not for general OT layout.

That would be another case of ‹using cannons to shoot sparrows› ...

Kent Lew

Or the editors I worked with were misinformed.

To be fair to them (and you), the Chicago Manual of Style is certainly not gospel. Many editors choose to follow different style guides. There are plenty of others out there.

John Savard

George Thomas said:

"...provide quick italics for most needs and polished italics for nerds."

As if the world needs something else to add to the degradation of typography -- as practiced by those with typographic knowledge, or as you refer to them, "nerds".

Absolutely: when I press on I in the bar above a text window, I want the real italics, not, say, sloped characters, with the real italics hidden in an OpenType submenu, only available on premium word processing programs.

There's nothing wrong, though, in making the feature available through the "proper" route as well. As for small capitals, in my opinion they should be treated as a case, just as much as upper and lower case, and so they should have discrete Unicode code positions.

John Savard

Mark Simonson said:

I've mentioned this before, but I think the real solution is a spacing model that isn't based on simple advance width and therefore doesn't need kerning exceptions to get proper spacing. I don't expect it to happen (and I'm not even sure if it would work as well as I imagine), but that's my dream.

Ooh!

That certainly would help with the issue of awkwardness when switching from a normal font to an italic font.

I could imagine this sort of thing being incorporated into Donald Knuth's Metafont easily enough. In the world of TrueType, however, I would suspect that such a spacing model goes far beyond what would be regarded as reasonable to expect type designers as users to cope with.

What I would suggest as being more in keeping with the limited ambitions of mainstream font technology is something like the following:

For an italic font, normally all letter pairs (except lower-case letters without ascenders or descenders) will be somewhat kerned. Instead of having to specify all the combinations in a kerning table, therefore, the default boundaries of the character's width should be so situated that descenders will stick out slightly to the left and ascenders will stick out slightly to the right. Only exceptions to the standard amount of kerning would have to go into the kerning table.

But for mixture with other fonts, the position of the left and right sides of the character's bounding box will have to be specified as something with no kerning.

So the left and right sides of the bounding box, at least for italic fonts, should have an intra-font value and an inter-font value that may differ. That is the minimal complication that will solve most of the issues.

Specifying bounding boxes that can be parallelograms - or even arbitrary curves - would be the ideal, but there should be something else that addresses the issue without making the ability to cope with this additional complexity a requirement. (Although the parallelogram case, being so well suited to the very common case of italics, ought to be automated and made easily available too, so that doing it right is a reasonable option more often.)

Ben Blom

The idea to have an italic within a variable font, only makes sense, if there is any “variation” possible to derive such an italic from the corresponding upright.

For most fonts, especially serif fonts, this is not possible—because the italic is just a different design than the upright. It may be confusing to give the same family name to a different design—but this is just the convention.

To add an italic to those variable fonts in which it is possible to derive the italic from the corresponding upright, only creates confusion—when most variable fonts don’t have an italic included. (However, this does make sense in unusual fonts like Roslindale Variable Italic.)

So the idea to have an italic within a variable font, is a non-starter.

Mark Simonson

Never say never: https://djr.com/notes/roslindale-variable-italic-font-of-the-month/

k.l.

(Using the variations mechanism for something as simple as replacing upright glyphs by italic glyphs is over the top. Using the variations mechanism where the typeface's design makes good use of it is fine. As always, ‹it depends›.)

Mark Simonson

I don't think italic as a variation is necessarily better or worse than italic as an OT feature, but it's got a leg up in that there is already some UI support for it (web browsers, Adobe CC).