See the test in http://opentype.info/download/featuretest.zip.
I don't have current Windows or Linux builds to test at the moment, but I'd expect that this applies there as well; it's not Mac OS X-specific. Contextual alternates ('calt') is not one of the OT features that is enabled by default in the engines I'm familiar with, so the behavior is correct in the absence of some kind of optional feature setting. To address this, we need a mechanism to allow page authors to specify optional font features, which in turn requires extensions to CSS (or some other idea?).
So it's something we should not enable by default?
It's hard to say! This is one of the frustrating things about OpenType: so much vagueness in the spec, leaving it up to the various shaping engines to decide how to behave and which features to apply. I note that the feature registry suggests it *should* be active by default: http://www.microsoft.com/typography/otspec/features_ae.htm#calt On the other hand, the documentation for the "standard scripts" engine does *not* list this as one of the features that is applied by default: http://www.microsoft.com/typography/otfntdev/standot/features.aspx This implies that Microsoft treats it as one of the "many more features (that can be activated at the user's discretion)". The Apple (CoreText) behavior is consistent with this; TextEdit.app does not use the Contextual Alternate by default, but the user can select it in the Typography panel. Currently, the ICU layout engine and Pango both appear to follow this interpretation, too. However, I just tried WordPad on Vista and it appears that MS has now decided to apply 'calt' as one of the default features. InDesign CS4, which uses Adobe's engine (so it is independent of the host platform) also does apply 'calt' by default. So it looks like the direction things are going is for 'calt' to be active by default, but this should be addressed by the underlying font shaping engines. I guess that on Vista, we'd get 'calt' automatically through Uniscribe, but on the other platforms we're dependent on other engines. Pango already has an open bug regarding this: http://bugzilla.gnome.org/show_bug.cgi?id=343111. I'll file a bug with Apple regarding the default features used by CoreText.
For reference, this is filed as rdar://6356597.
If we think contextual alternates should be enabled by default for Web authors, then we should feel free to configure the engines that way whenever possible. However, this change won't make beta2 so it might be best to hold off until after Firefox 3.1/Gecko 1.9.1. That would give us a lot more time to collect feedback before a release. So, no urgency here. Note that even when we get support for controlling this stuff in CSS, it will still be very important to choose good defaults, so this question and others like it won't go away. One policy question I have is whether it's better to match other apps on the platform by default (and thus tend to leave font engine settings at their defaults) or whether it's better to have consistent behaviour in Gecko across platforms (and thus try to configure font engines to roughly the same level). Hmm...
Right, we could attempt to turn the feature on even if the engines don't do it by default (though it's not immediately clear what attributes to set on the ATSUStyle to achieve this; some investigation will be required). But it's not urgent. In this instance, we can see from the feature registry, together with the default behavior of Vista and ID CS4 (as well as the pre-existing Pango bug report and proposed patch), which way things are heading for the future. Given this, I think we should try to support the feature by default, even if that's not yet widespread on some platforms. Let's be a leader rather than a follower, at least in cases where it's clear which direction to lead. :-) There may well be other situations where the "right" default is less clear-cut, and a general policy might be helpful, but in this case we can (IMO) regard it as a flaw in some existing engines, and working around flaws to provide better results is normally a good thing.
I tried to test this on Mac OS X by turning on the Contextual Alternates feature on the ATSUStyle, but at least with the Featuretest001 font mentioned here, this does not appear to work correctly. (There is no feature type/selector for this in the Apple font feature registry, as it's an OpenType feature rather than a native AAT one, but using the ATSUI font APIs, it appears to be mapped to feature 36, selector 0.) For testing purposes, I hacked this into the DisableUncommonLigatures() function that is used while initializing the style objects. However, adding this feature to the style attributes seems to *disable* the previously-working GSUB-based features; only the kerning still works. I'm guessing that this is an ATSUI bug whereby it doesn't properly handle applying features to OpenType fonts, even though it tries to map them to AAT and expose them through the same APIs. The Typography panel (e.g., in TextEdit.app) is able to do this but I suspect that may be going through CoreText rather than ATSUI. We could investigate this further and possibly file a bug with Apple, but I think it is better to look at adopting CoreText first (bug 389074) and then re-visit this issue.
From my type designer's perspective the thing is: Basic features (such as liga, kern) offer a typographic improvement for the layout, but it doesn't really hurt, if they are not used. But contextual features might be essential for a font to work at all. I showed an example in this image: http://www.opentype.info/static/clig.png (Don't mind the name "clig.png", the font actually uses calt) This font simply cannot be used, if calt isn't available. So from my point of view these contextual features are rather essential than optional.
OK, I think we agree this should be done but it doesn't seem like something we can do for FF3.1, which will be released quite soon.
The test in that zip indicates that CALT is enabled in Nightly (on Linux/x64), marking this as fixed. Please re-open if this is in error.
Status: NEW → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.