<html>
<head>
<base href="https://bugs.webkit.org/" />
</head>
<body>
<p>
<div>
<b><a class="bz_bug_link
bz_status_NEW "
title="NEW - Font features specified in @font-face blocks can't force us down the complex text codepath"
href="https://bugs.webkit.org/show_bug.cgi?id=155319#c23">Comment # 23</a>
on <a class="bz_bug_link
bz_status_NEW "
title="NEW - Font features specified in @font-face blocks can't force us down the complex text codepath"
href="https://bugs.webkit.org/show_bug.cgi?id=155319">bug 155319</a>
from <span class="vcard"><a class="email" href="mailto:shikisuen@outlook.com" title="Shiki Suen <shikisuen@outlook.com>"> <span class="fn">Shiki Suen</span></a>
</span></b>
<pre>(In reply to <a href="show_bug.cgi?id=155319#c20">comment #20</a>)
<span class="quote">> The "、" character is U+3001, which lies outside of the unicode-range in the
> example, so we are falling back to AppleSDGothicNeo-Regular to show it.</span >
Yep. That fits the current situation of how "font-variant-east-asian: Proportional Width" deal with CJK punctuations. I just feel weird that they looks still full-width monospaced in such "proportional" occasion, that's why I prefer 'palt' (both kana glyphs and CJK punctuation marks are proportional), which is not only preferred by myself but those Japanese visiting students in my University (I just demonstrated that webpage with some of them today, and they prefer the latter case which was having 'palt' enabled).
(In reply to <a href="show_bug.cgi?id=155319#c19">comment #19</a>)
<span class="quote">> This is because of a disagreement between the fast and complex text code
> paths. In particular, whenever font features are applied, we always want to
> go down the complex text code path. However, when they are applied in an
> @font-face block, we don't realize this and we may still go down the fast
> code path.</span >
Regarding your <a href="show_bug.cgi?id=155319#c19">comment #19</a> (quoted as follows), the reason I have necessities on such complex text code path is because of the following case: Enabling "font-variant-east-asian: Proportional Width" could trigger <a class="bz_bug_link
bz_status_NEW "
title="NEW - Proportional CJK Punctuation Mark could overlap with initial glyph in kyperlink"
href="show_bug.cgi?id=155299">bug 155299</a> and other unknown bug in Safari.
You could apply a global CSS definition to your browser, which consists as follows:
* {font-variant-east-asian: Proportional-Width !important;}
or
* { -moz-font-feature-settings: "palt" !important;
-webkit-font-feature-settings: "palt" !important;
font-feature-settings: "palt" !important;
}
You could definitely find that some websites could show unwanted spaces or linewraps on webpage.
(e.g. Twitter, all https:// marks are defined as invisible in CSS. However, as the definitions above enabled globally, those invisible parts becomes unwanted spaces.)
That's why I am thinking of using complex text code as workarounds: using only kana glyphs from certain Japanese fonts and make them proportional into a standalone @font-face virtual font, and reading CJK Punctuation marks from another font.
P.S.: Frankly speaking, 'palt' is still not ideal enough as the CJK period symbol is too condensed in its space. However, we have no power to ask font manufacturers to improve this. Thus, we have to use @font-face in combination with unicode-range to fit our necessities.</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are on the CC list for the bug.</li>
<li>You are the assignee for the bug.</li>
</ul>
</body>
</html>