Issue metadata
Sign in to add a comment
|
Height of special character rendered is dependent on the size of the smallest character in the same div
Reported by
san0...@gmail.com,
Nov 6 2016
|
||||||||||||||||||||||
Issue description
<b>Chrome Version : <Copy from: 'about:version'></b>
URLs (if applicable) :
Other browsers tested:
Add OK or FAIL, along with the version, after other browsers where you
have tested this issue:
Safari:
Firefox:
IE:
What steps will reproduce the problem?
(1)Render html: <span>△</span><span>◁△</span>
What is the expected result?
All characters be of same height
What happens instead?
The first character is of smaller height, while that same character in the other div is of proper height
Please provide any additional information below. Attach a screenshot if
possible.
,
Nov 6 2016
Test: IE: (Edge) OK
,
Nov 9 2016
Able to reproduce the issue on Windows 10 using chrome reported version #54.0.2840.71 and latest canary #56.0.2914.0 . Bisect Information: ===================== Good build: 52.0.2715.0 Revision(388964) Bad Build : 52.0.2716.0 Revision(389538) Change Log URL: https://chromium.googlesource.com/chromium/src/+log/e0187a49c43ecf1d0867776c14a20f1788d76ff1..ae60e0da2195ec94959b7d71f8fbc32c9aa3028b From the above change log suspecting below change Review URL: https://codereview.chromium.org/1907063002 kulshin@ - Could you please check whether this is caused with respect to your change, if not please help us in assigning it to the right owner. Thanks...!!
,
Nov 10 2016
,
Nov 16 2016
This is due to automatic font fallback and doesn't have anything to do with the size of the adjacent glyph. Nor the default font nor the font specified for the sites page shown in the screenshot have either the △ nor the ◁ glyph. Thus font fallback is used to find an appropriate font to render said glyphs. For the first span (with only the △ glyph) Cambria Math is selected as the glyph is considered to be in a math symbol block and the preferred font, Cambria Math, has the relevant glyph. For the second span (with both the ◁ and △ glyphs) again the same block is identified and Cambria Math to be the preferred font. Cambria Math, however, does *not* have the ◁ glyph thus we fall back on the next font which in this case is Segoe UI Symbol. To avoid rendering adjacent glyphs in the same element with different fonts we chose to render both with Segoe UI Symbol. So in this case we go out of our way to avoid inconsistencies in rendering just to cause the same. Fixing this requires changes to our text rendering engine to allow shaping across element boundaries. This is tracked in bug 6122 and is scheduled for 2017. In the mean time, the easiest way to avoid this is to either keep the characters in the same element or to explicitly specify a font. Thanks for the detailed report, I hope this response at least explains the current behavior and that the workarounds provided are sufficient for the time being. If you have further questions about this please feel free to reach out to the layout team (layout-dev@chromium.org) or me directly. |
|||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||
Comment 1 by san0...@gmail.com
, Nov 6 2016