I just realized that the style tag in the original attachment is wrong. Corrected example is attached (and it still exhibits the same buggy rendering).

Deleted: monospace.html 229 bytes

monospace.html 229 bytes View Download

Thanks for the report. Did you happen to test in other browsers, what do you see there? 

It's difficult to get this right since we would somehow have to apply geometric transforms to the fallback glyphs from a separate font to squeeze/stretch them to the matching size. 

As a workaround, it may help to hand-pick monospace fonts on each system which have a wider coverage than the default monospace font and add them to the font-family list. For example, Menlo on Mac OS which has wide special character coverage. Or alternatively provide a web font which has all needed characters in a monospace glyph set, e.g. Droid Sans Mono, Ubuntu Mono.

> Did you happen to test in other browsers, what do you see there? 

I hadn't tested it in other browsers, since I only use the Secure Shell extension in Chrome.

I needed to update the test-case to reproduce it in Edge, because its default monospace font seems to have better coverage. However, using a web font to force a fallback exhibits the same bug as in Chrome (see attached screenshot).

Deleted: monospace.html 306 bytes

monospace.html 306 bytes View Download

Deleted: Windows (Edge and Chrome).png 69.3 KB

	Windows (Edge and Chrome).png 69.3 KB View Download

As far as actual terminals go, see the attached screenshot for some common terminals on Linux.
• urxvt favors alignment and coverage over rendering: it clips characters that are too wide.
• xterm favors alignment and rendering over coverage: it does not use fallback glyphs at all.

Deleted: Screenshot 2018-02-07 at 11.24.10.png 326 KB

	Screenshot 2018-02-07 at 11.24.10.png 326 KB View Download

Firefox on Linux appears to get it right.

Deleted: Screenshot 2018-02-07 at 11.31.12.png 85.2 KB

	Screenshot 2018-02-07 at 11.31.12.png 85.2 KB View Download

> It's difficult to get this right since we would somehow have to apply geometric transforms to the fallback glyphs from a separate font to squeeze/stretch them to the matching size. 

Agreed, it's not an easy problem.

I suspect that scaling the glyphs down uniformly until they fit in the box would be a good enough workaround for me in most cases, although I understand that even that isn't as easy as it sounds (considering antialiasing and low-DPI rendering).

> As a workaround, it may help to hand-pick monospace fonts on each system which have a wider coverage than the default monospace font and add them to the font-family list.

Yeah, that at least helps for the more common glyphs. It's still not a great solution for the more exotic ones: you never know what kind of crazy characters you'll encounter when you're, say, reading the source file for a unit-test of an text-internationalization package, or writing a complex mathematical expression in a code comment.

Unfortunately, the fonts with good Unicode coverage tend to be ugly and hard-to-read, and the fonts that are easy on the eyes tend to have poor Unicode coverage.

there are various workarounds we know of we can apply (and we have some open bugs for hterm on the topic), so the focus on this bug was purely on making it "just work" in blink itself

Thank you for the additional details and surveying what other implementations do. Trying to align, then clip fallback glyphs into the glyph box of the primary font is perhaps something we can do without too much trouble (compared to for example geometrically transforming / box fitting fallback glyphs, either uniformly, or only in x-direction.)

> Trying to align, then clip fallback glyphs into the glyph box of the primary font is perhaps something we can do without too much trouble

Note that clipping is sometimes a really poor solution. (For example, if you clip the edges off of arrows, they might not look like arrows at all when you're done.)

Here's another test-case for that: I'm curious as to how Firefox handles too-wide glyphs for comparison.

Deleted: monospace.html 290 bytes

monospace.html 290 bytes View Download

Looks like Firefox handles under-width characters correctly, but not over-width.

Deleted: Screenshot 2018-02-08 at 12.34.36.png 64.2 KB

	Screenshot 2018-02-08 at 12.34.36.png 64.2 KB View Download

Hmm, another interesting tidbit in Unicode 9.0.0
(http://www.unicode.org/reports/tr11/tr11-31.html#Recommendations):

“Emoji style standardized variation sequences behave as though they were East Asian Wide, regardless of their assigned East_Asian_Width property value.”

Firefox is choosing the text-style variations in this case, so it doesn't apply, but Chrome seem to choose the emoji-style sailboat glyph (⛵).

Perhaps it's worth filing a separate issue to determine whether Chrome should prefer text-style glyphs in <pre> tags.

i'd expect both of these aspects (clipping mode and emoji-vs-text) to be css prefs that the page can select between.  e.g. something like css's text-overflow and font-feature-settings.

looks like UTF-8 supports U+FE0E for emoji selection.  bug reports here ( issue 625210  and  issue 491556 ) suggest it should work ...

Yes, variation selectors VS15 and VS16 work in Chrome for emoji presentation control (as long as there is font coverage). There are discussions to add emoji-presentation control to CSS, compare https://github.com/w3c/csswg-drafts/issues/1144