M49 Regression: Emoji layout width too small (or character too large) on non-2x
Reported by
siul...@gmail.com,
Mar 19 2016
|
||||||||||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/49.0.2623.87 Safari/537.36 Example URL: https://www.google.com/#q=%2B%F0%9F%98%80%2B Steps to reproduce the problem: 0. Use a Mac, and set your display to non-2x resolution. 1. Load https://www.google.com/#q=%2B%F0%9F%98%80%2B What is the expected behavior? Same spacing between
,
Mar 19 2016
Ah! My comment is truncated too. Expected: Same spacing between [emoji] and the two “+” signs. Actual: [emoji] overlaps with the “+” after it. Comment: From M48 to M49, https://bugs.chromium.org/p/chromium/issues/detail?id=551420 is fixed for 2x display and this bug is introduced for non-2x display.
,
Mar 19 2016
,
Mar 23 2016
,
Mar 24 2016
Ben, I believe this is a Skia issue, could you comment?
,
Mar 25 2016
With Chrome 49.0.2623.87 (stable) on a non-retina I actually see nothing drawn for the emoji in the web page (I see the correct one in the edit box). In 51.0.2687.0 canary and current tip of tree Chromium I see the correct emoji drawn and it doesn't overlap anything and seems the right size. (This is all on a MacPro.) What version of osx is this? Which hardware? Is this a retina display running at 1x? Can you try with Canary on this setup and see if there is a difference?
,
Dec 14 2016
Due to staring at several other issues, I think I know why this happens. The issue is measuring with one typeface but drawing with another. The most likely way for this to happen is when a typeface is found, the code stashes the typeface name somewhere (instead of the typeface itself) and then does a lookup based on the name later (trying to get the same typeface back). On a Mac, this will almost always result in the different emoji seen here because looking up a typeface by a name some typeface produced is quite unlikely to produce the same typeface (and in some cases is undefined). This also (as one would expect) works poorly with caching. I expect this is seen much less in recent versions of Chromium because there is now much less of this behavior (trying to 'serialize' and 'deserialize' a typeface based on name alone). I'm not currently seeing this on my non-retina macOS 10.12.1 with Chrome 57.0.2949.0. Is anyone still running into this issue? If so, please provide any details you may have.
,
Dec 15 2016
I think it might (also) have something to do with metrics scaling in CoreText shaping: From one ebraminio's contribution to HarfBuzz it seems that scaling up from font size 16 does not work so well for emoji, compare: https://github.com/behdad/harfbuzz/pull/367 - when that is changed to always using a CTFont at the right size, emoji spacing looks better.
,
Dec 15 2016
Interesting HarfBuzz issue. Note that Skia needs to go out of its way to only use CGFont (or a CTFont created directly from a CGFont), because drawing a CTFont at various sizes (including changing size through a transform) can cause an entirely different underling font to be used. See comments in and around Skia's SkFontHost_mac.cpp#ctfont_create_exact_copy for some details on this behavior.
,
Dec 15 2016
I also have submitted that as a test patch to Chromium https://codereview.chromium.org/2544283003/ would be nice to check that out.
,
Dec 19 2016
Siulung@, what do you mean by non 2x resolution? I've tried to reproduce your steps with all scaling settings on a Retina MacBook Pro but cannot reproduce the + overlap on top of the emoji. (compare emoji_search_stable.png). Ebrahim, I ran this with your CL applied, the emoji spacing in this case looks two wide to me, second screenshot.
,
Dec 19 2016
I think what Siulung@ is referring to is non 2x DPI (LoDPI) macOS as I have the same issue as the reporter on my non-retina MacBook. An interesting thing I faced while my little tests, hb-coretext custom constructors (hb_coretext_face_create, and my not merged hb_coretext_face_create_from_ct_font) fonts are acting differently than default harfbuzz constructed fonts on glyph metric things, perhaps this is related to the issue we have here or maybe not.
,
Dec 19 2016
Thanks - I'll try experimenting with setting a forced device scale factor for reproducing this.
,
Jan 28 2017
I am having a similar issue, which I was going to file separately, until I found this issue. For my part, I am running Chrome 56 on Mac OS X 10.12.2, on a non-Retina Mac. I prepared a fiddle that demonstrates my issue; it seems to be most visible when the font is 16px or smaller. https://jsfiddle.net/p2pjLd9m/ Expected Results: - The <span> that contains each emoji is rendered wide enough to contain the whole character. Actual Results: - At smaller font sizes, the emoji is rendered larger than the enclosing <span>.
,
Jun 20 2017
I took a quick look into this. At least a little bit of this is fixed on the browser side. It used to be that the browser would often measure with one font and draw with a completely different font and could end up with strange layout like this. As far as the Blink layout side goes, I cannot reproduce this issue when using version 10 of the AppleColorEmoji font, but I can reproduce when using version 12 of the AppleColorEmoji font. It may be the case that Apple relatively increased the size of the smaller emoji bitmaps (to enhance legibility) but this means the bitmaps no longer linearly scale. This may be breaking some assumption around linear scaling of text (which of course text doesn't do).
,
Jun 20 2017
Super simple local reproduction <span style="font-family:Helvetica;font-size:14px;background-color:green;">feels 💙</span> data:text/html;charset=utf-8;base64,PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkhlbHZldGljYTtmb250LXNpemU6MTRweDtiYWNrZ3JvdW5kLWNvbG9yOmdyZWVuOyI+ZmVlbHMg8J+SmTwvc3Bhbj4=
,
Jan 3 2018
This is more noticable for me on my non-retina external screen, but these emoji's still overlap on the main (retina) screen. Compare this to the flawless rendering from iMessage.
,
Feb 14 2018
,
Feb 19 2018
I *think* latest AppleColorEmoji has a trak table. I might be wrong.
,
Feb 19 2018
Yes, it has.
,
Feb 19 2018
Ok then, we need to figure out how to instantiate it such that CoreText does traking. See: https://github.com/harfbuzz/harfbuzz/blob/0bbf90ded00dd00ee3f79c1bd16c775d7c893278/src/hb-coretext.cc#L164 I couldn't see any constant immediately for emoji font. I'll ask Ned.
,
Feb 19 2018
Looks like we have to shape an emoji char with system font and fallback enabled, and use the resulting CTFont as a Apple Color Emoji CTFont that applies traking.
,
Feb 24 2018
Now harfbuzz has [an initial state] `trak` implementation which I did in hope this to be fixed sooner :)
,
Nov 28
Can anyone that still can reproduce this can test the most recent Chrome canary to see if this fixed?
,
Nov 28
Using Chrome 72.0.3624.0 I took the below screenshots. As you can see the non-retina version is now working pretty well (using iMessage as a baseline), but when I drag the window to my retina monitor, the emojis are now too widely spaced. In all of these screenshots there is no space between the emojis, and one space after the second emoji before the text. ``` 🎉🎉 for example ```
|
||||||||||||||||||||
►
Sign in to add a comment |
||||||||||||||||||||
Comment 1 by siul...@gmail.com
, Mar 19 2016