Created attachment 273601 [details] [Demonstration] EAFontVariantWithinFontFace.html // Please drop and lock bug 155316 and its related radar issue since its initial bug reporter made false assumptions to my idea before my confirmation on Twitter: https://twitter.com/ShikiSuen/status/708026601452122112 1. This bug is NOT related to specific fonts, but ALL fonts support "Font-Variant-East-Asian: proportional-width". I tested this webpage with Source Han Sans, it shows the same. 2. In the 2nd case of my attached demonstration page, it uses Font-Variant-East-Asian: proportional-width and works well. HOWEVER, in the 1st case of my attached demonstration page, "Font-Variant-East-Asian: proportional-width" is defined within @font-face and it couldn't work. P.S.: The 3rd case using palt is just the only way I could use to make both Kana and CJK Punctuation marks proportional in both Safari and Chrome, while Font-Variant-East-Asian: proportional-width couldn't be effective in Chrome.
<rdar://problem/25092073>
<rdar://problem/25092074>
Please do not make this issue as duplicate since people could easily get misunderstood if they read bug 155316 but not the current one. I am sorry, I appreciate its initial reporter, but his misassumption made me have to reclaim this issue here.
Webkit Version: WebKit-SVN-r197678 Safari Version: The most recent developer preview of OS X 10.11.4 and iOS 9.3 (as when WebKit-SVN-r197678 was released).
<rdar://problem/25092410>
Let me address something which should be really considered as intended here: Currently, "Font-Variant-East-Asian: proportional-width" should enable proportional kana in at least 'Hiragino Kaku Gothic ProN' and 'Source Han Sans'. This does well in Safari except the current bug I am claiming about (it does not work within @font-face block). However, it does not work with Google Chrome in any case at this moment. However, CJK punctuation marks may take too much horizontal space if still being displayed full-width and they could look better if condensed in space. That's why standard Japanese fonts like 'Hiragino Kaku Gothic ProN' and 'Source Han Sans' supports 'palt' table, which offers both Proportional Kana and Proportional CJK Punctuation Marks. (However, Safari has another issue relating to 'palt': https://bugs.webkit.org/show_bug.cgi?id=155299 , FYI.)
The only difference I can see between the first case and the second case is due to the unicode-range property in the @font-face. If you remove that property, the first two cases are pixel-per-pixel identical.
However you could find that the unicode-range covers Japanese Kana. (In reply to comment #7) > The only difference I can see between the first case and the second case is > due to the unicode-range property in the @font-face. If you remove that > property, the first two cases are pixel-per-pixel identical.
Update: This bug get triggered in case you turn the Unicode-Range on. In the 1st case of my attached demonstration, the unicode-range covers Japanese Kana glyphs.
Created attachment 273610 [details] Repro with unicode-range
Created attachment 273611 [details] Repro without unicode-range
I've uploaded a reduction. The two pages should be rendered identically.
Created attachment 273614 [details] Difference between what the first two attachments of Myles C. Maxfield look like.
Update towards what the 1st case should look like: Only kana glyphs (as covered in the unicode-range definition) are supposed to be displayed proportional but not "monospaced" in full-width. ================= To Myles:> Differences could still be shown on my side. Could you please tell me which build of Webkit are you using? I am using r197678.
(In reply to comment #14) > Update towards what the 1st case should look like: Only kana glyphs (as > covered in the unicode-range definition) are supposed to be displayed > proportional but not "monospaced" in full-width. > ================= > To Myles:> > > Differences could still be shown on my side. Could you please tell me which > build of Webkit are you using? I am using r197678. I'm also using the most recent nightly, which is r197678
(In reply to comment #15) > (In reply to comment #14) > > Update towards what the 1st case should look like: Only kana glyphs (as > > covered in the unicode-range definition) are supposed to be displayed > > proportional but not "monospaced" in full-width. > > ================= > > To Myles:> > > > > Differences could still be shown on my side. Could you please tell me which > > build of Webkit are you using? I am using r197678. > > I'm also using the most recent nightly, which is r197678 We may be miscommunicating. I am seeing a difference in rendering between the two pages. There is a bug here.
(In reply to comment #16) > (In reply to comment #15) > > (In reply to comment #14) > > > Update towards what the 1st case should look like: Only kana glyphs (as > > > covered in the unicode-range definition) are supposed to be displayed > > > proportional but not "monospaced" in full-width. > > > ================= > > > To Myles:> > > > > > > Differences could still be shown on my side. Could you please tell me which > > > build of Webkit are you using? I am using r197678. > > > > I'm also using the most recent nightly, which is r197678 > > We may be miscommunicating. I am seeing a difference in rendering between > the two pages. There is a bug here. Uh... So you successfully reproduced this bug?
(In reply to comment #17) > (In reply to comment #16) > > (In reply to comment #15) > > > (In reply to comment #14) > > > > Update towards what the 1st case should look like: Only kana glyphs (as > > > > covered in the unicode-range definition) are supposed to be displayed > > > > proportional but not "monospaced" in full-width. > > > > ================= > > > > To Myles:> > > > > > > > > Differences could still be shown on my side. Could you please tell me which > > > > build of Webkit are you using? I am using r197678. > > > > > > I'm also using the most recent nightly, which is r197678 > > > > We may be miscommunicating. I am seeing a difference in rendering between > > the two pages. There is a bug here. > > > Uh... So you successfully reproduced this bug? Yes.
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.
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.
Actually, the original content had "HiraKana, 'Hiragino Kaku Gothic ProN'" which means were were falling back to Hiragino Kaku Gothic ProN, except that fallback font doesn't have font-variant-east-asian: proportional-width enabled, so it is treated as a distinct font.
We really, really don't want to realize all the fallback fonts (to inspect them to see if they have features) at the point when we determine which code path to use. That makes this quite difficult.
(In reply to comment #20) > 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. 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 comment #19) > 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. Regarding your comment #19 (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 bug 155299 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.
(In reply to comment #21) > Actually, the original content had "HiraKana, 'Hiragino Kaku Gothic ProN'" > which means were were falling back to Hiragino Kaku Gothic ProN, except that > fallback font doesn't have font-variant-east-asian: proportional-width > enabled, so it is treated as a distinct font. Hirakana is a virtual font defined by using @font-face.
Created attachment 273625 [details] [Demonstration] EAFontVariantWithinFontFace.html (Updated, Virtual Font Definition Brought to the top) Update to the HTML demonstration. Virtual Font Definition Brought to the top.
(In reply to comment #22) > We really, really don't want to realize all the fallback fonts (to inspect > them to see if they have features) at the point when we determine which code > path to use. That makes this quite difficult. If it is difficult on the browser coding, then I am not sure whether your team is convenient to troubleshoot the another possible bug as what I described in comment #23.
(In reply to comment #21) > Actually, the original content had "HiraKana, 'Hiragino Kaku Gothic ProN'" > which means were were falling back to Hiragino Kaku Gothic ProN, except that > fallback font doesn't have font-variant-east-asian: proportional-width > enabled, so it is treated as a distinct font. You were absolutely not falling back to Hiragino Kaku Gothic ProN at first. You create an HTML which consists the following contents, and you could see that the @font-face with Unicode Range also omits western font variants: ================= <!DOCTYPE html> <html> <head> <meta charset="UTF-8"> <title>"font-variant-east-asian" in "@font-face"</title> <style> @font-face {unicode-range: U+0061; /* a */ font-family: SMALLCAPS-A; src: local('Georgia'); font-variant: small-caps;} sample {font-family: SMALLCAPS-A, Helvetica;} sample2 {font-family: Georgia; font-variant: small-caps;} </style> </head> <body> <h1></h1> <p><sample> Idea. </sample></p> <p><sample2> Idea. </sample2></p> </body> </html>
Created attachment 273632 [details] Another example to prove that Comment #21 is wrong. File to prove that Comment #21 is wrong. The initial virtual font defined by @font-face is actually being displayed. This attachment is another western example to show that the initial virtual font displays but defects in font-variant features in case of enabling Unicode-Ranges.
Created attachment 273634 [details] Not related to Unicode Range.png (In reply to comment #7) > The only difference I can see between the first case and the second case is > due to the unicode-range property in the @font-face. If you remove that > property, the first two cases are pixel-per-pixel identical. I removed this unicode-range property and have still found that it defects. See attachment "Not related to Unicode Range.png".
Created attachment 275071 [details] Myles' sample webpage merged and updated with a longer string for demonstration. Through further tests, this issue has been addressed in r198471. At least, my example looks fine in r198471. It is worth to be mentioned that Myles' sample webpages attached here won't reflect this update. I updated his sample webpage (by using a longer sample text string) to indicate that this issue has only been addressed with texts but not text background colors.
Created attachment 275072 [details] [Screenshot] Myles' sample webpage merged and updated with a longer string for demonstration.
Created attachment 276569 [details] Another comparison sample HTML. Problem with width calculation?
Created attachment 276570 [details] Rendering WebKit r199629 png image
(In reply to comment #32) > Created attachment 276569 [details] > Another comparison sample HTML. > > Problem with width calculation? Based on your example, the background width of line 5 & 6 should be identical but actually different. so does 2&3, 8&9, 11&12, 14&15. Thanks for your html example, looks more evident than what Myles and I made individually.