New OT feature proposal : Honorific Forms (hons)

[tiroj]

Some writing systems employ special forms to represent character sequences when these are used as honorific terms of respect. These representations differ visually from the non-honorific forms of the same character sequences. Some fonts include these honorific forms as Stylistic Set substitutions, but since these forms have a defined orthographic role, greater interoperability between fonts and in text would be facilitated by having a dedicated layout feature.

---

Tag: 'hons'
Friendly name: Honorifics

Registered by: Tiro Typeworks

Function: Replaces a glyph or sequence of glyphs with a special, visually distinct form when used as an honorific term of respect or invocation.

Example: In the Kannada writing system, the character sequence <0CB6 0CCD 0CB0 0CC0> ಶ್ರೀ śrī is written with a special ligature form when representing the honorific; both forms may appear in the same document.

Recommended implementation: Because the underlying encoding and relationship of an honorific to a default form will differ from script to script, no one implementation is recommended. Likely implementations may involve one-to-one substitutions (GSUB lookup type 1), many-to-one substitutions (GSUB lookup type 4), or contextual substitutions (GSUB lookup type 5 or 6).

Application interface: For sets of GIDs found in the 'hons' coverage table, the application passes the sequence of GIDs to the table and gets back a new GID. Note that full sequences must be passed.

UI suggestion: This feature should be off by default.

Script/language sensitivity: Applies to any script and language system that utilises distinct forms for honorifics. Note that Unicode atomically encodes many honorifics for the Arabic script, but these might also be written out and could be displayed using the Honorific Forms feature.]

Feature interaction: This feature may be used in combination with other substitution (GSUB) features, whose results it may override. Feature interaction would be governed by lookup ordering. For Indic scripts, this feature should be applied after reordering.

[tiroj]

I am a little concerned about using the feature name Honorific Forms, because of the processing distinction implied in Microsoft's names for Indic script features: — Forms (pre-reordering) vs — Substitutions (post-reordering). That's why I am proposing 'hons' as the tag, rather than 'honf'.

[twardoch]

I think a reasonable example for Latin-based use could be to use this feature to provide special ligatures for things like "Mr." or "Ms.", and this could be added to the description.

I'm mentioning it because I think app vendors would be more willing to expose the extra feature in UIs if there were use cases for multiple scripts including Latin.

Otherwise, the feature may share the fate of "ital", which is virtually inaccessible because it has been deemed "CJK-only", though it might make sense in all scripts, as a font that used it could implement kerning between uprights and italics.

[twardoch]

Ken,

of course I agree that it makes sense for CJK. But it would make a lot of sense for other scripts as well. I know many book designers who despair that in situations where you have a full sentence in upright, including parantheses, but inside the parantheses there is italic, there is no kerning at the text run break. Esp. in cases where you have an italic "f" followed by an upright ")".

There are many more cases like this. Scientific publishing and typefaces for long text could benefit from "ital". It wouldn't harm to also ship a separate italic font in addition to integrating it within the upright — just like some vendors ship integrated small caps plus a separate SC font.

[twardoch]

Non-CJK fonts, esp. "text fonts", are tiny compared to most other resources used in publishing, and are often re-used across projects.

And, while ital for CJK gives you the "space-saving" benefit, ital for EU gives you kerning, which is not easily obtained any other way.

But I think that because ital had been framed as "CJK", very few apps expose UI for it.

[twardoch]

In addition, there is the habit to add a basic set of Latin to fonts that are primarily designed for, say, Arabic, Hebrew or the Indics. There, "ital" could also be useful for the Latin part — much like the case is in CJK.

(BTW, I just recommended your excellent CJKV book to some developers who are struggling with Japanese UI design for Android apps :) — even though the 2nd ed. does not cover Android, I guess, it's still an incredibly useful read for those who need to understand the core differences between Euro-centric and CJKV text layout and processing).

[tiroj]

Ahem. Anything to say about the honorific forms proposal? :)

[twardoch]

I must say that I really really dislike the idea in OpenType that user-controlled features are tied to a particular implementation, including GSUB & GPOS. I understand that this is needed for the automatically applied features, but I remember my disappointment that the MS OT engine did not apply ssXX features in GPOS ( see http://sites.twardoch.com/typography/font-tech/gpos-stylistic-sets ).

I think that for user-controllable features, it really should be up to the font implementer to decide whether the feature is best implemented via GSUB, GPOS or both. Even though this has not been done so in the past, I think implementations should evolve towards being more lenient. After all, if I need to employ both substitutions and positioning to get desired results for smcp, I should be able to, similarly to pnum or sups.

Therefore, I'm rather weary of encoding the word "Substitutions" in the name. If "Forms" is not to your liking, perhaps "Honorific Alternates" would be a better choice. After all, most feature names, especially the ones that are primarily intended for GSUB, tell you what you get in the end (some forms, ligatures, sets, small caps etc.). There are some exceptions.

But Honorific Substitutions is a name that talks about the process, not about the result. This is a different naming paradigm than most features.

I'd support Honorific Forms. After all, hons is conceptually a bit similar to tnam (Traditional Name Forms).

[tiroj]

Good idea, Ken.

Friendly name: Honorifics

---

Adam:

But Honorific Substitutions is a name that talks about the process, not about the result. This is a different naming paradigm than most features.

I guess because the immediate use case I'm looking at is Kannada, I was thinking of the feature name in terms of the convention used in Microsoft's Indic feature set.

[twardoch]

I agree with the "Honorifics"
suggestion, which incidentally perfectly abbreviates to hons :)

[twardoch]

And as a more general remark: feature names are mostly noun. For user-controlled features, they're mostly built in a way where a UI checkbox next to them would tell the user: if the checkbox is on, you will get what's on the label as a result.

In most cases, they names are in plural (Ligatures, Small Caps, Stylistic Alternates), and they are short form for "something something Forms/Alternates/Variants". Sometimes they're a collective singular (Swash, Superscript).

Rarely, they're formed in a way where it's a gerund that could be an adjective to an omitted noun (Titling), and very very rarely they're verbs (Randomize). When they affect the whole font or group object they're singular (Optical size, Stylistic Set, Centered CJK Punctuation). Kerning is an odd case but that's a word where it's really very hard to tell anymore Wyatt grammatical function it has. Is this a word that describes a process, or is this a word that unveils some collective object? But since kerning is so core to type, it's fine for the feature name to be a bit of an exception to the overall scheme.

ital is interesting: the style name is called Italic which implies a whole font change. But the feature is named Italics, short for Italic Forms/Alternates etc., which indicates that the feature is meant to target an arbitrary subset of glyphs.

So overall, it's rather good and reasonably consistent. And most importantly, they don't indicate the particular implementation, they're functional and built in a way that can be exposed to users in the UI.

The automatically applied features are less consistent. Sometimes they're implementation-specific (mark vs. mset), and I think if we were to start from scratch, we’d just make one feature tag that could work in both GSUB & GPOS (no big reason why mark rather than mset couldn't exist in GSUB and if it were present, it would be applied, and if it also existed in GPOS, it also would be applied).

The automatically applied features really are a very very separate phenomenon from the user-controlled. I don't care about their names at all :)

I think it's a bit confusing that both groups are all in one list in the spec. The one group really has rather little to do with the other, UX-wise.

[bobh0303]

Would this be a useful and/or recommended to identify when Arabic sequences that include alef-lam-lam-heh should get special rendering (as opposed to when they shouldn't)?