- From: Timothy Chien <timdream@gmail.com>
- Date: Fri, 18 Dec 2015 01:33:08 +0800
- To: Xidorn Quan <quanxunzhen@gmail.com>
- Cc: WWW International <www-international@w3.org>, CJK discussion <public-i18n-cjk@w3.org>, "www-style@w3.org" <www-style@w3.org>, 中文HTML5同樂會ML <public-html-ig-zh@w3.org>, Richard Ishida <ishida@w3.org>
On Thu, Dec 17, 2015 at 3:54 PM, Xidorn Quan <quanxunzhen@gmail.com> wrote: > On Thu, Dec 17, 2015 at 5:30 PM, Timothy Chien <timdream@gmail.com> wrote: >> Hi, >> >> The Unicode® Standard Annex #11 have long defined a set of >> recommendations [1] on handling character width in East Asian context. >> >> [1] http://www.unicode.org/reports/tr11/#Recommendations >> >> I assume the recommendations are directed to handling the display of >> the data so it ought to be addressed in CSS. However, these remain >> unspecified in the CSS spec, and web authors have to workaround the >> problems (particularly, characters with ambiguous widths) by >> hard-coding OS font names or even shipping their own web font, to >> ensure width are displayed correctly in critical places, like ASCII >> art "images". > > I don't really see anything which should be addressed but remains > unspecified in CSS in the section you mentioned. Could you point out > exactly which sentences do you think of? > > For ASCII Art, I believe that you just need "monospace" generic font > family (optionally with "white-space: pre"). Not sure why authors have > to "workaround" it. > That's exactly where the problem is. If the ASCII image involved use any of the ambiguous width characters, like ● U+25CF or any of the Greek characters, I have no guarantee whether or not the "monospace" font used will make these characters full-width or half-width -- on Windows I would have to set font-family: PMingLiu instead (because I happen to know know PMingLiu contain U+25CF in full-width) and this only help me on computers with PMingLiu font. Another problematic example is ´ U+00B4, which may mistakenly shown as full-width sometimes in IE in Windows XP zh-TW locale (I don't remember the exact reproducible scenario nor I know how the current Windows behaves). >> Character grid [2] was a related proposal being mentioned by Mr. >> Ishida in [3], but it was removed from the current CSS Text spec [4]. >> The current CSS Text spec does not specify any feature allow web >> authors to specify character width directly nor indirectly from, for >> example, HTML "lang" attribute. >> >> [2] http://www.w3.org/TR/2003/CR-css3-text-20030514/#document-grid >> [3] https://lists.w3.org/Archives/Public/public-i18n-cjk/2015OctDec/0017.html >> [4] http://www.w3.org/TR/css3-text/ > > I believe character grid isn't about "to specify character width > directly or indirectly". It is about a special alignment rule when > narrow / proporational characters appear in wide / monospace document. > >> Quick web searching shows there wasn't any discussion took place, >> ever. People have pointed out offline to me that there isn't a lot of >> interest on this either (particularly because people are able to >> address the issue are not the user of East Asian languages I guess?) >> >> So here it is. Is there any previous discussion/conclusion I am not >> aware of? Thanks! > > For the character grid, there was actually some discussion happens in > TPAC2015. Florian proposed a simplified version of character grid > during CSSWG meeting there. Minutes can be found here [1] (see "Inline > Character Grid" section). > > [1] https://lists.w3.org/Archives/Public/www-style/2015Nov/0264.html > > - Xidorn Thanks for the pointer. I mentioned document grid or character grid because it would kind of achieve the same result, but I understand now this should not be related. Perhaps I should rephrase my question this way: Is there a CSS feature that "treat ambiguous-width characters as double width" as what many Terminal programs offers as user options? If such capability is offered to the web author and set in the UA style sheet with :lang() selector by default, we should have satisfy the recommendation lay out in Unicode TR-11. Thanks, Tim
Received on Thursday, 17 December 2015 17:34:04 UTC