feature request: option to shift vertically the "baseline" of SVGs

[anthrotype]

Currently we map the svg viewbox (x, y) point to (0, UPEM) in font space.
We scale the viewbox width/height so they fit the units-per-em, and flip the Y-axis (svg goes downwards, font go upwards) and translate the origin y += UPEM.

E.g. if viewbox is (0, 0, 10, 10) and font UPEM is 1000 we end up with a transform from svg to font space like this: (100, 0, 0, -100, 0, 1000). So, point (0, 0) in svg space maps to (0, 1000) in font space, point (0, 10) in svg maps to (0, 0) in font, point (10, 10) in svg maps to (1000, 0), etc.

This may be good for now, however positioning the origin so high up by an amount equal to the UPEM may not work for all designs.
Even for noto or twemoji I think we end up with emojis that look don't look centered next to other text.

Maybe nanoemoji could have a commandline option to customize the vertical placement of the SVG in the font space. Or some option that allows to set the imaginary "baseline" of the emojis (i.e. what would become after the transformation the (0,0) in font units).

I haven't fully thought of a UX for this but I think it could be useful to have.

[rsheeter]

I think this leads us to having a config file (akin to how we do icon fonts) rather than just commandline args

[rsheeter]

And maybe take a transform as a config

[anthrotype]

@drott also noticed when comparing noto-emoji CBDT/CBLC with the COLRv1 version on the same line, the latter appears to sit too high relative to the baseline.

I think this code in noto-emoji is relevant, it appears to be setting the CLDT glyph metrics such that the bitmap glyph is vertically centered in between the ascent and descent lines:
https:/googlefonts/noto-emoji/blob/master/third_party/color_emoji/emoji_builder.py#L109-L128

whereas in our mapping from SVG to font space, we simply make so that the entire viewBox lies in the positive x/y quadrant, i.e. sits on the font's baseline

[rsheeter]

Oh nice, that gives us a fairly clear pattern to copy and afaik the CBDT is considered acceptably aligned

[anthrotype]

it should still need to be user-configurable since not all fonts have the same ascent/descent values

[anthrotype]

right now we don't even bother setting ascender/descender in nanoemoji, which means we get the default values from ufo2ft (I believe ascender = 0.8 * UPEM and descender = 0.2 * UPEM)

[rsheeter]

Now that we have a config file perhaps we can add options to control this? - my naive thought is [still] to just have a setting for a transform to apply. Does that seem sufficient? - we can add ascent/descent as well if we can't compute them easily.

[yisibl]

It seems too high when mixed with other text.

Left(nanoemoji), right(Apple emoji)

[anthrotype]

I think we will need both a transform option and the ascender/descender ones. The latter are important for line height, besides the problem of vertically centering the emoji.

[rsheeter]

Current result of COLRv1 (in todays Chrome Canary!!!) vs bitmap (CBDT); looks like we need some scaling too?

[rsheeter]

Courtesy of @anthrotype , ref https:/googlefonts/noto-emoji/blob/master/third_party/color_emoji/emoji_builder.py#L109-L128

[yisibl]

It is best to customize ascender and other parameters through parameters or configuration when building the font.

[rsheeter]

Reopening to provide better default per f2f discussion. Instead of (0,0) to (upem, upem) scale into (0, descender) to (ascender-descender, ascender)

[drott]

Awesome!