New issue
Advanced search Search tips

Issue 857087 link

Starred by 1 user
Status: WontFix
Owner: ----
Closed: Oct 27
Cc:
kojii@chromium.org
drott@chromium.org
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Mac
Pri: 3
Type: Bug



Sign in to add a comment

U+26AE, U+26AF, and U+26E2 fail to render in LayoutNG

Project Member Reported by kojii@chromium.org, Jun 27 2018 
Steps to confirm the result:
1. https://test-results.appspot.com/data/layout_results/linux_layout_tests_layout_ng/7218/layout-test-results/results.html
2. Click [All] or [LayoutNG failures]
3. Type "unicode-fallback-font.html" to [Filters] text box and hit Enter key.
4. Click "fast/text/unicode-fallback-font.html"

* U+26AE, U+26AF, and U+26E2 fail to render on Linux.
* U+26E2 fails to render on Mac.
* All these render on Windows.

I guess this is because LayoutNG shapes across space characters.

drott@, do you have any ideas why these characters are affected?

Comment 1 by drott@chromium.org, Jun 29 2018 

I don't have a good explanation. Perhaps rather an issue that because of different run length (line/paragraph vs. words) font fallback patterns are different and there is a bug there? I assume the LayoutNG bot uses the same deterministic font configuration that we established for the other linux bots?

Comment 2 by kojii@chromium.org, Jun 29 2018 

> I assume the LayoutNG bot uses the same deterministic font configuration that we established for the other linux bots?

I think so, since our results changed when bots' fonts were changed.

I guess this is either by design or hit some problem in fallback or run segmenter. Sounds like we need to debug what's happening to know more. Do you think you can help?

Comment 3 by e...@chromium.org, Oct 27

Status: WontFix (was: Available)
►

Sign in to add a comment