fall back to 'per-character' fallback when 'per-grapheme' cluster fallback does not find a font |
||
Issue description"ሀ̏ ህ̀ ጀ́" has the following three grapheme clusters: [1] U+1200, U+030F U+1205, U+0300 U+1300, U+0301 Because there will be very few fonts covering the above sequences [2] (U+1[23]xx block is for Ethiopic and U+03xx is a block for combining marks with ScriptExt = Common ), Blink's per-graphme-cluster font fallback ends up showing two empty rectangles (tofus). OTOH, Firefox and Safari are just happy to use one font (Ethiopic font) for base characters (U+1200, U+1205, U+1300) while using another font for U+030x (one of LGC fonts). The result is ok-ish and readers can make sense of what they're reading. The same is true of Chrome's omnibox. The above sequences are rendered ok-ish. BTW, you can see an extreme case of this issue at https://unicode.org/cldr/utility/character.jsp?a=135D&B1=Show . "U+0020 U+135D" is considered a grapheme cluster for which no font is found. Chrome shows two empty boxes. [1] U+030F, U+0300, U+0301 are poor man's substitute for real Ethiopic combining marks, U+135[D-F]. [2] There may be a few (old) Ethiopic fonts to support the above grapheme clusters because U+135[D-F] (proper Ethiopic combining marks) were not added to Unicode until Unicode 6.0.
,
Jun 4 2018
I don't think we should do this in general. What algorithm would you propose for doing this in a way that reliably improves the result? We intentionally moved towards grapheme cluster fallback to avoid situations in which glyphs are combined incorrectly across fonts. IMO we should instead work on improving fallback, for example by using Noto better for fallback inside Chrome. I find it's not predictable whether mixing fonts will be okayish or actually produce a worse result, in this case it may work, in other cases glyphs are very offset or colliding etc.
,
Jun 24 2018
Agree that plugging Noto is better solution. |
||
►
Sign in to add a comment |
||
Comment 1 by js...@chromium.org
, Jun 3 2018