Icons are oversized in Windows 10 14393/Edge

[be5invis]

Tested with 100% and 200% DPI.

[be5invis]

The one provided here is sized correctly. Perhaps related to the lack support of view box in SVG.

[13rac1]

Hmm.... Interesting. Awesome seeing SVGinOT working in Edge!

This isn't a bug in this font, per se, since I am using the SVGs as-is from the EmojiOne project. Could this count as a bug in Edge or in EmojiOne? A workaround could be implemented in SCFBuild (the font build system used to create this font). Is there any difference with Twitter Color Emoji? The SVGs in it are built differently.

[13rac1]

@RoelN are you aware of this? Relevant to add to LapisLegit?

[be5invis]

@eosrei Spec of SVG in OT (link):

Glyph Semantics and Metrics

The glyph descriptions in the SVG documents are considered to be the SVG versions of the glyphs with the corresponding IDs in the CFF or glyf table. They are designed on an em specified in the head table’s unitsPerEm field, as with CFF and TrueType glyphs. SVG glyph definitions will be in SVG’s y-down coordinate system, with the default baseline at y=0. For example, the top of a capital letter may be at y=-800, and the bottom at y=0. This coordinate system will need to be translated appropriately to the coordinate system of the rest of the OT tables and the coordinate system of the graphics environment.
Glyph semantics are expressed in the usual way (cmap table followed by GSUB). Glyph metrics such as horizontal and vertical advances are specified in the OpenType metrics tables (hmtx and vmtx), and glyph positioning adjustments by the GPOS or kern table.
As with CFF glyphs, no explicit glyph bounding boxes are recorded. The “ink” bounding box of the rendered SVG glyph should be used if a bounding box is desired; this box may be different for animated vs static renderings of the glyph.
Note that the glyph advances are static and not able to be made variable or animated.

[be5invis]

@eosrei @RoelN According to the spec, you have to use em-units as coordinates, and inverse the Y coordinates. So... It IS a bug of EmojiOne, and Windows is strictly following this spec, while FireFox supports some extensions I think.

[13rac1]

Yes, I've read the spec many times. A copy/paste of multiple paragraphs isn't helpful to get your point across. Do you want me to transform all of the source material?

Edit: A transform is already applied to fix the alignment. The screenshots show that working correctly.

[be5invis]

@eosrei The spec speicifes that:

• All points should use emunits as coordinate units. viewboxes are not supported, at least in Edge.
• The coordinate system's origin is the same as TTF, with y-axis inversed (y-down) to follow SVG's habit.

So... yes, you need to transform the SVG either, to make the SVG outline fits the glyf outline.

[13rac1]

All points should use emunits as coordinate units. viewboxes are not supported, at least in Edge.

Will Edge support view boxes? AFAIK to fix this in the font I need to build full SVG parsing (reparsing?) into SCFBuild. Hmm... there is a 2.048x scaling on the source. SVGs always display too small without it in Firefox.

The coordinate system's origin is the same as TTF, with y-axis inversed (y-down) to follow SVG's habit.

Already done.

[be5invis]

@eosrei I am not sure whether Windows (yes, it is a Windows D2D's built-in feature, so non-browsers can support it either) will support viewboxes in the far future, but in the incoming RS1, it won't. And perhaps Windows other engines (like freetype?) will never support viewboxes, considering it somehow conflicts with the Spec's requirements.
So the SVG's point should be scaled to fit the same coordinates with glyf ones (but with y-axis inversed, of course).

[13rac1]

How can I reproduce this for testing? Will it work (aka break) on the newest Win10 VMs from Microsoft? https://developer.microsoft.com/en-us/microsoft-edge/tools/vms/ I have an older WIn10 VM now, but could download a new one.

FWIW and for my own future reference:

• Current SVG transform generation: https://github.com/eosrei/scfbuild/blob/2224cd2b35b09f6458dcdc7897192a867c8b586c/scfbuild/builder.py#L173-L199
• Current SVG transform usage: https://github.com/eosrei/scfbuild/blob/2224cd2b35b09f6458dcdc7897192a867c8b586c/scfbuild/builder.py#L97-L119

[be5invis]

@eosrei You have to use the latest Windows 10 14393 build, install the font, and open a web page using your font with Edge.

[13rac1]

I can run the preview VM. Haha! I am downloading it now.

[13rac1]

Awesome seeing SVGinOT work on Win10!

I've confirmed this bug in Edge and Sticky Notes on Win10 Preview 14.14393. How unbelievably frustrating.

Reinebow renders incorrectly, but completely differently than EmojiOne Color. EmojiOne Color is huge, but Reinebow is small?!?! https://xerographer.github.io/reinebow/

These two fonts shouldn't be this drastically different. I'll try some tests later this week, but I cannot spend lots of time debugging until there is confirmation this is how MS intends for it to render. I wish there were a publicly accessible issue queue on Microsoft projects so I could track the status/details. Edge cannot load the regular SVG files in the Github preview, so there is still work to do. Edge/Win10 vs FF/Ubuntu16.04:

Additional note: I'm surprised they haven't fixed font hinting in Windows. The regular glyphs look terrible in Character Map. I may have to run autohint to generate hinting data.

[be5invis]

ttfautohint is ok