By default, we should use required and basic 'liga' ligatures, but not discretionary ligatures such as 'dlig'. http://www.microsoft.com/typography/otspec/featurelist.htm http://developer.apple.com/textfonts/Registry/index.html#Type0 I guess we want "required" and "common" but not the others.

Hmm, it appears from this testcase that we aren't using discretionary ligatures. Compare the output of this testcase (if you have the font) with the samples here: http://www.linotype.com/2326-17829/ligatures.html

I'm not sure what the difference is between Zapfino Extra LT Pro and plain Zapfino, but in this version of the testcase I do see the discretionary ligatures.

Are those ligatures marked as discretionary in the Zapfino font, though? Because when I create that testcase in TextEdit and choose "Ligature ... Use Default", I get those ligatures.

I was assuming that they were discretionary because Safari doesn't show them, but maybe Safari doesn't show ligatures at all?

For Latin text, Safari doesn't use ATSUI and I believe it doesn't do any ligature processing at all.

Ok, Zapfino.dfont is an AAT font. It doesn't have the Opentype liga or dlig tables. It just has an AAT 'morx' table. (see http://developer.apple.com/textfonts/TTRefMan/RM06/Chap6morx.html ). I can't see in that documentation any provision for a distinction between basic and discretionary ligatures. So it seems, unless more evidence turns up, we really have nothing to do here ... except, perhaps, disable ligatures completely for AAT fonts on the grounds that some of the ligatures are discretionary. But that seems like overkill and I'd be reluctant to do it.

OK, so it seems OS X *can* distinguish "common" ligatures from "special" ligatures in Zapfino. In TextEdit you can get extra control over ligatures by pressing command-T to open the fonts pane and then using the "star" dropdown widget at the bottom, choosing "Typography". That gives you a pane where you can toggle "Common ligatures" and "Special ligatures" checkboxes. This appears to be an extra mask that is applied on top of the Format/Font/Ligature/(Use None, Use Default, Use All) setting. In this testcase, "sh" and "st" ligatures are only applied when "Special ligatures" are enabled. "gg" and "fi" ligatures are only applied when "Common ligatures" are enabled. So I'm not sure how this information is encoded in the font file but the distinction is there and controllable through ATSUI somehow. I guess I'll experiment to see if I can get the "Common ligatures" behaviour without "Special ligatures".

This seems to work. No idea how to write an automated test for it though. Maybe we need a way to expose ligature information to script.

Comment on attachment 330810 [details] [diff] [review] fix John's kinda busy

Pushed as 17122:d55aac0ec553.

I backed this out as a potential cause of reftest failures on mac: http://hg.mozilla.org/mozilla-central/index.cgi/rev/da0fa455f1af http://hg.mozilla.org/mozilla-central/index.cgi/rev/30da9cae7cf2 Failure log: http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1219236048.1219238921.6991.gz#err0 This was the regression range: http://hg.mozilla.org/mozilla-central/index.cgi/pushloghtml?fromchange=a836d0b2668a&tochange=d55aac0ec553 So this looked like the most likely culprit.

Those are my reftests from bug 99457. It's not a "real" failure, but we are getting a "fi" ligature in the test text which is making the text shorter and causing lines to break not quite where the reference rendering assumes they should. I assume from conversations we've had in the past that you weren't expecting ligatures in a monospace font?

(In reply to comment #13) > Those are my reftests from bug 99457. It's not a "real" failure, but we are > getting a "fi" ligature in the test text which is making the text shorter and > causing lines to break not quite where the reference rendering assumes they > should. So add letter-spacing: 0.01em to the reftest?

Seems like papering over the issue to me. I think we'd rather always disable ligatures for monospace.

I'm seeing the breakage where we're doing ligatures in monospace textareas, e.g. in this bugzilla comment field, and I'm guessing it's this -- we fixed earlier bugs on this, so we shouldn't regress it. I agree that we should disable ligatures for monospace fonts entirely always.

Changed your mind since when you commented in bug 384395 last year? ;) Bug 384395 - monospace font shouldn't use ligatures

Actually no, I deliberately used the phrasing "we'd rather" to imply that I was speaking for the consensus rather than my personal opinion ;-)

I think ProFont had additional problems with their ligatures (like, I think they had required or somesuch).

I'm confused about why this patch would make us do *more* ligatures. It's only supposed to decrease the ligatures we do. Could ATSUSetAttributes be setting up some default ligaturization (which in some cases is no ligatures at all), and then in SetLigatureFeatures we're blindly overriding that? Maybe we need to add an ATSUGetFontFeatures call in SetLigatureFeatures and then only turn them off. I'll experiment.

I'm aghast that Apple's "Courier" font has ligatures (on Leopard).

This works.

I am copying here the comments I wrote at bug 450151: The rules about fonts are now quite well defined. The world is at the threshold of supporting all sorts of scripts and languages on the computer. Following standards correctly is the way to go forward. If a font misbehaves, the user will replace it with another one that suits them. Let the marketplace decide, not Mozilla. The font makers have the OpenType standard. They should update their fonts according to its rules porting them to Unicode compliant formats. It’s not hard work, and more importantly, it’s not Mozilla’s job to mess with them: http://www.microsoft.com/typography/specs/default.htm Then there is a way to categorize fonts programmatically by way of a number stored inside the font file. This should help with the next item following: http://www.w3.org/Printing/stevahn.html There are generic font families -- a fallback method when the specified font is missing: http://www.w3.org/TR/REC-CSS2/fonts.html#generic-font-families OpenType categorizes the fonts according to Unicode scripts. Each script has a set of features for all languages that come under it or when the ‘default’ language is specified. The app, in this case, Firefox should allow these features generically for that script. For Latin script, they should simply allow the ‘liga’ feature WITHOUT REGARD to whether they are monospace or proportionate. If a particular language under a script requires an additional feature, Mozilla could allow such special cases via extensions or by building them into the app by following the OpenType specification. it is a simple, straight forward algorithm. The purpose for the monospace and proportionate categorization was to allow straight-edge alignment of text in tables and such during DOS / Windows 3.1 days. That classification is now superseded with font-family categorizing. Monospace fonts still have their utility, but should not be considered a broad category but a special feature of a font like one that emulates typewriter print. If Mozilla wants, they can define monospace font in each OS, such as Courier, just to help user remember it. The categorization should be according to font-families and not monospace / proportionate. For instance, I’d like to be able to select my favorite Fantasy family font. Thanks.

Comment on attachment 334803 [details] [diff] [review] fix v2 Thank goodness rebus pictures are now disabled! :) (Sorry this review took a bit, I missed it in my inbox!)

Pushed b0d995128795.

Comment on attachment 334803 [details] [diff] [review] fix v2 I'd like to take this in 1.9.0. The patch is fairly simple and low-risk, it's baked for a while on trunk, and it fixes an issue that matters a lot to some people.

Comment on attachment 334803 [details] [diff] [review] fix v2 Not approved for branch, doesn't meet the new branch criteria mconnor laid out (that is, it's a cosmetic "nice to have" and will be fixed soon in the next release).

In Firefox 3 on my Mac, I had this rendering: http://dracos.co.uk/temp/zapfino/ff3.png Now in Firefox 3.5, I have this: http://dracos.co.uk/temp/zapfino/ff35.png I obviously prefer the FF3 rendering, and presume this bug is the cause of the change. Is there anything I can do about it - is there some way I can turn on discretionary ligatures for a particular section of my web page? Or do I have to revert to having an image of the text, something I'd really rather not do, as I was quite pleased with FF3's rendering?

We need CSS extensions to let authors control what Opentype features are used. We're working on that.