Closed Bug 1320197 Opened 8 years ago Closed 2 years ago

SVG in OpenType is rendered slightly too small


(Core :: SVG, defect, P3)

50 Branch



97 Branch
Tracking Status
firefox97 --- verified


(Reporter: jan.boesenberg, Assigned: jfkthame)



(Keywords: fonts)


(3 files, 1 obsolete file)

Attached file testFont.ttf (obsolete) —
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

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.
Keywords: fonts
Component: Untriaged → SVG
Product: Firefox → Core
I have set up a better JSFiddle to illustrate this issue:

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.
Attached file 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.
Attachment #8814247 - Attachment is obsolete: true
Priority: -- → P3

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.

Assignee: nobody → jfkthame

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

Pushed by
Use the font's unitsPerEm value when setting up the SVG glyph view. r=emilio
Add reftest. r=emilio
Closed: 2 years ago
Resolution: --- → FIXED
Target Milestone: --- → 97 Branch

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 ( 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.

Regressions: 1746795
Flags: qe-verify+

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.

Flags: qe-verify+
You need to log in before you can comment on or make changes to this bug.