1320197 - SVG in OpenType is rendered slightly too small

Status: VERIFIED FIXED

(Core :: SVG, defect, P3)

Description

[Jan Bösenberg]

Attachment: testFont.ttf

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

Steps to reproduce:

I created a very small True Type font with a simple square as the only glyph at char code 0xe000. It is included both as a standard glyph and as an SVG in the 'SVG ' table, as defined in the SVG Glyphs in OpenType Specification

The SVG glyph is rendered about 2% smaller on Firefox than the TrueType glyph, although it should have the same size. The size of the TrueType glyph is the correct one.

There is a JSFiddle at https://jsfiddle.net/kbhn4q01/

The size of the black square is the same on Chrome and IE11 (both render the standard glyph) and on Edge 14 (which renders the embedded SVG). On Firefox the square looks like it was scaled to 98% with the bottom left corner as the origin.


Actual results:

The SVG renders about 2% smaller than the standard glyph.


Expected results:

The SVG should have the same size as the standard glyph.

Comment 1

[Jan Bösenberg]

I have set up a better JSFiddle to illustrate this issue:

https://jsfiddle.net/kbhn4q01/3/

The font now contains two glyphs at char codes 0xe000 and 0xe001. Both glyphs are identical squares with the baseline through the vertical center. Only for the first glyph an SVG is included, so the second glyph will render as a standard glyph on every browser.

In the fiddle (on Firefox and Edge 14) the purple square is the SVG. The correct layout of the square would be to fill the intersection of the green and grey area, but as you can see on Firefox the SVG is shifted to the left and slightly too small.

Comment 2

[Jan Bösenberg]

Attachment: testFont2.ttf

This is the font used by the improved JSFiddle. It contains two glyphs at 0xe000 and 0xe001. Both glyphs are squares with the baseline through the vertical center. Only for 0xe000 an SVG glyph is included.

Comment 3

[Jonathan Kew [:jfkthame]]

Attachment: Bug 1320197 - Use the font's unitsPerEm value when setting up the SVG glyph view. r=#layout-reviewers

This fixes the mis-sized rendering of SVG glyphs when unitsPerEm is not 1000, as in the example here;
thia also affects some real-world Adobe fonts, e.g. https://fonts.adobe.com/fonts/tipoteca-series#fonts-section

Comment 4

[Jonathan Kew [:jfkthame]]

Attachment: Bug 1320197 - Add reftest. r=#layout-reviewers

The testcase has some "fuzz" on macOS and Windows because the black non-SVG glyph gets antialiasing,
which shows slightly around the edges of the (non-antialiased) SVG glyph that is painted on top.
A "real" failure, however, would show strips of solid black, so it would have greater differences
and affect more pixels.

Depends on D133641

Comment 5

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/11dabfd15323
Use the font's unitsPerEm value when setting up the SVG glyph view. r=emilio
https://hg.mozilla.org/integration/autoland/rev/cbfbd2bac317
Add reftest. r=emilio

Comment 6

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

https://hg.mozilla.org/mozilla-central/rev/11dabfd15323
https://hg.mozilla.org/mozilla-central/rev/cbfbd2bac317

Comment 7

[Sairus Patel]

Great to see this fixed, thank you!

Just to note, in addition to the several color fonts in the Tipoteca Series that Jonathan mentioned (Filicudi Color Pride, Filicudi Color TV, etc), Noto Emoji SVG (https://github.com/adobe-fonts/noto-emoji-svg) also a non-100 UPM (2048).

So Firefox, before this fix, was rendering Noto Emoji SVG too small, and Filicudi Color (UPM of 833) too large.

Comment 8

[Ciprian Georgiu, Desktop QA]

I've reproduced this bug using the STR from comment 0, on an affected build, Nightly 2021-12-14.

The bug is verified as fixed on latest Beta 97.0b4, under macOS 11, Ubuntu 18.04 x64, Win 10 x64.