Harfbuzz's OT shaper can behave sometimes differently to uniscribe. Sometimes copyrighted fonts like (Noori Nastaiq MT) only display correctly when using uniscribe. (which is not necessary caused by halfbuzz shaping bugs) \u062F\u06CC\u0646\u0627 "دینا" (Warning - the above line is unlikely to be display anything like it does using the "Noori Nastaiq MT" font) Since Halfbuzz has a uniscribe backed it would be nice to be able to enable it via a GeckoPreference.
Summary: Feature Request: Allowing using of Harfbuzz uniscribe backend → Feature Request: Allow use of Harfbuzz uniscribe backend
Created attachment 8643920 [details] [diff] [review] proof of concept patch Patch allows turning on harbuzz uniscribe shaper with the following pref: "gfx.harfbuzz.shaper" = "uniscribe" This patch is currently base on firefox 33, will rebase for sending to the try server.
https://treeherder.mozilla.org/#/jobs?repo=try&revision=f7c6fa725cd0 For some reason tryserver didn't auto post this?
I'm not sure how I feel about this. In general, I'd prefer not to add a code path that in principle shouldn't be needed: harfbuzz should be able to render all OpenType fonts correctly. So on the harfbuzz side, we should look into the issue with Noori Nastaliq, and see if we can get it fixed. Eliminating the Uniscribe (and DirectWrite) shaping backends we used to have in Gecko was a deliberate choice, to simplify our code and reduce the maintenance burden and attack surface. (Historically, we have seen a number of issues related to flaws deep inside Uniscribe, which are potentially exposed to attack via malicious webfonts.) So I'd be hesitant to add one of them back (in a different form) unless the case for it is really compelling. Note also that I don't think the hb-uniscribe backend is necessarily considered production-quality; it exists in HB primarily for comparison purposes, and may not have undergone much review/testing. Meanwhile, let's look into the harfbuzz/Noori issue over on the harfbuzz list. cc'ing jdaggett for any additional thoughts.
I agree with Jonathan here. Using harfbuzz across all platforms assures consistency of results, it's less maintenance and, most importantly, it means we're not exposed to security-related issues in Uniscribe/DirectWrite shaping code. In the past we've reported security-related bugs to Microsoft and it's often taken a *long* time to get them fixed (e.g. I can remember a *year* wait to get a cmap-related bug fixed). So I think we should log this issue as a bug against harfbuzz and get it fixed upstream rather than switching to Uniscribe/DirectWrite for shaping under Windows.
The HarfBuzz Uniscribe backend is NOT supposed to be used in production (same about the DirectWrite one). I think this can be closed.
Looks like the consensus here is "wontfix".
Status: UNCONFIRMED → RESOLVED
Last Resolved: 7 months ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.