846617 - text shaping with AAT Myanmar fonts broken in Firefox 19

Status: RESOLVED FIXED

(Core :: Layout: Text and Fonts, defect)

Description

[arky [:arky]]

Attachment: MM3 Font test with Firefox 19

Latest Firefox 19 does not render fonts correctly. Tested this webpage[1] with Firefox 18 and latest Firefox 19 on Ubuntu Linux. 

This problem can reproduced on Firefox Mobile nightly as well.




[1] http://mozillamyanmar.org/2013/02/05/%E1%80%99%E1%80%B1%E1%80%AC%E1%80%BA%E1%80%87%E1%80%AE%E1%80%9C%E1%80%AC-%E1%80%99%E1%80%BC%E1%80%94%E1%80%BA%E1%80%99%E1%80%AC/

Comment 1

[arky [:arky]]

Attachment: MM3 Font test with Firefox 18

Comment 2

[arky [:arky]]

Attachment: Testcase for negative letter-spacing issue

Andrew Cunningham suggested this might be caused by negative letter spacing. Created this testcase to reproduce this problem.

Comment 3

[Jonathan Kew [:jfkthame]]

Indeed - this is behaving as designed. When the author specifies non-default letterspacing, we disable the 'liga' and 'clig' features, because it doesn't really make sense to use ligatures with letterspaced text.

(The word "office" with letterspacing should look like "o f f i c e", not "o f fi c e" or even "o ffi c e".)

So don't use letterspacing if you want all ligatures to be applied.

The root of the problem here is that the Myanmar3 font is using the 'liga' and 'clig' features, which will only be used when the text is rendered with its "natural" spacing, to achieve "shaping" that actually needs to happen regardless of letterspacing modifications. If the font used the 'rlig' (required ligatures) feature instead, the ligatures would still be applied, as we do not disable 'rlig' even when letterspacing is present.

Comment 4

[Axel Hecht [:Pike]]

Jonathan, is there a bug for the change in 19 that we can reference?

arky, do you have contacts to the folks that created the font?

Comment 5

[Jonathan Kew [:jfkthame]]

The change in behavior is a result of bug 797398, where we switched from pango to harfbuzz for all text shaping on Linux. AFAICS, the pango backend didn't implement the feature of disabling non-required ligatures when letterspacing.

(Previously, only certain scripts such as "simple" Latin/Cyrillic/etc, Arabic, and Hebrew were shaped through harfbuzz; for Indic and SEAsian scripts, we'd fall back to pango.)

Comment 6

[arky [:arky]]

(In reply to Axel Hecht [:Pike] from comment #4)
> arky, do you have contacts to the folks that created the font?

Yes, I do know them.

Comment 7

[Axel Hecht [:Pike]]

Can you reach out to them and get them to fix the font? harfbuzz not rendering it as intended sounds like a good argument, and a good way to confirm it's fixed.

Comment 8

[arky [:arky]]

(In reply to Axel Hecht [:Pike] from comment #7)
> Can you reach out to them and get them to fix the font? harfbuzz not
> rendering it as intended sounds like a good argument, and a good way to
> confirm it's fixed.

Thanks, Will get on it. I believe there are whole bunch of fonts (including non-standard) in use for Burmese content. Will gather feedback and file bugs accordingly. 

AFAIK Tharlon font project (http://code.google.com/p/tharlon-font/) is more active development. So I filed an upstream bug there.

Comment 9

[Ngwe Tun]

Hi Jonathan and Arky,

Please find my attachment about my finding of Tharlon rendering in Mac and Windows 8. I haven't try Windows 7 and Windows XP. I don't think it is an issue by opentype font tags. We can use it in other browser as well. Hope, It should be solved by Mozilla Rendering or any rendering engine. Do we need to take care of opentype tags in Browser Level. I don't think Myanmar3 or other font will be replaced with *rlig* so far.

I've faced with native AAT Burmese Font in Mac too. It needs to be fixed by Browser. It doesn't happen in Ver 18.0

Comment 10

[Ngwe Tun]

Attachment: native AAT Font Myanmar Sangem MN in Firefox 19 at MAC.

Comment 11

[Ngwe Tun]

Attachment: Tharlon font rendering well in Windows 8.

Comment 12

[Ngwe Tun]

Attachment: broken test case html file with tharlon font rendering in chrome at MAC

Comment 13

[Ngwe Tun]

Attachment: broken test case html file with AAT Myanmar Sangem MN font rendering in chrome at MAC

Comment 14

[Jonathan Kew [:jfkthame]]

There are a couple of distinct issues here:

(1) Myanmar fonts that rely on OpenType 'liga' and 'clig' features to produce all the "shaped" forms, reordered glyphs, etc., will NOT work when letterspacing is applied, as explained in comment #3. This is by design; setting non-default letterspacing disables the ligature features.

To make a ligature-based OpenType font work even when letterspacing is applied, you need to use the 'rlig' feature, as this is NOT switched off automatically when letterspacing is applied.

I don't know whether all other applications apply the 'rlig' feature, or if there are some that *only* apply 'liga' and 'clig'. If that's the case, a solution for font developers would be to include the same lookups in 'rlig' *and* in the 'liga'/'clig' features, so that whichever feature(s) the engine applies, the same lookups will be used.

(The better long-term solution is to follow the new 'mym2' script tag and shaping specification that MS has introduced with Windows 8. But that won't work with older shaping engines.)

(2) The native AAT Myanmar font "Myanmar Sangam MN" that ships with OS X is indeed broken in Firefox 19. This is because Myanmar is missing from the list of "complex" scripts for which we prefer Core Text shaping if AAT tables are present. We should fix this; I'll attach a patch.

Comment 15

[Jonathan Kew [:jfkthame]]

Attachment: support AAT Myanmar fonts via Core Text shaping.

Comment 16

[Ngwe Tun]

Thanks Jonathan,

We will try to change *rlig* instead of *clig* and *liga*. It will not take time to change for font developer. It will not be easy to change or upgrade by end user. Can you ship that font file with mozilla firefox ver 19.1 or something. IT would be special case. But we really needed for the end user. Why It is not impact in other browser? And will it be problem in other software too?

Best

Ngwe Tun

Comment 17

[Ngwe Tun]

Attachment: padauk font not rendered (not reordered) in mozilla firefox MAC

Comment 18

[Ngwe Tun]

Dear Jonathan,

I found another issues in Mozilla Firefox 19.0 at MAC. Padauk font is not properly rendered in Firefox as well. So, Can you ask to change *rlig* opentype features to Martin Hosken?

Best

Ngwe Tun

Comment 19

[Jonathan Kew [:jfkthame]]

I see Padauk also uses the 'clig' feature; so yes, that will fail if letter-spacing is applied. Using 'rlig' instead (or in addition) would be better, I think, as "ligatures" used to implement reordering should not be considered optional. I'm cc-ing Martin on this bug so he'll see the discussion.

However, remember that all this applies *only* if non-zero letter-spacing is applied; otherwise, fonts like these should work as intended (right?). So it is not a universal problem; only authors who actually use the CSS letter-spacing property need to be concerned about this issue.

Also, note that if you add explicit OpenType feature tags to the style:

  -moz-font-feature-settings: 'liga', 'clig';

then the features *will* be applied even when letter-spacing is present. So for authors who insist on using letter-spacing, there is a workaround that will solve the problem even without updating the fonts.

Comment 20

[lang.support]

Attachment: incorrect letter spacing ebtween grapheme clusters

Although there seems to be a bug in how letetr spacing is calculated between grapheme clusters.

I tried the following rules in a test page

font-family: TharLon;
letter-spacing: 20px;
-moz-font-feature-settings: 'clig', 'liga';
font-weight: normal;

spacing before a cluster containing a medial-ra is much greater than between other graphemes. I assume the width of the medial-ra is being included despite wrapping around other characters?

Comment 21

[Jonathan Kew [:jfkthame]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/781d180f8a0f

Comment 22

[Jonathan Kew [:jfkthame]]

I'm morphing the bug summary to reflect the actual bug we're fixing with the patch here (the regression for the AAT Myanmar font shipped with OS X).

The other issue described here - shaping failure for ligature-based Myanmar fonts when letterspacing is used - is not really a bug; the feature is working as designed, but the fonts are using a mechanism that's not appropriate for basic script shaping, as it's not required to be always enabled. Font developers and/or page authors should address this by using other OpenType feature tags ('rlig'), and/or by explicitly forcing 'liga' and 'clig' to be re-enabled when letterspacing is used, as discussed above.

Comment 23

[Jonathan Kew [:jfkthame]]

(In reply to lang.support from comment #20)
> Created attachment 720488 [details]
> incorrect letter spacing ebtween grapheme clusters
> 
> Although there seems to be a bug in how letetr spacing is calculated between
> grapheme clusters.
> 
> I tried the following rules in a test page
> 
> font-family: TharLon;
> letter-spacing: 20px;
> -moz-font-feature-settings: 'clig', 'liga';
> font-weight: normal;
> 
> spacing before a cluster containing a medial-ra is much greater than between
> other graphemes. I assume the width of the medial-ra is being included
> despite wrapping around other characters?

I'm not seeing this in my testing here. Are you sure there's not an extra space or something in your testcase? Which Firefox version (and platform)?

If there's a real issue here, please file a new bug about it, and attach the actual testcase you're using.

Comment 24

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/781d180f8a0f

Comment 25

[Jonathan Kew [:jfkthame]]

Comment on attachment 720415 [details] [diff] [review]
support AAT Myanmar fonts via Core Text shaping.

[Approval Request Comment]
Bug caused by (feature/regressing bug #): 797402

User impact if declined: Myanmar (Burmese) script text will not display correctly when using the default OS X Myanmar font.

Testing completed (on m-c, etc.): Confirmed to fix the issue in local build and in current m-c Nightly.

Risk to taking this patch (and alternatives if risky): Minimal risk: simple change in Mac-only code that affects -only- the Myanmar Unicode codepoints. The alternative of reverting bug 797402 would adversely affect a much larger number of Indic OpenType fonts, for which harfbuzz shaping is better than Core Text.

String or UUID changes made by this patch: None

Comment 26

[Lukas Blakk [:lsblakk] use ?needinfo]

Comment on attachment 720415 [details] [diff] [review]
support AAT Myanmar fonts via Core Text shaping.

Approving for uplift since this is a low risk fix for a small user group that got regressed in 19.

Comment 27

[Jonathan Kew [:jfkthame]]

https://hg.mozilla.org/releases/mozilla-aurora/rev/7727abce31f8
https://hg.mozilla.org/releases/mozilla-beta/rev/86c4114fddf0

Comment 28

[Gen Kanai [:gen]]

Is this ready for testing in the latest Aurora?

Comment 29

[Jonathan Kew [:jfkthame]]

As of now, the current Aurora build is dated 2013-03-06, but it will have been built earlier in the day, before the patch landed there. To confirm this, about:buildconfig says it was built from 357d21b20bf0, which the hg log confirms is an earlier changeset.

So you'll need to wait for an Aurora build dated at least 2013-03-07.

Comment 30

[Ioana (away)]

Attachment: Firefox 19 vs 20

Windows 7 32bit - Mozilla/5.0 (Windows NT 6.1; rv:20.0) Gecko/20100101 Firefox/20.0 (20130307075451)

I've been trying to reproduce this bug in order to verify it, but the text on the web page in comment 0 looks the same on Fx 19.0 and Fx 20b4 - Please see the attachment.

Are there any steps for reproducing this bug not mentioned above?

I've also tried to work with the reduced test case in comment 2, but the chars there are displayed as simple squares for me. My Windows doesn't offer the option to set this language for it, nor can I find a Firefox locale for it. The mozillamyanmar.org page is displayed fine.

Comment 31

[Jonathan Kew [:jfkthame]]

The fix here relates only to AAT fonts, which are specific to Mac OS X. (I've just fixed the Platform field to reflect this.)

The original example given was not really a valid bug, it was expected behavior where letterspacing is applied, as discussed in comment 3; but there was genuine brokenness for AAT Myanmar fonts on OS X, as per comment 14. So that's what we have fixed here.

To verify, it's best if you set gfx.downloadable_fonts.enabled to FALSE in about:config, because many Myanmar sites provide custom downloadable fonts that will take precedence over the default OS X font, and thus hide the problem.

Then visit pages such as http://mozillamyanmar.org/ or http://www.bbc.co.uk/burmese/. In Firefox 19, the text is obviously broken (both in the page, and in the tab title of the BBC page); in latest Aurora (or in Nightly) it should render correctly.

Comment 32

[Ekanan Ketunuti]

On Windows 7 32bit Mozilla/5.0 (Windows NT 6.1; rv:22.0) Gecko/20130303 Firefox/22.0

http://mozillamyanmar.org/2013/02/05/%E1%80%99%E1%80%B1%E1%80%AC%E1%80%BA%E1%80%87%E1%80%AE%E1%80%9C%E1%80%AC-%E1%80%99%E1%80%BC%E1%80%94%E1%80%BA%E1%80%99%E1%80%AC/

text shaping is broken if gfx.font_rendering.harfbuzz.scripts set to -1

Comment 33

[Jonathan Kew [:jfkthame]]

See the earlier comments here.

The brokenness of the heading on that page happens because the page sets CSS letterspacing on the element. This is expected behavior, as described in comments 3 and 14.

It is not a Firefox bug, it needs to be fixed on the site - by removing the use of letterspacing, or by adding explicit OpenType feature tags to re-enable the ligatures, or by using a font that does not rely on "non-required" ligature features to achieve basic (required) shaping.

Comment 35

[u279076]

Flagging for verification in Firefox 20, 21, and 22.

Comment 36

[Manuela Muntean [Away]]

Verified fixed on a Mac OSX 10.7.5 machine, based on comment 31, with Firefox 20 beta 5, build ID: 20130313170052.

Comment 37

[Simona Badau, Desktop QA]

Verified as fixed on Mac OS X 10.8:
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:21.0) Gecko/20100101 Firefox/21.0 Build ID: 20130401192816

Comment 38

[Tracy Walker [:tracy]]

mass remove verifyme requests greater than 4 months old