OpenType features (e.g. small caps) not consistently applied

I have had similar experiences with other typographic extras.

My workarounda have been

a) Make the changes in TextEdit and copy and paste.
or
b) Restart (Pages? Mac OS X?) to reset the fonts. After that it worked - at least for some time.

And I'm not crazy, right?

I'm not a medecine man so I can't respond.

What I know is that on my system minion pro behaves correctly.



On the left are _true small caps_ which I got from the Typography… pane.
On the right are the _sad calculated ones_ which I got from
Format > Font > Capitalization > Small Caps.

From time to time, I read messages from Magnus telling that he met some odd behavior. On my systems I always get a consistent one.

Yvan KOENIG (from FRANCE lundi 4 août 2008 10:24:27)

If you want to reproduce the problem, try the following:

1. Open the Font Palette.
2. Open the Typographic extras.
3. Put the cursor in the search field of the Font Palette. (This gives the Font Palette focus instead of the main window.)
4. Click on any font high up in the list, like "Arial".
5. Type arrow down. (This will now move you to the next font in the list, if you followed the steps above, and if you have the same behaviour as me.) Check if the Typography panel is updated with the new values.
6. Type arrow down again.
7. And again.
8. And again...

Sooner or later the Typography panel will not be updated correctly. At that stage you will be able to display it correctly by closing it, clicking on the font, reopening the panel again or something like that. However, sometimes, the actual settings cannot be applied properly.

The behaviour is even more easy to reproduce in Numbers than in Pages.

Have fun!

Hello Magnus

The iMac under 10.5.4 is not available today so I tested under 10.4.11

No problem at all.

From Pages I was able to scan the complete font list with the down arrow.

From Numbers, I did the same with the mouse because when I press down arrow, it's not the Font dialog which receive the key, it's the spreadsheet document.

Yvan KOENIG (from FRANCE lundi 4 août 2008 11:22:27)

Perhaps they broke something in the transition to Leopard. The behaviour is not at all consistent for me.

In Numbers, the font dialogue gets the focus, provided I first click in the search field, as mentioned above. The typography panel happily shows all the different font options as I scroll through. However, it seems fairly arbitrary what is applied.

If I type "fiction" and apply "common ligatures" for Minion Pro, no ligatures are shown in Numbers. If I apply both common and rare ligatures, the fi-ligature is sometimes shown, but not the ct-ligature. It seems pretty random to me.

I'm not sure to reproduce this kind of problems in Pages, but they do happen from time to time.

If I'm remembering of this problem when the imac will be available, I will do tests under 10.5. I'm unable to reproduce the described behavior under 10.4 (I don't write that it doesn't exists).

Yvan KOENIG (from FRANCE lundi 4 août 2008 19:03:32)

Yes, something got broken in the Leopard - Pages link. I have reported exactly the same problem a while ago (see: http://discussions.apple.com/message.jspa?messageID=5885598#5885598). I have also filed a bug report; but, so far, to my complete annoyance, Apple hasn't done anything.

This is a big problem for me, because I have a lot of documents formatted with OpenType fonts, small caps, old numerals, and so forth.

I think the root problem here is with Leopard. Surely if you have some text with both ligatures and small caps set on, the small caps should override the ligatures? But even in TextEdit, most ligatures override small caps.

The above from the thread in the reference below is a misunderstanding of the relationship between the operating system and the intelligent composition model.

The idea is that the individual font file determines how that font file composes. The operating system does not determine how the individual font file composes.

The standard character set ISO-IEC 10646 / Unicode has upper case and lower case, but it only has small upper case for phonetics.

Small upper case (Kapitälchen, kapitæler, scall capitals) are, therefore, formed either by mapping lower case characters to lower case glyphs and lower case glyphs to small capital glyphs or by mapping upper case characters to upper case glyphs and upper case glyphs to small upper case. If for some bizarre behaviour the mapping did not produce a small upper case glyph when the font file contained a lower case ligature for two or more default glyph codes in the output of the CMAP in the first stage of the transform, then this would be a bug in the Apple MORX or Microsoft GSUB programming of that font file and not in the operating system. Similarly, if the intelligent and media independent colour matching of an ICC printer profile turned blue skies green, that would be a bug in the gamut mapping of that ICC printer profile and not a bug in the operating system.

Best,

Henrik


Reference:

http://discussions.apple.com/message.jspa?messageID=5885598#5885598

The idea is that the individual font file determines how that font file composes. The operating system does not determine how the individual font file composes.

Doesn't that concept break down when one is dealing with OpenType features in OS X? I have the impression that the extent to which these features are honored in display depends on the OS (and perhaps the app) and not on the font. 10.4 and 10.5 have different levels of support for OpenType features, and I think different apps do as well.

Doesn't that concept break down when one is dealing with OpenType features in OS X? I have the impression that the extent to which these features are honored in display depends on the OS (and perhaps the app) and not on the font. 10.4 and 10.5 have different levels of support for OpenType features, and I think different apps do as well.

Indeed, the difference between Apple TrueType 2 and Microsoft OpenType is that in the former the transform is determinate, that is, it is defined at the time the transform is made while in the latter the transform is indeterminate and defining it is deferred until the time it is run. The difference between ColorSync 2 and the model of the International Color Consortium is as TrueType 2, that is, the transform is determinate while the Windows Color System in Microsoft Windows Vista is indeterminate runtime rendering. Steve Upton has a summary - he was on the editorial board of the previous icc abc project on the ColorSync home page. Adobe's models are closer to Microsoft's than to Apple's. The reason for PDF/X-3, for instance, is that Adobe's colour manglement model is for deferred, runtime rendering. There is no way whatsoever to build a business model between the professional photographer in the studio and the professional photographer in the print shop.

hh

References:

http://www.color.org/ICCwhite_paper_24ICCandWCS.pdf
http://www.colorwiki.com/wiki/VistasNew_Color_Management_System_-WCS

"There is no way whatsoever to build a business model between the professional photographer in the studio and the professional photographer in the print shop."

Corrigenda:

"There is no way whatsoever to build a business model between the professional photographer in the studio and the professional lithographer in the print shop."

hh

Well, I am surprised to see support for the Typography panel in TextEdit, I would not have expected that. But it shows the same problem I have within Pages:

Contextual Alternates (Opentype feature 'calt') appear to be supported only for two-letter combinations. But there are fonts which define alternate glyphs based on longer character runs.

In my case it is a font with connected glyphs used in primary school. I would be very glad to promote Pages to be used by teachers, but without correct processing of the feature 'calt' there will always be some missing connections.

My comparison is always InDesign CS3 and it's OpenType support.

I am not sure if this is a bug or a feature limitation... 😟

- Michael

I am not sure if this is a bug or a feature limitation

A personal gripe - it is difficult as Adobe applications have not the same support. It is then no use saying that one Adobe application is the reference as opposed to other Adobe applications since the OpenType model does not operate with the idea of application-independent imaging. It's called product differentiation, apparently.

hh

I am not sure if this is a bug or a feature limitation... 😟

Apple's support for OpenType is improving. OS X 10.3 did not support any OpenType features. 10.4 supported some of them. 10.5 supports more. Hopefully the ones you need will eventually be added. You can ask Apple to do that via these links.

http://www.apple.com/feedback/macosx.html
http://www.apple.com/feedback/pages.html

The word processor Mellel is specifically designed to support OpenType rather than Apple's own technology. Whether it does what you need I don't know.