font-feature-settings dlig for multiple CJK characters
Reported by
kudoh.ka...@realtype.jp,
Apr 8 2016
|
|||||||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/49.0.2623.110 Safari/537.36 Example URL: https://jsfiddle.net/llsmrsll/ksqwswro/ Steps to reproduce the problem: 1. To prepare the font-feature-settings dlig and Font with a "dlig" 2. Set the "dlig" to DOM What is the expected behavior? This feature replaces a sequence of glyphs with a single glyph (a ligature), which is preferred for typographic purposes. When enabled, this feature inserts those ligatures which may be used for special effect. What went wrong? "dlig" was not working on Japanese unicode range. Does it occur on multiple sites: Yes Is it a problem with a plugin? No Did this work before? N/A Does this work in other browsers? Yes Chrome version: 49.0.2623.110 Channel: n/a OS Version: OS X 10.11.4 Flash Version: Shockwave Flash 21.0 r0
,
Apr 18 2016
Do we have a tracking bug for this already drott? If so please merge as needed.
,
Apr 18 2016
Thanks for the useful test case, kudoh.kazuhiko. Koji, this seems to be an issue of the CJK caching segmentation. Looks like we need to know/check whether the font has isCJKIdeographOrSymbol()-type characters in the lookup tables.
,
Apr 20 2016
Yeah, the CJK segmentation optimization is guilty. Disabling word iterator if 'dlig' and the dlig contains CJK character is one way to go, but unlike bug 479370, authors are likely to apply 'dlig' to the whole document, so we might slow down the whole document. We'll need some ideas how to make this work without regressing the performance much.
,
Apr 20 2016
Yes - well, I think we need to take all multi-character lookup features into account, not only DLIG, scan the tables for whether the lookup sequences contain CJK, and then check whether such features are activated for CJK runs, and potentially disable the CJK caching segmentation in this case. Behdad@, any idea how FF handles this?
,
May 4 2016
After we have * shaper-assisted line breaking (eae@, crbug.com/609117 ) * fixed-length cutoff for maxmium shaping length we should consider whether we can remove the CJK segmentation in CachingWordShaperIterator that was put there to unblock slow CJK linebreaking.
,
May 4 2016
I'm not positive. Not segmenting characters in CJK is like not segmenting words in Latin. Each "word" in the cache will be a paragraph. I haven't measured but we'd probably be faster to disable the cache at all. Ligatures of multiple CJK characters not working is shame, but it's so rare and the user benefits of supporting it is far less than loosing the benefit of the cache. We need to find a way to fix this without sacrificing the cache.
,
May 4 2016
Let's measure twice, cut once ;)
,
May 6 2016
BTW, forgot to mention: > * fixed-length cutoff for maxmium shaping length This didn't really help, at least on Win/Official, please see https://bugs.chromium.org/p/chromium/issues/detail?id=603398#c10 > Let's measure twice, cut once ;) Could you explain a bit more?
,
Jun 19 2017
This will be done as a part of inline layout for LayoutNG.
,
Sep 11 2017
,
Sep 11 2017
,
Oct 26
|
|||||||
►
Sign in to add a comment |
|||||||
Comment 1 by cbiesin...@chromium.org
, Apr 8 2016