Apple and CFF: what's the deal?

paul d hunt's picture

If i remember correctly, someone recently refered to the Mac as being a "marginally Unicode compliant environment" or something to that effect. Why is Apple taking so long to adopt the standard and what is the best way to get around this apparent obstacle? I'm assuming (correct me if i'm wrong) that Apple is still adhering to some glyph naming standard to access glyphs, but which standard is that?

Nick Shinn's picture

I’d encourage all font developers to test their fonts, just to make sure that the correct use of the ’cmap’ table for OT CFF fonts is not restricted to fonts developed by Adobe.

Does this mean that the FontLab default, which assigns a character name of, for instance, "tcommaaccent", and gives it the Unicode 0163, is incorrect?

Do I have to change ALL character names to alphanumeric code, e.g. "uni0163"?

twardoch's picture

> Does this mean that the FontLab default, which assigns a character name of,
> for instance, “tcommaaccent”, and gives it the Unicode 0163, is incorrect?

It depends on what you mean by "incorrect". The "registered" glyphnames are not an official part of the OpenType standard, they're a recommendation by Adobe. Mac OS X recognizes most of the mnemonic glyphnames listed by Adobe in the AGLFN (such as aogonek, cacute, ntilde etc.) but in case of U+0163, Adobe recognizes both the glyphnames "tcommaaccent" and "uni0163" while Mac OS X 10.4 only recognizes "uni0163".

A.

dezcom's picture

The things that seem so simple can be so frustrating.

ChrisL

dannomon's picture

Thanks all-

I already addressed the lookup ordering issue - simple fix works like a charm and I'm hoping to get this and some other changes in an SU though I feel a little uneasy about relying upon the order of the lookups in the fonts themselves; I've seen fonts that were not ordered. I guess worst case would be to have a huge precedence list of features to follow. For the capitals features, I changed them to checkboxes from radio buttons (just for OT fonts though) based on feedback though I've seen a few comments stating that this was not preferred. At least, it's up to the user to check a single or multiple capitals features.

I wasn't aware of the kerning problem you noted which I'll investigate but I did indeed just find and address a vertical kerning issue: values were definitely confused. Also note, fonts that don't have a 'morx' or 'mort' but have a 'GSUB' go through OT processing but if the font has also has a 'kern' table, MacOS X positioning for ATSUI and CoreText will use that instead of the 'GPOS' (this is specified by the OT spec).

So the gist the 'cmap' issue then is it's been fixed correctly in Leopard. Unfortunately, we're past the last SU for Tiger so there's no going back. I'll post back after investigating the kern issue. Cheers,

Dan

Miguel Sousa's picture

> though I feel a little uneasy about relying upon the order of the lookups in the fonts themselves

Recently there was a thread on the OpenType list entitled "Feature apply order", which discussed what some text engines are doing.

Nick Shinn's picture

It depends on what you mean by “incorrect”.

Sorry Adam, no diss of FontLab intended, just perplexity on my part.
OK, the way it appears:
Adobe recommends glyph names, FontLab incorporates them into its code pages, but Apple doesn't recognize all the glyph names.
Is this a misunderstanding, an oversight, or Apple's recalcitrance to Adobe's fiat, given that "registered" glyph names are not part of the OT standard?

Miguel Sousa's picture

Dan, while you're at it, can you fix style-linking and how the styles of a same family are listed? Here's a test case: Arno Pro, a family of 32 faces. (Let me know if you can't get a hold of the fonts)

The problems I find when using the OS's (10.4.10) 'Font' window are:
1. When selecting Arno Pro from the 'Family' list, the style 'Bold Display' is the one selected by default on the 'Typeface' list, instead of 'Regular'.

2. On the 'Typeface' list, some styles are disordered (see image below). 'Bold Display' and 'Bold Italic Display' should appear near the bottom, and 'Light Display' and 'Light Italic Display' near the top, for example.

3. Style-linking is not working correctly. For example, selecting 'Regular' and pressing Command+B, 'Semibold' gets selected instead of 'Bold'. Pressing Command+B again and 'Bold Display' gets selected, instead of going back to 'Regular'.

Arno Pro's faces that should style-link are the following:
a. Caption / Caption Italic / Bold Caption/ Bold Italic Caption
b. SmText / SmText Italic / Bold SmText/ Bold Italic SmText
c. Regular / Italic / Bold / Bold Italic
d. Subhead / Subhead Italic / Bold Subhead/ Bold Italic Subhead
e. Display / Display Italic / Bold Display/ Bold Italic Display
f. Semibold Caption / Semibold Italic Caption
g. Semibold SmText / Semibold Italic SmText
h. Semibold / Semibold Italic
i. Semibold Subhead / Semibold Italic Subhead
j. Semibold Display / Semibold Italic Display
k. Light Display / Light Italic Display

dannomon's picture

I haven't delved into this part of the Font Panel before but yes, I agree having the "regular" or "plain" style should be the default. Typeface names do seem to be getting more interesting these days; having a smarter order would be nice and I'll file the appropriate request bugs. Thanks for the feedback. Cheers,

Dan

dezcom's picture

Dan,
Thanks for listening to us here! We really appreciate it.

ChrisL

k.l.'s picture

Since Miguel mentions style-linking in Arno Pro, the question is, what is Command+B supposed to do in Apple applications?
Does it rely on 4-style subfamilies defined by name table IDs 1+2 and OS/2 fsSelection? Or does it rely on the OS/2 weight value and allow toggling through weights, as in Adobe applications? (Needs to treat optical weights as separate families.)
[Edit] To put the question differently: Does Apple want to imitate style-linking behavior as in Microsoft applications, or in Adobe applications? The former may make sense if the goal is to match (Word) users' expectations. But Apple applications' font menus show large families rather than the 4-style families into which large families are teared in Windows, so there is no need to pay tribute to 4-style families when it comes to style shortcuts.

Dan -- I've seen fonts that were not ordered.

I think this then is a problem of fonts. At least in Latin script fonts, considering the OpenType List discussion to which Miguel refers.

Dan -- For the capitals features, I changed them to checkboxes from radio buttons (just for OT fonts though) based on feedback though I've seen a few comments stating that this was not preferred. At least, it's up to the user to check a single or multiple capitals features.

Hm. Does it mean to get smallcaps from both upper and lowercase one needs to activate two options? I have not seen OS 10.5 yet ...
(Seems I am one of those who would have preferred mutually exclusive options "Upper & Lower Case", "Upper Case", "Upper Case & Small Caps", "Small Caps". Still wondering why a user would want to select uppercase and smallcaps at the same time.)

I have a question:
Does/will OS 10.5 also interpret GPOS features (e.g. 'kern') with multiple lookups and contextual positioning?

Karsten

dannomon's picture

Man, we diverged from the original topic quite a bit (should have started a new thread "Type issues in MacOS Leopard"). But no matter, I'll try answering the best I can.

what is Command+B supposed to do in Apple applications?

Well, it's supposed to do the most sensible, logical thing and switch to a weighted style that also is associated with the style that was previously selected. So if say "Oblique" is selected, doing a Command+B will change the style to "Bold Oblique". But sometimes it's not entirely obvious what to change the style to based on the original style. We can do better though and will try.

Does/will OS 10.5 also interpret GPOS features (e.g. ’kern’) with multiple lookups and contextual positioning?
I'm not sure what you mean but if you're asking if Leopard has full 'GPOS' processing, the answer is yes. There was an omission in Leopard for my default 'GPOS' feature list though: it's missing the 'mkmk' and 'mark' for general layout (of course, it's there for CoreText Arabic if the font has a 'GPOS'). Also, I mentioned it earlier but I should reiterate that we now always use the 'kern' table if present in a font in lieu of its 'GPOS'.

Hm. Does it mean to get smallcaps from both upper and lowercase one needs to activate two options? I have not seen OS 10.5 yet ...
(Seems I am one of those who would have preferred mutually exclusive options “Upper & Lower Case”, “Upper Case”, “Upper Case & Small Caps”, “Small Caps”. Still wondering why a user would want to select uppercase and smallcaps at the same time.)
Actually, it is written (in the OT spec) that these feature shall be permitted to interact with any other 'GSUB' substitution feature (just need to apply them in the correct order, doh!). Cheers,

Dan

k.l.'s picture

This is a chaos thread anyway ...  ;-)

Karsten -- would have preferred mutually exclusive options "Upper & Lower Case", "Upper Case", "Upper Case & Small Caps", "Small Caps"
Dan -- Actually, it is written (in the OT spec) that these feature shall be permitted to interact with any other 'GSUB' substitution feature (just need to apply them in the correct order, doh!).

What I refer to is UI options, not features themselves. Mutually exclusive means: among casing options. Of course case-related features should interact with other GSUB features like 'calt', 'liga', 'ss01' etc.

Dan -- but if you're asking if Leopard has full ’GPOS’ processing, the answer is yes.

Yes, this is what I wanted to know. Great!

Many thanks. Karsten

twardoch's picture

> it’s missing the ’mkmk’ and ’mark’ for general layout

That is very unfortunate.

Is language-dependent processing (the "locl" feature) supported anyhow?

A.

dannomon's picture


What I refer to is UI options, not features themselves.

Well, those case related features are 'GSUB' substitution features so they are also allowed to interact with themselves. That's why the UI does not make them mutually exclusive. So 'c2sc' and 'smcp' are allowed to be on at the same time though their sum effect might be zero depending on the font design.

it’s missing the ’mkmk’ and ’mark’ for general layout - That is very unfortunate.
I'm advocating getting that fix in an SU but I could really use a Latin font that relies upon those features to add to my support. Any well known candidates you can suggest?

Dan

dannomon's picture


Is language-dependent processing (the “locl” feature) supported anyhow?

Er, no. And this is because Leopard OT layout isn't looking at the languages and the UI doesn't really allow for it. Though, there are now discussions about expanding general language specifying support. Can't say much more about that since it's still in planning but we are very much aware of the need and want to address it.

Dan

Miguel Sousa's picture

> I could really use a Latin font that relies upon those features to add to my support. Any well known candidates you can suggest?

Vista ships with enhanced versions of Arial and Times New Roman that contain 'mkmk' and 'mark'.

dberlow's picture

"Why is Apple taking so long to adopt the standard and what is the best way to get around this apparent obstacle? "

I don't know the answer to the first question, but we added a dial tone to all our fonts and everything seems to work fine on the Mac now.

Cheers!

Thomas Phinney's picture

Hey, Dan (F), nice to see you here. Note that Adobe Arabic is an OpenType CFF font family that has the 'mark' and I think the 'mkmk' feature as well. You should have it already for testing, and if not I can certainly send it to you.

Karsten asked: Does it rely on 4-style subfamilies defined by name table IDs 1+2 and OS/2 fsSelection? Or does it rely on the OS/2 weight value and allow toggling through weights, as in Adobe applications?

InDesign does the first behavior, not the second, to the best of my knowledge. I consider that first one the "expected" behavior. Is there some particular Adobe app in which you've observed the second behavior?

(Say, I tried to close any open tags that might have been causing the ongoing italics, but it didn't work, so it wasn't 'cite' or 'em' or 'i' doing it. Sigh.)

Cheers,

T

twardoch's picture

Dan,

please contact me offlist at adam at twardoch dot com.

A.

k.l.'s picture

Thomas -- InDesign does the first behavior, not the second, to the best of my knowledge. I consider that first one the “expected” behavior.

Ouch, right!
(Don't remember how I got at that idea but obviously liked it much ...)

Karsten

kikujiro's picture

Miguel -- the OT style-linking bugs you mention (which I posted here, not realising how much livelier the Typophile forums were) have been fixed in Leopard (as of 10.5.1; I never checked in 10.5). At least, the default font when selecting Arno Pro is now Regular, and command-B/command-I do sensible things at last. The list order looks much the same but with a better default at the top.

More generally -- I realise this is dragging the thread way off topic, but as it seems to be a productive place to discuss Leopard font bugs, may I point out with some frustration that a very old bug has returned from 10.3.5, viz broken support for old PS1 fonts with alternative glyph sets -- most notably 'Expert' fonts, which have been working fine since 10.3.6, and now don't display any more? Dan, if you're reading, I did file this on Bug Reporter, but any help in getting it fixed in the next SU would be much appreciated. I've had to go back to fake small caps and lining figures, and they're horrible.

dezcom's picture

>>>"Is language-dependent processing (the “locl” feature) supported anyhow?
Er, no. And this is because Leopard OT layout isn’t looking at the languages and the UI doesn’t really allow for it. Though, there are now discussions about expanding general language specifying support. Can’t say much more about that since it’s still in planning but we are very much aware of the need and want to address it.
Dan"<<<

Dan,
Any more progress on this? Language support is a pretty major thing and is bound to open up more userbase for Apple if handled well. I hope that THEY let you proceed with full support on this right away.

ChrisL

twardoch's picture

Chris,

I guess if Apple says "expanding general language specifying support [is] still in planning", then it won't happen before Mac OS X 10.6 in two years or so. Let's not hold our breath — but let's hope that the obvious bugs in Leopard's OT feature handling get fixed sometime soon.

Best,
Adam

dezcom's picture

I hope so too, Adam. I don't know if Dan or anyone else at Apple is still paying attention. I hope so.

ChrisL

Thomas Phinney's picture

OS X may have had a lot of font-handling bugs, but you have to give Dan F and Apple kudos for working so hard to fix them - especially lately.

Cheers,

T

Syndicate content Syndicate content