-
|
Reproduced in both Firefox 137.0 and Chromium 135.0.7049.52 on Linux Mint 22. The screenshots are from Firefox. Chromium results differ slightly in irrelevant ways. Open this URL and look at the rendered result: https://fonts.google.com/specimen/Fira+Code?preview.text=A%20-%3E%20B,%20%D7%90%20-%3E%20%D7%91
Now cut the text out of the input box (leaving it blank), then paste it back in:
There are two issues here:
|
Beta Was this translation helpful? Give feedback.
Replies: 12 comments 19 replies
-
|
It's a shortcoming of the font. The font does NOT support right-to-left features like |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for the report though. Sorry for the terse reply. |
Beta Was this translation helpful? Give feedback.
-
|
It's much more tolerable when you apologize :) Are you aware of any font that supports this ligature and works correctly in RTL and in LTR? If not, are you certain that HarfBuzz will produce correct results if someone crafts such a font? I don't have the know-how to test any of this beyond what I've already found. |
Beta Was this translation helpful? Give feedback.
-
There is no |
Beta Was this translation helpful? Give feedback.
-
I'll elaborate a bit later. :) |
Beta Was this translation helpful? Give feedback.
-
I see! Thanks for the patience. I'm clearly out of my depth, so if you're certain this is not an issue, I'm happy to accept that. |
Beta Was this translation helpful? Give feedback.
-
|
The question about fonts which support |
Beta Was this translation helpful? Give feedback.
-
|
This is what happens in OpenType text shaping for this case: The text has "->", and the bidi algorithm converts it to "-<" logically but to be rendered right-to-left. So far so good. The font however, has features that see the text "-<" in that order, not knowing that the text is right-to-left, and they produce the shape you see. OpenType lookups in general don't know which direction they are operating on. It's a shortcoming of OpenType: harfbuzz/boring-expansion-spec#57 In the 2000s, to work around this limitation, four feature tags were standardized: https://learn.microsoft.com/en-us/typography/opentype/spec/features_pt#tag-rtla In my previous comment I said So. Currently, Fira Code, I suppose, uses the feature tag I still intend to fix properly by way of the first issue linked above, to make the lookup data in the font tell the shaper which direction it expects the text in, such that the shaper and the font designer agree on the direction. That is how, AAT fonts work for example. But that is not in OpenType and not in the pipeline yet. So, for now, what I said about Please file an issue with Fira Code and link here. @khaledhosny and I can adviseon how to do it. |
Beta Was this translation helpful? Give feedback.
-
Since shaping is applied on the logical order of the text, L2 is irrelevant here. L4 is implemented as part of shaping as well, so is mirroring. L2 basically just orders different runs within the line. |
Beta Was this translation helpful? Give feedback.
-
That's the part I'm not sure about MS implementation. Only testing can tell. |
Beta Was this translation helpful? Give feedback.
-
That's not according to UAX#9. It says (paragraph 3.5) that shaping is applied after rule I2, and at that moment neither reordering nor mirroring were applied yet, so you still have "->" and "=>" to shape, not "-<" and "=<", which is after mirroring. |
Beta Was this translation helpful? Give feedback.
-
|
The conversion from "->" to "-<" happens as part of shaping. UAX#9 doesn't really know what it says about shaping, mind you. |
Beta Was this translation helpful? Give feedback.
-
|
Note that the shaping text in UAX#9 is limited to Arabic-style shaping, not ligatures or contextual forms. They should happen after Bidi_Mirroring is applied. |
Beta Was this translation helpful? Give feedback.
-
|
|
Beta Was this translation helpful? Give feedback.
-
|
It looks to me like the Google Fonts page has a couple of different versions of the font resource. When the page is first loaded, it loads a small subset version of Fira Code (a 7.4kB WOFF2 file) that just supports the initial preview text, but then when you click in one of the preview areas to live-edit the text, it replaces this with a more complete resource (this time it's 34.7kB). In particular, the initial subset doesn't include the |
Beta Was this translation helpful? Give feedback.
-
|
Oh wow. Nice catch. So in fact, this applies to all fonts on Google Fonts, as can be observed here: https://fonts.google.com/?preview.text=%D7%90%20-%3E%20%D7%91 I haven't the faintest idea how to report bugs like this to giants like Google. |
Beta Was this translation helpful? Give feedback.
-
|
The Google Fonts issue tracker is at https://github.com/google/fonts/issues |
Beta Was this translation helpful? Give feedback.
-
I never would have guessed. Issue opened: google/fonts#9335 If only all of Google's products were that easy to report bugs in! |
Beta Was this translation helpful? Give feedback.
-
|
@behdad Do you know if Google Fonts is using harfbuzz to power their font subsetter? It could be argued this is a subsetter bug, or at least should be an optional subsetter feature: because it cannot know what directionality will be applied when rendering, it should extend the requested character coverage to include codepoints reachable by Unicode bidi mirroring. |
Beta Was this translation helpful? Give feedback.
-
|
Yes, they use hb_subset. And it's kind of a known issue that subsetter should expand the input over composition/decomposition. Mirroring had not occurred to me. Specially if the font has RTL script tables. cc @garretrieger |
Beta Was this translation helpful? Give feedback.
-
|
I filed #5281 |
Beta Was this translation helpful? Give feedback.
-
|
Here's what OpenType has to say on the issue: |
Beta Was this translation helpful? Give feedback.
-
|
Not super relevant for this discussion, but, emphasis mine:
This is horrifying for the current discussion in the Unicode mailing list: https://corp.unicode.org/pipermail/unicode/2025-April/011375.html |
Beta Was this translation helpful? Give feedback.
-
|
Yes I was highly opposed to freezing OpenType to Bidi_Mirroring of Unicode 5.1. Fortunately, in HarfBuzz, we do against OpenType spec and mirror according to the latest version of Unicode standard, such that fonts don't have to add |
Beta Was this translation helpful? Give feedback.
-
|
It would be good for someone to submit a change request to the Unicode so that what UAX#9 says about shaping and mirroring would be consistent with what OpenType says and the shaping engines out there actually implement. The current evident contradiction is not a good thing. |
Beta Was this translation helpful? Give feedback.
-
|
And for the curious, this is the Fira Code https://github.com/tonsky/FiraCode/blob/master/features/calt/hyphen_arrows.fea |
Beta Was this translation helpful? Give feedback.
It's a shortcoming of the font. The font does NOT support right-to-left features like
rtlm, etc. There's nothing in HarfBuzz to fix over a font shortcoming like that.