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.
0
Comments
The old working version of the Cocoa "Typography" menu arguably the best OpenType feature interfaces around, although way too difficult to get at.
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.
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?
When you start to answer me next time, look more carefully.
Reminds me of the good ol’ days when clever entrepreneurs used the Symbol-set slots for storing more tasty ligatures.
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.
Also fun is the blank menu item, which seems to activate the UNIC feature.
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.
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.
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.
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.
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.
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)
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.