FYI, OS X Mavericks OpenType bug for LNUM lookups

Jackson Showalter-Cavanaugh

As an advocate of default old-style figures, I thought I'd share this incredibly dumb bug:

OS X Mavericks's cocoa text engine seems to assume every font’s default figures are lining. Therefore it doesn't look for, or offer, the OpenType Lining Figures LNUM lookup. As a result, users of fonts with non-lining default figures have no way to turn them on.

Attached is an image showing the "Number Case" options for Calibri, which has default old-style figures. You can see there is no "Lining Figures" option.

I've submitted bug report with Apple. I'd encourage others to do so as well.

James Puckett

Someone really needs to teach Apple’s UI hacks the difference between simple and dumbed-down.

Jackson Showalter-Cavanaugh

I don't think this is a dumbing-down issue, I just think this was an incredibly boneheaded assumption (they didn't make the same mistake with Proportional/Tabular widths).

The old working version of the Cocoa "Typography" menu arguably the best OpenType feature interfaces around, although way too difficult to get at.

Deleted Account

It is real simple. The default the user is expecting in lining figures. This may be because when one starts typing, the default is uppercase. I think if there are lining figures in a font, and one doesn't put them in the default position, one is denying the undeniable defaults and asking for trouble forever.

Jackson Showalter-Cavanaugh

expectations and assumptions ≠ standards

not that it's at all relevant but i'm pretty sure the default for typing is not uppercase, seeing as how i'm typing without holding modifier keys and getting nothing but lowercase.

Chris Lozos

There is a difference between default and user expectation of default

John Hudson

Attached is an image showing the "Number Case" options for Calibri, which has default old-style figures.

Are you sure about that? The Windows version of Calibri has default tabular lining numbers.

The original intent was for all the CT Collection fonts to have default proportional oldstyle numerals, but when Calibri and Cambria were adopted as core fonts by Office we had to change the default in those two families to tabular lining.

What's the version number on the fonts you are looking at?

Jackson Showalter-Cavanaugh

Interesting. It says v0.9, so it must be an early one. It came from an old windows testing machine.

Deleted Account

"i'm typing without holding modifier keys and getting nothing but lowercase."

When you start to answer me next time, look more carefully.

LeMo aka PatternMan aka Frank E Blokland

David: ‘[…] one is denying the undeniable defaults and asking for trouble forever. ’

Reminds me of the good ol’ days when clever entrepreneurs used the Symbol-set slots for storing more tasty ligatures.

Marcos Ojeda

to clarify, is this a legit Core Text bug where LNUM is being disregarded entirely or a poorly chosen default in TextEdit?

Jackson Showalter-Cavanaugh

It appears to be disregarded entirely, since the "Default" option doesn't activate it.

John Hudson

The default the user is expecting in lining figures.

So because the limitations of a particular generation of technology meant that default numeral style for most fonts needed to be tabular lining -- i.e. the setting with the most restrictions -- we're now obliged to do that forever, even if the majority use for numerals in most documents is not tabular and in context of mixed case text?

I always offer my customers a choice of what numeral style they want as default, and most choose proportional oldstyle because that's the style that is most used in their publications.

Personally, I think the whole notion of default numeral style is faulty. Numeral style should always be an application UI setting, and not rely on fonts designating any particular style.

SiDaniels

Jackson, unless someone messed up, we make sure our shipping (non-beta/preview) products have fonts set to at least version 1.00. So 0.90 would indicate a pre-release version of Calibri. Cheers, Si

Jackson Showalter-Cavanaugh

Just to confirm Marcos' question, here is a test using Adam Twardoch's fantastic OpenType testing font Nadyezhda SL One. LNUM is behind the bz pair, it is not on by default and none of the menu options activate it.

Also fun is the blank menu item, which seems to activate the UNIC feature.

Chris Lozos

The default type style is almost the same issue. There are people who either don't know the difference or who do not care about it who are satisfied with default settings. The problem comes for the people who know and care but are prevented from using their choice because the system won't present the possibility.

Deleted Account

"The problem comes for the people who know and care but are prevented from using their choice because the system won't present the possibility."

Is that what's happening here? Since these fonts could be presented by the founder in such a way that the system could present the figure possibilities to the user perfectly plainly, I don't think so.

"Personally, I think the whole notion of default numeral style is faulty."

Personally, I think everyone should have their own gold mine and a god who only cares about them in a religion with 365 Christmas days, so I can have a new pair of socks every day. But we don't even have standard public encodings for these glyphs, so you better toe the line...

" -- we're now obliged to do that forever,"

...slaves.

Chris Lozos

"...because the system won't present the possibility."
By system, I did not mean the operating system. I include the whole path: Typeface>application>UI

I don't know what is at fault here, a beta software, a miss application of a standard, or an obtuse operating system.

Marcos Ojeda

@jackson fwiw, i submitted radar: 16019362 describing this bug and also reported it to the coretext-dev mailing list for good measure.

maybe when i'm less sleepy, i'll just try creating an attributed string with the uppercase figure feature outright. my gut feeling says that the problem is due to being unable to query the property, but that it is possible that the property can be set directly in spite of what the api says is possible. but i'd only bet a few doge on it.

Kent Lew

Personally, I think the whole notion of default numeral style is faulty. Numeral style should always be an application UI setting, and not rely on fonts designating any particular style.

John — I’m not quite sure I follow your thinking here. The basic numeral codepoints have to be assigned to one set of glyphs or another, right? So, one style or the another has to be the “default.” I’m certain you would not suggest double-mapping or not encoding any.

Or are you saying that an application UI should not bother to have a generic option labeled “Default figures”? Okay, fine. But surely the application is going to have to designate some default starting point, right? The app can’t not display any numerals until the user has specifically selected a figure style. That would be nonsensical.

And what if the default setting for the application (perhaps as specified by user preferences, perhaps out-of-the-box) is Lining Figures, but none are present?

What if the font has only one style of figures present: oldstyle? In this case, should the app display oldstyle figures for the default Lining Figures setting? How will it know that’s what it’s doing?

Or should that font instead be required to have a dummy OTL feature — say, for example, feature onum { sub @figs by @figs; } onum; — in order that the application be able to query what figure style options are available? And otherwise, it should break? That seems a bit draconian.

So, then maybe the app will have to make some fallback assumptions. Which puts us pretty much back where we started.

John Hudson

Kent, what I mean is that despite whatever a font maker has assigned to the Unicode codepoints, the proper place for decision regarding numeral style is at the application level, made by the typographer. Yes, there needs to be some kind of fallback, and some kind of initial default setting the first time you open an app, but after that the numeral style should always be determined by the choice of the typographer, not the font manufacturer.

So, a UI such as InDesign's that provides an option for 'default', i.e. whatever privileged glyphs are mapped in the cmap table, makes no sense. The choice should always be explicit by the user and if, as David suggests, the default expectation of users is [tabular] lining figures, by all means make that the default numeral style setting in apps, i.e. have all app begin by applying the {lnum} and {tnum} features. Then the user can go and modify these settings, as personal default preference, or for specific documents, text selections, or paragraph/character styles.

Fallback for fonts with few numeral style variants doesn't need a lot of thought, because it basically takes care of itself, just as it does now if a user selects a style and spacing combination not supported by the font. In the worst case, you end up with whatever numerals the font maker has mapped to Unicode in the cmap table, but my point is that should be the end result of fallback, not the beginning point of typography.

PabloImpallari

I struggled with this very same issue when creating the interface for the Drag and Drop Testing Page, and ended up with the configuration you can see on the attached image.
It works... However, very few fonts includes all the 4 sets.

Most fonts are including only 1 or 2 sets.
Other are including 3 sets: usually Lining Proportional, Lining Tabular and Old Style Proportional, but Old Style Tabular is left behind.
Fonts including all the 4 sets are very very few.

As a result of not having all 4 sets, the interface fails.
For example, if the user selects 1) Old Style + 2)Tabular, they usually get Lining Tabular instead. (Or any other combination, depending on the sets available and the sets selected)

PabloImpallari

....

Jackson Showalter-Cavanaugh

This bug was fixed in 10.9.3.

Nick Shinn

I always include all four sets of figures, at least, even if some are wildly inappropriate. That way there is no “fail” in the OT menu.

In some types I make the default for body text (optical size) tabular oldstyle, and the display default proportional lining. That makes perfect sense, IMHO. If anyone is foolish enough to want tabular oldstyle in their headlines, they have that option.