Unicode point from a supplementary plane that is not supported by a default font makes following supported point not rendered
Reported by
vsemozhe...@gmail.com,
Nov 29 2016
|
||||
Issue description
UserAgent: Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/57.0.2934.0 Safari/537.36
Steps to reproduce the problem:
Open the attached test.html file in the browser.
Or just open about:blank and run this script from console:
///////////////////////////////////////
const inFontFirst = '\u{1f40e}\u{1f40d}\u{1f40c}\u{1f40b}\u{1f40a}';
const notInFontFirst = '\u{1f40a}\u{1f40b}\u{1f40c}\u{1f40d}\u{1f40e}';
console.log([...inFontFirst].join(','));
console.log(inFontFirst);
console.log([...notInFontFirst].join(','));
console.log(notInFontFirst);
document.writeln([...inFontFirst].join(','));
document.writeln(inFontFirst);
document.writeln([...notInFontFirst].join(','));
document.writeln(notInFontFirst);
document.close();
document.body.style.whiteSpace = 'pre';
///////////////////////////////////////
Loke at the page and at the console.
What is the expected behavior?
All the supported glyphs are rendered properly.
All the unsupported glyphs are rendered as placeholders.
What went wrong?
If the supported glyphs come first:
All the supported glyphs are rendered properly.
All the unsupported glyphs are rendered as placeholders.
If the unsupported glyphs come first:
All the unsupported glyphs are rendered as placeholders.
All the supported glyphs are rendered as placeholders.
Please, compare the attached result-chrome.png with attached result-firefox.png, look at the last lines.
Did this work before? N/A
Does this work in other browsers? Yes
Chrome version: 57.0.2934.0 Channel: canary
OS Version: Windows 7 x64
Flash Version: 24.0.0.170
,
Nov 29 2016
Tested the issue on windows 7 using chrome latest canary M57 #57.0.2935.3 and issue is reproduced. Issue is seen from M46 and From M30 to M45 , the given test file is opened blank. Hence it is a Non-Regression Issue , marking it as untriaged. Note : Issue is specific to Windows 7 and not seen in any other OS. Thanks!
,
Nov 29 2016
For versions without full ES6 support use test2.html file or this script: /////////////////////////////////////////////////// const inFontFirstSplited = '🐎,🐍,🐌,🐋,🐊'; const inFontFirstContinuous = '🐎🐍🐌🐋🐊'; const notInFontFirstSplited = '🐊,🐋,🐌,🐍,🐎'; const notInFontFirstContinuous = '🐊🐋🐌🐍🐎'; console.log(inFontFirstSplited); console.log(inFontFirstContinuous); console.log(notInFontFirstSplited); console.log(notInFontFirstContinuous); document.writeln(inFontFirstSplited); document.writeln(inFontFirstContinuous); document.writeln(notInFontFirstSplited); document.writeln(notInFontFirstContinuous); document.close(); document.body.style.whiteSpace = 'pre'; /////////////////////////////////////////////////// Here it is on IE11 in my system:
,
Dec 2 2016
,
Dec 2 2016
Thanks for the report. Yes, this is similar to issue 618178 in that our font fallback code usually takes the first character of an unshaped sub-run of text, and fails to find the Emoji font if the first supported character is not supported, then does not make any progress with shaping and gives up. As a temporary workaround, on Windows, you may try to specify "Segoe UI Emoji" as a font in the list, this should display all supported characters. Our shaping code should probably traverse the hint list further if no font is found for the first hint glyph, which is the first character. Thanks for the test case, I'll take a look.
,
Dec 2 2016
Thank you. With "Segoe UI Emoji", I can see all the glyphs.
,
May 21 2018
This now works as expected and renders as in firefox. Thanks for the report and the test case! |
||||
►
Sign in to add a comment |
||||
Comment 1 Deleted