Font ligatures across multiple HTML tags are shown incompletely
Categories
(Core :: Layout: Text and Fonts, defect)
Tracking
()
People
(Reporter: Bjoern, Unassigned)
Details
Attachments
(3 files)
101781696-6f632100-3af8-11eb-9681-62ed0c545bfc.png
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:83.0) Gecko/20100101 Firefox/83.0
Steps to reproduce:
Configured Fira Code as monospace font,
went to https://gebish.org/manual/3.4.1/#indexes-and-ranges,
looked at the Groovy example with the asserts.
That page currently uses prettify for highlighting which is a bad choice as it does not actually support Groovy.
Because of that the code is parsed as something else, probably Java and the result is
<span class="lit">0.</span><span class="pun">.</span><span class="lit">1</span> instead of
<span class="lit">0</span><span class="pun">..</span><span class="lit">1</span>.
Actual results:
The .. ligature was applied to the two individual dots, the left dot was moved to the right and only the left-most pixel of the left dot remains and thus is almost invisible as can be seen in the attachment.
Expected results:
The point is, that Firefox allows font ligatures to be applied which imho is against the intent of separating the characters in different tags (even if the intention is wrong here). If they are in different HTML tags they should imho be seen as separate characters and not joined together by a ligature.
And even if they are joined together by a ligature it is not helpful if the first character then is almost not visible anymore.
|
||
Comment 1•4 years ago
|
||
Could you please provide some steps on how to configure Fira Code as monospace font in order to reproduce this issue?
Thanks.
|
||
Comment 2•4 years ago
|
||
(In reply to Björn Kautler from comment #0)
Expected results:
The point is, that Firefox allows font ligatures to be applied which imho is against the intent of separating the characters in different tags (even if the intention is wrong here). If they are in different HTML tags they should imho be seen as separate characters and not joined together by a ligature.
This is a mistaken expectation. The CSS Text spec is quite explicit about this:
Text shaping must not be broken across inline box boundaries when there is no effective change in formatting [...]
So shaping effects such as ligatures, kerning, contextual forms, etc., are expected to apply across element boundaries, unless the author explicitly prevents them with appropriate formatting controls (or Unicode control characters such as zero-width non-joiner).
|
Reporter | |
Comment 3•9 months ago
|
||
|
|
Reporter | |
Comment 4•9 months ago
|
||
|
|
Reporter | |
Comment 5•9 months ago
|
||
I'm sorry for not responding earlier, I missed the comments here and just now logged in to report something else seeing the in-site notification.
It might be wrong expectation that the ligature should not be done.
I did not know that and that's ok then.
But I don't think it is wrong expectation that the ligature should be shown properly.
As you can see in the screenshot, one of the dots is barely visible.
I changed it in the upper line to not being in different spans, but the same.
So it should be like in the upper line, but is like in the lower line in attached comparison1.
Or changed to < and =, again in the upper line within the same span shown like expected
and in the lower line shown like it currently is in attached comparison 2.
|
|
Reporter | |
Updated•9 months ago
|
|
|
Reporter | |
Updated•9 months ago
|
|
|
||
Comment 6•9 months ago
|
||
The issue here is caused (or at least exacerbated) by the site's use of text-rendering: optimizeSpeed on the <pre> element. This causes Firefox to skip retriving the true bounds of each glyph for painting purposes; instead, it uses an approximation based on the overall font's ascent/descent and the advance width of the glyph. But in the case of Fira Code, the .. ligature ends up replacing the second of the original two . glyphs, with the outline of the first dot being offset to the left of the glyph origin, which falls outside the (approximate) bounds computed for the element, based just on the glyph position and advance.
Using text-rendering: optimizeLegibility instead would avoid this, as Firefox would then evaluate the true glyph bounds and paint the full area required. optimizeSpeed doesn't interact well with fonts that have substantial "overhang" like this where the glyph "ink" extents beyond the typographic glyph bounds (from origin to advance) as used for layout purposes.
|
|
Reporter | |
Comment 7•9 months ago
|
||
Ah, thanks.
For me it was indeed not optimizeSpeed but auto as I have a user script overwriting that for this and similar reasons.
But as the font size is 1 em which is 16 px and thus smaller than the configured 20 px it was treated like optimizeSpeed.
Now that I changed it to optimizeLegibility in my user script, it is displayed fine, thanks.
So again one change of actual Bug content.
Because there is still either an implementation or documentation bug I'd say.
https://developer.mozilla.org/en-US/docs/Web/CSS/text-rendering says that optimizeSpeed "disables kerning and ligatures".
But as we have seen, the ligatures are used, even if optimizeSpeed is used.
Chrome for example indeed does not use ligatures if optimizeSpeed is used, (or auto which is the same for Chrome according to mentioned page)
Description
•