Bug 45239 – failure to display required ligatures

• Status: UNCONFIRMED
• Component: Text

Steps to reproduce
===================
1. Have a Latin fraktur (Latf) font that features correctly encoded required ligatures (e.g. the fonts at http://unifraktur.sf.net).
2. Use that font on a webpage (e.g. via style="font-family: YourFont;")
3. Display that page in Safari.

Expected result
===============
Fraktur typography features required ligatures (ch, ck, ſt, tz). A correct fraktur font should encode them as required ligatures (through OpenType or AAT). A browser should honor that encoding – Firefox on Max OS X already does it!

Actual result
=============
Safari (unlike Firefox!) appears not to display any ligatures in the Latin script at all, not even the required ligatures.

Example URL
=============
This is an example of a webpage that embeds (through @font-face) a Latin fraktur font with correctly encoded required ligatures. The webpage also shows screenshots of the correct text rendering from Firefox:
http://unifraktur.sourceforge.net/letterspacing.html#browser_test

[Alexey Proskuryakov]

Were you testing on Mac OS X 10.5? This works fine for me on 10.6, so I think that this is simply not supported on older Mac OS X versions.

(In reply to comment #1)
I'll have to test it again. I have been pointed to the CSS definition "text-rendering: optimizeLegibility;" that causes Safari to display ligatures. After including that definition, the ligatures are displayed at least on Mac OS X 10.5.

However, if an explicit opt-in via additional CSS is necessary, then I think this is still a failure to display required ligatures. After all, the point about required ligatures is that they are required.

Additionally, even when I have explicitly opted-in ligatures via additional CSS, Safari still fails to distinguish between "rlig" ligatures and "liga" ligatures like Firefox does when letterspacing is increased.

Negative. On this Mac OS X 10.6.4 with Safari Version 5.0.1 (6533.17.8), the required ligatures are not displayed either:

http://unifraktur.sourceforge.net/letterspacing.html#browser_test

unless you explicitly opt-in to display them by using the additional (and invalid) CSS specification (style="text-rendering: optimizeLegibility;"):

http://unifraktur.sourceforge.net/letterspacing.html#browser_test_optimizelegibility

But even then, Safari will still fail to distinguish between required ligatures and other ligatures when letterspacing is increased – unlike Firefox, as the Screenshots of Firefox's correct display demonstrate.

And an additional test with the current Webkit Nightly Build – Safari Version 5.0.1 (6533.17.8, r67077) – yields exactly the same incorrect results.

I suspect that Alexey Proskuryakov happened to visit the test page in that short window of time when I had indiscriminately added the additional CSS, so it is was only my unthoughtful tinkering with the test page that made him suppose the display was correct. Of course, I could be mistaken.

[Alexey Proskuryakov]

Yes, text-rendering: optimizeLegibility was present at the time I looked at the page. Requiring it shouldn't come as a surprise - the whole point of optimizeLegibility is to enable more typography features at the cost of worse performance.

Ligature display should not solely depend on opt-in CSS. It should depend on the script and on the ligature type. In fact, it already does. Nobody would suggest to make Arabic licatures dependent on opt-in. This would make no sense since these ligatures are required. Without them, it is just plain wrong typography. This is no different with the required ligatures of the Latin script fraktur typography: Without required ligatures, the typography is just plain wrong. The point of required ligatures is that they are required. Why should Firefox be the only browser to honour the requiredness of required ligatures?

[Glenn Adams]

Note the thread at [1]. The issue appears to be whether the complex text path is enabled by default or not. Apparently there are various triggers for enabling this in WK and some other browsers. OTOH, FF appears to enable by default.

IMO the complex text path should be enabled by default and have opt-out behavior, not opt-in (via various undocumented means).

[1] http://lists.w3.org/Archives/Public/www-style/2012Jul/0155.html

Required ligatures are required, so it shouldn’t be up to the author to enable them.

[Glenn Adams]

(In reply to comment #7)
> Required ligatures are required, so it shouldn’t be up to the author to enable them.

Does that mean you agree with my opinion expressed in comment #6: that complex text path be enabled by default?

(In reply to comment #8)
> (In reply to comment #7)
> > Required ligatures are required, so it shouldn’t be up to the author to enable them.
> 
> Does that mean you agree with my opinion expressed in comment #6: that complex text path be enabled by default?

No.

[Glenn Adams]

(In reply to comment #9)
> (In reply to comment #8)
> > (In reply to comment #7)
> > > Required ligatures are required, so it shouldn’t be up to the author to enable them.
> > 
> > Does that mean you agree with my opinion expressed in comment #6: that complex text path be enabled by default?
> 
> No.

so, let me understand better: you say required ligatures are required and should not require the author to enable... since their support is predicated on complex text path, then does that not imply the latter must be enabled by default? or are you suggesting a particular algorithm for enabling complex text?

(In reply to comment #10)
> (In reply to comment #9)
> > (In reply to comment #8)
> > > (In reply to comment #7)
> > > > Required ligatures are required, so it shouldn’t be up to the author to enable them.
> > > 
> > > Does that mean you agree with my opinion expressed in comment #6: that complex text path be enabled by default?
> > 
> > No.
> 
> so, let me understand better: you say required ligatures are required and should not require the author to enable... since their support is predicated on complex text path, then does that not imply the latter must be enabled by default? or are you suggesting a particular algorithm for enabling complex text?

There are multiple ways to resolve this without enabling the complex text path by default. An algorithm that selects it conditionally is one way to do so.

[Eric Seidel (no email)]

It's very difficult for me to tell from your test what's going on.  (Partially because I find that font so difficult to read.)

beſitze appears with an f-i ligature on the Open Type line, but not on the ATT and Graphite lines.  Is that what your attempting to show?

Ideally we'd produce a self-contained test case and attach it to this bug.  But we can also work from your external test case, assuming you can help me make sure I understand what you're trying to show.

Vielen Dank!