1213783 - getExtentOfChar() returns same result for all chars in non-rendered ligature (Open Sans font)

Status: RESOLVED INVALID

(Core :: SVG, defect)

Description

[Vince]

User Agent: Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/45.0.2454.101 Safari/537.36

Steps to reproduce:

Load the following JS Bin, wait 5 seconds (font download), then check the console:
https://jsbin.com/retikeqigi/1/edit?html,css,js,console,output

The JS Bin contains an SVG <text> element, with "ff" text in Open Sans font. The "ff" is not rendered as a ligature, and the characters are individually selectable.

The console shows the result of getExtentOfChar() called on each character.


Actual results:

The console shows that getExtentOfChar() returns the same SVGRect for both characters. The SVGRect is the bounding box for the potential ligature, even though the ligature is not rendered (x at origin, width is double the expected value of ~10.8).

The font size is 32px; this is larger than 20px, the size above which browsers are not normally expected to render ligatures.

This issue has been reproduced in the latest versions of Firefox on Windows and Mac (both 41.0.1).


Expected results:

Two adjacent bounding boxes should be returned, of width ~10.8. Chrome, IE and Safari return the expected result.

Comment 1

[Cameron McCormack (:heycam)]

Hi Vince; sorry about the delay looking at this issue.  This does appear to be rendered using a ligature, although I note that the single ligature character doesn't completely join the two "f"s together so it might not be obvious.  I inspected the downloaded font and found that it does have a ligature defined for "ff".  You can tell that the ligature is being used by making the <text> element contain three "f"s and comparing the appearance of the first two to the last one.

> The font size is 32px; this is larger than 20px, the size above which browsers are not normally expected to render ligatures.

Where does this rule come from?  I don't believe Firefox applies a rule like this.

As the SVG spec requires that the entire ligature glyph's box should be returned, I think this is working correctly.  If you want to ensure that ligatures will not be used, you can set |font-variant-ligatures: none;| in your style sheet.

Comment 2

[Vince]

Hi Cameron,

Thank you for the clarification on this.

The rendering of the ligature is indeed very subtle. I've only been able to detect it by putting 3 "f"s in a row in the above example, and then noting the slight difference in the selection rectangle when you select first 2, and then all 3 "f"s. As the ligature is being rendered, the results of getExtentOfChar() are therefore according to spec, and to be expected. I can confirm that setting font-variant-ligatures to none allows getExtentOfChar() to return the individual character bounding boxes.

Regarding the comment about ligatures not being rendered above 20px, I wasn't expecting this to be a hard and fast rule, and reading the following spec more closely reveals browser differences: https://developer.mozilla.org/en-US/docs/Web/CSS/text-rendering.

This comment is related to optimizeLegibility:
> One very visible effect is optimizeLegibility, which enables ligatures (ff, fi, fl etc.) in text smaller than 20px for some fonts (for example, Microsoft's Calibri, Candara, Constantia and Corbel or the DejaVu font family).

whilst further down, Gecko appears to exhibit almost the opposite behaviour:
> [4] If the font size is 20 pixels or higher, Gecko browsers use optimizeLegibility; for smaller text they use optimizeSpeed. The 20 pixels threshold value of the auto keyword can be changed via the browser.display.auto_quality_min_font_size preference.