305.35 KB, image/png
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_7) AppleWebKit/534.46 (KHTML, like Gecko) Version/5.1 Safari/534.45 Build Identifier: 5.0 release When rendering text in Warnock Pro under OS X, Firefox uses ligatures outside of the common ligatures group. This makes the font appear strange and unusual. Reproducible: Always Steps to Reproduce: 1. Open link given above. 2. Inspect font rendering closely Actual Results: Font is rendered using ligatures that are not in the common ligatures group (i.e. not only things like fi and ff are rendered with ligatures, but also some contextual alternate ligatures etc.) Expected Results: Only common ligatures are used. I really appreciate the new support for ligatures, but this was a bit too much :)
Please attach a screenshot showing the problems you see. Thanks.
Created attachment 540897 [details] screen shot taken in Firefox 5.0, showing Warnock Pro ligatures The screenshot shows part of the rendered webpage (link given in bug description). I also enlarged a portion that shows the alternate ending ligature at the end of the words (the "o" and the "e" with an elongated end serif) along with a common ligature (the "fi" ligature). Another example would be the unusual capital "L" at the beginning of the name "Lars" which is set in italics in the sidebar. The Warnock Pro font used is provided by Adobe and has the following identification: OTF 1.009;PS 001.000;Core 1.0.26;makeotf.lib(1.11) (It is the standard Warnock Pro font that was distributed with the CS 4.)
I can confirm the bug (firefox, version 6.0.2). It also happens with the font Minion Pro from Adobe. If you want to reproduce the bug, you can get this font for free as part of the Acrobat Reader download from Adobe's web page.
I suspect these are not actually ligatures, but examples of "contextual swash" glyph substitutions. Could you try the latest Nightly build and see if the issue is resolved, as we just landed a patch to stop applying the 'cswh' feature by default (in bug 689179)?
I tried the 2011-10-10 nightly (version 10.0a1) – and the bug is fixed! You are right, what I saw were indeed contextual swashes. Thanks for fixing this :)
Resolving fixed, per comment 5.