The waved vector region-flags .svg files inside third_party/region-flags/waved-svg currently display slightly different from the same region-flags as encoded in both the bitmap and vector color fonts.
In particular, the SVG versions do not have the oblique soft-light blending effect that gives the flags a pseudo-3D effect. It's suble but visible when comparing them side by side. E.g. see the Scotland flag:
This screenshot is the SVG file:
This one is the glyph from the COLRv1 font in Chrome (notice it gets darker in the lower-right corner, and lighter in the top-left):
The bitmap CBDT font has a similar soft-light effect as well (ignore the blur or different color tint):
The reason we do in a post-processing stage instead of directly on the waved SVGs produced by the rsheeter/warp tool is because, initially we thought that SVG feBlend element didn't support the soft-light blend mode (https://www.w3.org/TR/SVG11/filters.html#feBlendElement).
However, it turns out that at least on latest Chrome and Safari (but not on FireFox), feBlend now supports all of the CSS blend modes, including soft-light. See this https://codepen.io/yoksel/pen/rNQJBK (forgot exactly how and where I found that link)
In fact I was able to modify the Scotland flag to add the feBlend with soft-light, here's the modified file and the diff vs the original:
Looks like this in Chrome (basically the same in Safari), notice the darkening at the lower-right end compared to the top-left:
In FireFox (102) however, the unsupported filter is ignored and it looks flat, mono color:
These above are the standalone SVG rendered in the browsers. However, when the same file with feBlend is embedded in an OT-SVG font (with nanoemoji --color_font untouchedsvg), Safari completely discards the filters and displays the corresponding glyph similarly to the way FireFox does with the standalone SVG above. Possibly this has to do with the fact that filters, in general, are excluded from the svg-native spec and maybe Safari decided to stick to that for OT-SVG fonts.
I file this issue so that I don't lose the results of my experimentation and also as a reminder to revisit this later if/when SVG and/or OT-SVG support for CSS blend modes has improved across implementations.
The waved vector region-flags .svg files inside third_party/region-flags/waved-svg currently display slightly different from the same region-flags as encoded in both the bitmap and vector color fonts.
In particular, the SVG versions do not have the oblique soft-light blending effect that gives the flags a pseudo-3D effect. It's suble but visible when comparing them side by side. E.g. see the Scotland flag:
This screenshot is the SVG file:
This one is the glyph from the COLRv1 font in Chrome (notice it gets darker in the lower-right corner, and lighter in the top-left):
The bitmap CBDT font has a similar soft-light effect as well (ignore the blur or different color tint):
The region-flags SVGs are the sources for both the bitmap and COLRv1 fonts; for the bitmap, the non waved SVGs in third_party/region-flags/svg directory are first converted to PNG, compressed (see Makefile), and then passed through the waveflag.c command to be warped and modified with the soft-light blend effect, see: https://github.com/googlefonts/noto-emoji/blob/81a3995aa3b5c5b86996780576f5c437d8bc101b/waveflag.c#L352
Whereas for the COLRv1 font, we created waved versions of the vector region-flags using the rsheeter/warp tool, and checked those in under third_party/region-flags/waved-svg directory (see #3). The soft-light effect is only added in a post-process step to the COLRv1 font with the colrv1_add_soft_light_to_flags.py script (it's translated as a PaintComposite with soft-light blend mode), see: https://github.com/googlefonts/noto-emoji/blob/81a3995aa3b5c5b86996780576f5c437d8bc101b/colrv1_postproc.py#L323
The reason we do in a post-processing stage instead of directly on the waved SVGs produced by the rsheeter/warp tool is because, initially we thought that SVG
feBlendelement didn't support the soft-light blend mode (https://www.w3.org/TR/SVG11/filters.html#feBlendElement).However, it turns out that at least on latest Chrome and Safari (but not on FireFox), feBlend now supports all of the CSS blend modes, including soft-light. See this https://codepen.io/yoksel/pen/rNQJBK (forgot exactly how and where I found that link)
In fact I was able to modify the Scotland flag to add the feBlend with soft-light, here's the modified file and the diff vs the original:
emoji_u1f3f4_e0067_e0062_e0073_e0063_e0074_e007f.svg.zip
Looks like this in Chrome (basically the same in Safari), notice the darkening at the lower-right end compared to the top-left:
In FireFox (102) however, the unsupported filter is ignored and it looks flat, mono color:
These above are the standalone SVG rendered in the browsers. However, when the same file with feBlend is embedded in an OT-SVG font (with
nanoemoji --color_font untouchedsvg), Safari completely discards the filters and displays the corresponding glyph similarly to the way FireFox does with the standalone SVG above. Possibly this has to do with the fact that filters, in general, are excluded from the svg-native spec and maybe Safari decided to stick to that for OT-SVG fonts.I file this issue so that I don't lose the results of my experimentation and also as a reminder to revisit this later if/when SVG and/or OT-SVG support for CSS blend modes has improved across implementations.