Typophile - Opentype feature access to unusual characters - Comments

> where do these

Miguel Sousa — Fri, 3 Oct 2008 04:40:04 -0700

> where do these replacements actually occur? i’m curious. i’m still trying to understand the workings behind the scenes. for example, if you have a font that substitutes f f i (u0066 u0066 u0069) by ffi (uFB03), what problems will arise?

There are no actual replacements in e.g. InDesign. The underlying characters will remain the same when you apply the features; only the displayed glyphs will change. The issues may occur latter when, let’s say, you generate a PDF file, send it to someone, and that person tries to retrieve the text from the PDF (or perform a search). If the PDF has a ToUnicode table, the text might come out with U+FB03, instead the original U+0066 U+0066 U+0069. If there’s no ToUnicode table in the PDF, the glyph name will be parsed. According to this list the glyph name ffi will correspond to character U+FB03, and according to these rules the glyph name f_f_i will be mapped to the characters f, f and i. This page explains where and why glyph names are used.

> what will happen if you name the substituted glyph f_f_i and still assign the unicode point (uFB03)?

I think it will depend on how the glyph was inserted, which app generated the PDF and which app reads it and accesses the PDF contents. Ideally, the glyph f_f_i should be unencoded, and a glyph duplicate of it — named uniFB03 (or ffi) — should be the one to carry the encoding. But what you describe is not at all bad. That’s actually what we do in our fonts. The reasoning being that we favor the ligature aspect — therefore the glyph name f_f_i and not ffi —, but at the same time we don’t want people to get notdefs if the text happens to contain the character U+FB03 — therefore we assign the code point.

back to this, Miguel

paul d hunt — Fri, 3 Oct 2008 03:26:45 -0700

back to this, Miguel said:
Many of Adobe’s early Pro fonts have similar kinds of substitutions (e.g. in Warnock Pro the ornaments are alternates of lowercase Latin letters), but this is not really a good practice*. These and other substitutions (like sub [a A] by ordfeminine;) were implemented in the font to make its usage convenient from the user’s POV, but they’re not good because they replace character(s) by other character(s).

where do these replacements actually occur? i’m curious. i’m still trying to understand the workings behind the scenes. for example, if you have a font that substitutes f f i (u0066 u0066 u0069) by ffi (uFB03), what problems will arise? what will happen if you name the substituted glyph f_f_i and still assign the unicode point (uFB03)?

...in addition to which, I

dtw — Fri, 14 Sep 2007 03:29:40 -0700

...in addition to which, I often type (c) to mean (c), as in lists. When I want a copyright symbol, I know how to get it. Word used to substitute one for the other with its AutoCorrect settings, until I got fed up with it and switched it off. I wouldn’t want that ‘feature’ built into the font. Not that Word knows about OpenType features, but you get my drift...

____________________________________________________________
Ever since I chose to block pop-ups, my toaster’s stopped working.

Right. This is a

Thomas Phinney — Fri, 10 Aug 2007 14:58:26 -0700

Right. This is a particularly important issue for the copyright symbol, because the c-in-parens has no legal relevance. It has to either be the copyright symbol or the word “copyright.”

Disclaimer: At least, that’s what I’ve heard from lawyers. I’m not a lawyer myself and of course you should consult an actual lawyer for impartial legal advice.

Regards,

For example, many PC users

John Hudson — Thu, 9 Aug 2007 16:45:56 -0700

For example, many PC users are used to the automatic replacement of 1/2 to ½ and of (C) to ©.

But these are character-level substitutions performed by the application. So what ends up in the text string when (C) is coverted to © is © not (C). If this substitution were performed at the glyph level, then the text string would remain (C), which is not the copyright symbol.

Paul, a conversion of (C)

twardoch — Thu, 9 Aug 2007 16:04:36 -0700

Paul,

a conversion of (C) to © on the glyph level is rather bad because it breaks Unicode. Any OpenType features that break Unicode should be avoided unless there is a really strong argument to do it anyway.

Adam

back to this topic... would

paul d hunt — Fri, 13 Jul 2007 11:10:02 -0700

back to this topic...
would it be advisable to have some type of feature where for character composition (besides ccmp) so that the user would know that if this feature is enabled certain characters are converted easily to symbols? For example, many PC users are used to the automatic replacement of 1/2 to ½ and of (C) to ©. Would it be so bad to have a symbol composition feature (symb, hypothetically) that could build on these standardized (by Microsoft) practices to make symbols easily accessible via simple key combinations instead of having to hunt through a glyph palette?

Paul, the

twardoch — Wed, 4 Jul 2007 21:08:10 -0700

Paul,

the Scedilla->Scommaaccent case is indeed special. The proper Unicode codepoint to be used with Romanian is that of Scommaaccent (U+0218). Unfortunately, some old Unicode implementations use U+015E (Scedilla) in the Romanian locale. This means that the Romanian text can be represented in two different ways, “old” (using Scedilla) and “new” (using Scommaaccent). The “locl” OpenType replacement helps migrate the electronic text from the old to the new encoding. In this very case, the font helps fix a particular isolated encoding problem.

Also, the Scedilla->Scommaaccent replacement in “locl” for Romanian has become a widely accepted practice now. Both Unicode and OpenType work on that very principle: if something becomes widely accepted practice, it can be codified. So if you manage to convince enough people to follow a particular method, you may be lucky with your stuff getting “standardized”.

this is really a bit of a

paul d hunt — Wed, 4 Jul 2007 09:19:57 -0700

this is really a bit of a sticky wicket, isn’t it? everyone seems to be in agreement that OT features should not be used for character conversion, but even the most recently released fonts by Adobe substitute scedilla with scommaaccent in the ’locl’ feature. if we were following this non-conversion rule strictly, scedilla would be replaced by scedilla.locl (a clone of scommaaccent), right? So, is there just a bit of wiggle room with this rule, or should it be followed absolutely?

…they should not or, at

Nick Shinn — Sun, 3 Jun 2007 11:24:53 -0700

...they should not or, at least, should not do so automatically.

The same is true of “SmartyPants”, and “Typographic Quotes”, which is a default of InDesign, isn’t it?

Yes, some apps still maintain the faux italic for backward-compatibility reasons.

I don’t think that’s the main reason. It’s because application engineers think their application can fill in the gaps in a font family, and they believe it’s a genuine service to the user to do so. For instance, InDesign offers users small caps of any font, even those with no true small caps.

no need or reason to come up with NEW solutions that still follow this old-style way of thinking.

The need for Smarty-Pants: typographers hate seeing hash mark quotes and apostrophes, and if Smarty can fix that, they don’t mind the hack, even if it screws up abbreviations like ’07.

But as I said, your (and others’) arguments against *lying* Stylistic Alternatives have convinced me that it would be impractical to include them in my fonts. Thank-you!

BTW, the faux italicization

twardoch — Sun, 3 Jun 2007 09:47:23 -0700

BTW, the faux italicization really comes from the *extremely* early days of computing, where you had bitmap fonts, very few fonts, low-resolution printers etc. (where you wouldn’t even actually tell the roman from the italic, easily). Remember, those were the days where fonts came on floppy disk and using three different fonts on a page might overload your printer’s memory. And the expression “electronic documents” probably didn’t exist (neither did the PDF format).

We’re 20 years into future now. Yes, some apps still maintain the faux italic for backward-compatibility reasons. But there is no need or reason to come up with NEW solutions that still follow this old-style way of thinking.

Anyway, thanks for your

Nick Shinn — Sat, 2 Jun 2007 22:03:29 -0700

Anyway, thanks for your comments, everybody.
I’m glad the extra “superior” glyphs passed muster — are there any others that could be added, other than these footnote symbols?

That assumes that the effect

Nick Shinn — Sat, 2 Jun 2007 22:03:27 -0700

That assumes that the effect of case feature substitutions is always equivalent to a baseline shift...

That wasn’t my assumption, although I did express myself sloppily. Although I didn’t say “some of” the alternate glyphs, I didn’t mean *all* of the substitutions are equivalent to baseline shifts.

I was just giving an example of how a font can solve a layout application difficulty.

And really, isn’t that how OpenType features work? The substitution coding is in the font.
It would in theory be possible to just name the glyphs in a font, and have the app do the substitutions. For instance, with “one.numr”, “fraction”, and “nine.dnom” as font glyphs, an application fraction-maker could construct 11/99.

I would imagine that might be how Adam’s putative CS5 math engine would work.

Nick: It can be useful. The

John Hudson — Sat, 2 Jun 2007 13:32:25 -0700

Nick: It can be useful. The alternate glyphs in the case feature, for instance, solve an application problem (manual application of baseline shift) by automatically repositioning punctuation such as parentheses.

That assumes that the effect of case feature substitutions is always equivalent to a baseline shift, but this is not so. case feature substitutions may involve changes to the form of glyphs as well as to their vertical positioning, not to mention spacing. In fonts in which the default numeral forms are oldstyle, it makes sense to put mappings to lining numerals in the case feature. So the case feature is not simply doing in the font what could be done at the application level: it is things that are glyph centric and need to be controlled at the font level.

John states that fonts shouldn’t attempt to fix application shortcomings with hacks, but the converse is exactly what apps do with faux features.

And I likewise think that they should not or, at least, should not do so automatically. If, when the user clicked the italic button in Word, for example, a dialogue popped up saying

’The font family you are using does not include an italic font. Do you want Word to slant the regular font to fake an italic?’

that would be preferable to automatic slanting.

Adam, I already

Nick Shinn — Sat, 2 Jun 2007 11:16:38 -0700

Adam, I already capitulated.

Regarding backwards compatability, just follow the money.
You can open a Quark 3 document on an Intel Mac, but only if you buy Quark 7. Don’t need new fonts though, thanks to the stellar philanthropy of type foundries!

Don’t you think that’s a bit of a double standard?

After all, Quark, InDesign and Word have incorporated faux features (bogus weight, italicization, scaling, small caps) since day one.
To paraphrase; the functional qualities of such software may be fine, but the typographic side of the design is broken.

John states that fonts shouldn’t attempt to fix application shortcomings with hacks, but the converse is exactly what apps do with faux features.

Opentype feature access to unusual characters

Nick Shinn — Tue, 29 May 2007 21:45:16 -0700

Here are a few ideas:

Superior:
® becomes “registered.alt” — a small, superior version of the character
† becomes “dagger.alt” — a small, superior version of the character
‡ becomes “daggerdbl.alt” — a small, superior version of the character

Stylistic alternates:
’ becomes “second”
” becomes “minute”
x becomes “multiply”
- becomes “minus”
l becomes “liter” (u+2113)
> becomes “fist” (u+261E)

These seem reasonably intuitive.
Is there any reason not to implement them?
Anything else that could be added?