1425711 - Use decomposed Unicode form if precomposed one is unavailable but called for

Status: UNCONFIRMED

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

Description

[paperboyo]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:56.0) Gecko/20100101 Firefox/56.0
Build ID: 20170922200134

Steps to reproduce:

Hello,

Works in Blink. When using a font that does support a letter, a combining mark and, optionally, mark/mkmk feature to position them, but doesn’t support a precomposed glyph to render the above combination, Firefox should dynamically render correct character when a composed form is called for (instead of using a fallback font).




Actual results:

E.g. a font contains e (u0065) and combining ogonek (u0328), but doesn’t contain ę (u0119). When text in this font contains ę (u0119), it’s rendered using a fallback font.




Expected results:

Instead it should be rendered as a combination of e (u0065) and combining ogonek (u0328) in the original font. Firefox should be able to decompose on-the-fly. This, combined with mark/mkmk would allow for much, much smaller font files (see e.g. https://github.com/twardoch/ttfdiet).

This is related, a mirror-like reflection of already supported https://bugzilla.mozilla.org/show_bug.cgi?id=728866 (although, this doesn’t work for me in Stylo 59.0a1 2017-12-16 somehow)...

Thank you.

Regards
m.

Comment 1

[paperboyo]

Attachment: Decomposition on-the-fly not working in Firefox

Comment 2

[Jonathan Kew [:jfkthame]]

This is closely related to the issues in bug 543200, though this exact case isn't the main focus of the existing discussion there.

Comment 3

[Jonathan Kew [:jfkthame]]

Are you sure this works in Blink? On which platform, and what specific fonts are involved in your example screenshot? I just tried a quick test with Chrome 63 on macOS, and I'm seeing font fallback rather than decomposition for the U+1ebc character with this:

  data:text/html,<div style="font-family:zapfino">&%23x1ebc; E&%23x0303;

Comment 4

[paperboyo]

Hello,

Thanks for the interest! I’m absolutely, definitely never-ever sure of anything, but, yeah... pretty sure. Sorry: I’m on Windows 10 (16299.98), Chrome 64.0.3282.24, Firefox 56.0 and 59.0a1 (2017-12-17).

I’m not allowed to share the font above, but I have taken open source https://github.com/adobe-fonts/source-serif-pro/releases/tag/2.000R and ran it through latest https://github.com/fonttools/fonttools:
pyftsubset.exe .\SourceSerifPro-Bold.ttf --gids=6,794,795
(bastardised font attached)

Attaching screenshots illustrating the behaviour using this font and `u1ebc u0045+u0303` on http://www.impallari.com/testing/.

---

This is probably inappropriate and I should open another issue, but my understanding of all this (and the terminology) is so weak, that this may create more confusion than just asking here. Plus, this is related (I hope!):

As far as I understand, mentioned https://bugzilla.mozilla.org/show_bug.cgi?id=728866 should help in the opposite direction: rendering decomposed forms using existing precomposed glyphs supported by the font. Pt. 11 here: https://gist.github.com/paperboyo/f5809901b044cd49d7e7ada140fa1584 (screenshots taken from https://www.theguardian.com/film/gallery/2015/jul/15/ingrid-bergman-from-gawky-teenager-to-international-film-star-in-pictures) illustrates that Chrome is cleverly using e.g. a supported u00F6 when `u006f+u0308` is called for (u0308 is NOT even present in this font, just u00a8!). Firefox fails :-(

I haven’t yet read https://bugzilla.mozilla.org/show_bug.cgi?id=543200, but maybe this will take care of this second issue?

Thank you! Please let me know, if you want me to clarify anything.

Regards
m.

Comment 5

[paperboyo]

Attachment: Bastardised SourceSerifPro-Bold.subset.ttf used in both Decomposition on-the-fly Firefox 56 FAIL.png and Decomposition on-the-fly Chrome 64 OK.png

Comment 6

[paperboyo]

Attachment: Decomposition on-the-fly Firefox 56 FAIL.PNG

Comment 7

[paperboyo]

Attachment: Decomposition on-the-fly Chrome 64 OK.PNG

Comment 8

[paperboyo]

In my comment above (https://bugzilla.mozilla.org/show_bug.cgi?id=1425711#c4) the URL given no longer illustrates the problem as the font there changed for one that contains glyphs in the Combining Mark area (so Firefox is able to compose correctly).

The problem illustrated at the gist.github URL in the same comment is still very much a real one, though (Firefox can’t compatibility-compose on-the-fly as opposed to Chrome), which makes me suspect that https://bugzilla.mozilla.org/show_bug.cgi?id=728866 isn’t really fixed. At least – not fully.

Unless I’m missing something, which is very much possible…