Closed Bug 805702 Opened 7 years ago Closed 7 years ago
scaling of emoji glyphs is incorrect
Support for color emoji glyphs recently landed on trunk. However, the scaling of the glyphs appears to be incorrect, Safari shows the glyphs at roughly 2/3 the size of the glyphs shown in Gecko. Gecko should match Safari since this is basically an Apple custom format. The difference between Nightly and Safari is the same on both retina and non-retina displays.
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 804934
This is definitely related but I don't see why this is necessarily a duplicate unless you've explicitly investigated that angle. If you have, can you add more explaination here? Otherwise, I think we should leave this open until we confirm that the two issues are actually the same bug rather than different problems in a related area.
The emoji glyphs all claim to have a width of 800 units: <mtx name="u1F201" width="800" lsb="0"/> and have "fake" (blank) TrueType outlines implying a bounding box of 800 units square: <TTGlyph name="u1F201" xMin="1" yMin="-40" xMax="801" yMax="760"> <contour> <pt x="0" y="0" on="1"/> </contour> <contour> <pt x="800" y="800" on="1"/> </contour> <instructions><assembly> </assembly></instructions> </TTGlyph> But when we draw, the color bitmap glyphs appear to render slightly larger than their reported glyph bounds/advance width. I don't know why, but that is the discrepancy you're describing here, and explains the cursor misplacement/glyph overlap/rendering turds described in bug 804934. So yes, I think this is the same issue. We need to figure out how to persuade Core Text to draw the bitmaps at the proper size to match the TrueType metrics.
You need to log in before you can comment on or make changes to this bug.