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

[RoelN]

@eosrei I haven't looked into the calculations scfbuild does on the axis and scale, but I would dig in that area for the scaling bug. Maybe the <g> trick would work as mentioned in https://github.com/eosrei/scfbuild/issues/4?

I still have to download this VM. How does http://bixacolor.com/ or https://pixelambacht.nl/2014/compyx-a-multicolor-8bit-font/ fare in W10? Or indeed https://pixelambacht.nl/lapislegit/?

[be5invis]

@RoelN Bixa Color: OK Compyx: OK LapisLegis: See the image

[RoelN]

@be5invis Ah, thanks! Some things to note:

1. Bixa Color looks good
2. But Compyx too, which is a surprise to me because it uses transform on the SVG element, which shouldn't work
3. LapisLegit has the "supersize bug". This is built with scfbuild so I'm thinking the coordinates recalculations going on there are wonky.

[13rac1]

@RoelN FWIW I couldn't test any of your fonts last night (PST), your server wasn't responding. ¯_(ツ)_/¯

This is built with scfbuild so I'm thinking the coordinates recalculations going on there are wonky.

Doesn't surprise me. :-/ I'll look at applying the scaling transform to remove the viewbox and background.

https://pixelambacht.nl/lapislegit/?

It's interesting how much of the SVG spec isn't implemented by Microsoft. No animations, no rotations.

[13rac1]

I've pulled a short example SVG from Bixa Color to compare. MSFT is using a strict interpretation of the unitsPerEm value.

    <unitsPerEm value="1000"/>

The less than symbol clearly is using numbers in the 0-1000 range:

<?xml version="1.0" encoding="UTF-8"?>
    <svg xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" version="1.1" enable-background="new 98 -55 642 822" id="glyph29">
    <path fill="#ED0088"  d="M239 242 L345 348 L642 51 L536 -55 L239 242 Z " />
    <path fill="#00AFE9"  d="M642 716 L204 278 L98 384 L536 822 L642 716 Z " />
    <path fill="#30328C"  d="M536 752 L572 716 L292 437 C278 423 271 403 271 384 C271 364 278 345 292 331 L572 51 L536 16 L168 384 L536 752 Z " />
    </svg>

SCFBuild is hard coded to use the now recommended value of 2048. The EmojiOne graphics are drawn with a viewBox="0 0 64 64", so we need to scale by 32x and strip the viewbox attribute. I manually added a <g transform="scale(32)"> to the EmojiOne 1f93e.svg file. svgo was able to apply the transform. Before:

<g transform="scale(32)">
<path fill="#ffdd67" d="m33.5 18l-3.1-1.8v10.8h6.9z"/><path d="m38.2 22.9c-2 1.3-.9 4.1-.9 4.1-2.8 0-4.8-5.6-4.8-9l5.7 4.9" fill="#eba352"/> [snip]
</g>

After:

<path fill="#ffdd67" d="M1072 576l-99.2-57.6V864h220.8z"/>
<path d="M1222.4 732.8c-64 41.6-28.8 131.2-28.8 131.2-89.6 0-153.6-179.2-153.6-288l182.4 156.8" fill="#eba352"/> [snip]

I am going to rebuild v1.3 with this character changed and see if it renders correctly.

[13rac1]

Ah right, FontForge and Inkscape 0.91 cannot parse the output of svgo. This is SCFBuild in verbose mode with a FontForge error:

DEBUG:scfbuild.fforge:Creating glyph at 0x1f93e for build/svg-bw/1f93e.svg
I'm sorry this file is too complex for me to understand (or is erroneous)

[13rac1]

Currently trying to make 1f93e.svg work correctly in Firefox using scale(1,-1) while waiting on a massive ETL elsewhere. Minor breakthrough after disassembling Bix Color. The <head> is different:

    <indexToLocFormat value="0"/>

It's 1 on EmojiOne Color and 0 on Bixa Color. Changing the EmojiOneColor ttx to 0 and rebuilding results in a correctly sized SVG, but it's still upside down:

More to come...

Just realized: Edge isn't wrapping the lines correctly. There's no horizontal scroll bar on the EmojiOne Color HTML demo page.

@RoelN FWIW You can run svgo on Bixa Color's SVGs to save some bytes.

@yincrash This issue may be of interest if you haven't seen it.

[be5invis]

indexToLocFormat is not used for SVG table, it is used to indicate the format of loca table which records the offsets of glyph outline date in glyf, which is the fallback B&W data.

[13rac1]

Haha! I just checked the docs on indexToLocFormat. It cannot possibly be related.

[be5invis]

The upside-down may be caused by not flipping y coordinates. SVG uses a y-down coordinate system while TTF/CFF use y-up. Line wrapping may be related with glyph semantics, given that emojis are symbols, and there are many ZWJs in it.

[13rac1]

Update: The sizing fix is due to the removal of the viewBox attribute on that SVG. It has to be there to find B&W proportional font width, but cannot be there for the SVG table.

The upside-down may be caused by not flipping y coordinates. SVG uses a y-down coordinate system while TTF/CFF use y-up.

The thing is, if I copy/paste a Bixa Color character out of the ttx then remove the scale(1,-1) it works fine in FireFox. No.

Line wrapping may be related with glyph semantics, given that emojis are symbols, and there are many ZWJs in it.

Yeah. Chrome has major issues with line-wrapping ZJW in <textarea> fields also.

[13rac1]

Ok, I see what to do to automate this nonsense.

Original SVG copy/paste from Bixa:

<?xml version="1.0" encoding="UTF-8"?>
    <svg xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" version="1.1" enable-background="new 75 25 375 788" id="glyph18">
      <g transform="scale(1,-1)">
    <path fill="#ED0088"  d="M191 761 C160 709 142 647 132 580 C124 581 115 581 104 579 C101 578 89 576 75 573 L75 722 C103 737 165 753 191 761 L191 761 Z " />
    <path fill="#00AFE9"  d="M375 25 L75 25 L75 175 L100 175 C141 175 175 209 175 250 L175 463 C175 604 204 721 275 787 L277 788 L275 250 C275 209 309 175 350 175 L375 175 L375 25 Z " />
    <path fill="#30328C"  d="M225 250 C225 189 268 139 325 128 L325 75 L125 75 L125 128 C182 139 225 189 225 250 L225 250 L225 250 Z M125 631 L125 687 C153 696 190 708 226 719 L225 505 C225 565 201 631 125 631 L125 631 Z " />
    </g></svg>

The box is the default Inkscape board since there's no viewBox attribute.

With the scale removed:

With a coordinate system inversion <g transform="scale(1,-1) translate(0,-1000)"> which gets us back to "Normal":

Bixa Color SVGs are upside down, but not translated. That's why (1,-1) works for it, but not for me. Now I can do the same to 1f93e.svg and apply the whole thing with svgo #20. Solution for this font, which will be automated in SCFBuild:

Original upstream EmojiOne

<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 64 64" enable-background="new 0 0 64 64">

Current EmojioneColor

<svg xmlns="http://www.w3.org/2000/svg" id="glyph1077" viewBox="0 0 64 64"><g transform="translate(0 -9.6) translate(-0.0 -104.8576) scale(2.048)">

New EmojiOneColor, pre svgo, excluding the vertical alignment adjustment:

<svg xmlns="http://www.w3.org/2000/svg"><g transform="translate(0,-2048) scale(32)">

Thanks @be5invis and @RoelN ! I'll get this implemented in SCFBuild some time this week.

[13rac1]

Interesting. The transform/scale need to make it work in Firefox:

Is what causes the scaling problems in Edge:

Whatever. This solution works for both.

[be5invis]

@eosrei According to OT Spec, the “viewbox” is fixed by design, with the width identical to the value recorded in hmtx, and height identical to vmtx records (if present). FireFox may support some extension that resizes the outlines to fit the viewbox.

They are designed on an em specified in the head table’s unitsPerEm field, as with CFF and TrueType glyphs. ... 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.

[be5invis]

I think that maybe Firefox is incorrectly handling view boxes: they scale view boxes to 1000_1000, instead of upm_upm. Therefore you have to manually introduce a 2.048x scale to make the size right, while Edge doesn't need that.

[13rac1]

The OT spec says that, but I've just proved it false in Edge and we already knew it false in Firefox ;) Either way, if I follow the spec, then it'll work in both. No problem!

🤼is displayed in the above Edge screen shot using:

<svg xmlns="http://www.w3.org/2000/svg" id="glyph1075" viewBox="0 0 64 64"><g transform="scale(1,-1)">

Proof Edge handles the 64x64 viewBox attribute. Edit: At least as far as scaling.

[13rac1]

they scale view boxes to 10001000, instead of upm \ upm.

Yes. It works correctly, if I remove the viewBox attribute though.

[be5invis]

@eosrei : I have a speculation: Firefox cannot handle viewboxes correctly. They scale the glyphs’ outlines to 1000×1000, instead of upm×upm (the latter one is used by Edge). Removing the 2.048× scaling causes glyphs in FireFox undersized, and given that your font’s UnitsPerEm is 2048, I think that it is the real reason. Perhaps related: https://bugzilla.mozilla.org/show_bug.cgi?id=719286 But anyway, you’ve found a proper fix...

[13rac1]

Yes absolutely! The scaling to 1000x1000 was infuriating. I knew the existing solution was a workaround, but since there was no other implementation of the spec there was nothing else to test against. @RoelN 's fonts were different, but both worked in Firefox. So I didn't want to spend anymore time on it. I'm excited to update this and the other four fonts to work correctly in Edge.

[RoelN]

Nice work, thanks for the updates! Glad a solution has been found.

[yincrash]

Not sure how I missed the notification for this. It'd be really useful if implementations said what svg features they did and didn't implement. It's cool that there is more than one implementation now though!

[RoelN]

This thread talks about how Firefox indeed assumes 1000x1000 if you don't set the width/height yourself: https://lists.w3.org/Archives/Public/public-svgopentype/2016Aug/0000.html

[13rac1]

I know I know! It's out! I'll work on this at PyBay this weekend! Haha!

[13rac1]

Progress! I'm using Reinebow as my first test case since it is proportional, builds much faster, and works in-browser without an install. Full test with EmojiOne and TWEmoji tomorrow. Main problem was adjusting for font ascent/descent.

Edit: Yes, I know p and q don't have normal descents in Reinebow.

[13rac1]

Freizer(http://xerographer.github.io/freizer/) and Multicoloure(http://xerographer.github.io/multicoloure/) are now fixed with Edge. EmojiOne Color V1.4 is looking good too, except somehow word-wrap isn't working... 🤷 Not sure if this is an Edge, HTML, CSS, or font bug ATM.

[13rac1]

Fixed in SCFBuild. Will be in V1.4. Thanks for the help!