11:04:19 RRSAgent has joined #clreq 11:04:19 logging to https://www.w3.org/2019/11/07-clreq-irc 11:04:28 Zakim has joined #clreq 11:52:15 Meeting: Clreq Editors' Call 12:59:09 xfq has joined #clreq 13:01:21 rrsagent, make log public 13:01:35 present+ Eric, xfq 13:01:57 regrets+ huijing, Yijun 13:02:05 chair: xfq 13:02:07 scribenick: xfq 13:03:24 rrsagent, make minutes v2 13:03:24 I have made the request to generate https://www.w3.org/2019/11/07-clreq-minutes.html xfq 13:06:29 rrsagent, make minutes v2 13:06:29 I have made the request to generate https://www.w3.org/2019/11/07-clreq-minutes.html xfq 13:08:28 Topic: Line breaking for ambiguous characters 14:26:16 https://github.com/w3c/csswg-drafts/issues/4419 14:26:24 Eric: I saw this issue 14:26:24 ... two things 14:26:24 ... the code point of dash in Chinese and English is the same 14:26:24 ... in Latin, there are En Dash and Em Dash 14:26:24 ... in Chinese, there are connector marks and two-em dashes 14:26:30 ... @@ 14:26:30 ... I wrote an article about two-em dashes 14:26:30 ... in strict line-breaking rules, there are prohibition rules for line start/end 14:26:39 rrsagent, make minutes v2 14:26:39 I have made the request to generate https://www.w3.org/2019/11/07-clreq-minutes.html xfq 14:26:43 https://thetype.com/2019/03/14918/ 14:26:48 Eric: the two-em dash is already two-character wide 14:26:48 ... using prohibition rules will cause the position of three characters to be moved 14:26:48 ... that would be very ugly, especially in cases where column width is narrow, like magazine 14:26:48 ... I don't think prohibition rules for line start/end are needed for two-em dashes personally 14:26:57 ... but two-em dashes shouldn't be broken in the middle 14:26:57 ... the situation for other dash-like characters is the same 14:26:57 ... in strict line-breaking rules, there are prohibition rules, but normally we don't enforce them 14:26:57 ... these dash-like characters can appear at line end, but not line start 14:27:03 ... for example, connector marks are used to indicate ranges 14:27:03 ... I think Unicode also has line breaking algorithm for these characters 14:27:07 rrsagent, make minutes v2 14:27:07 I have made the request to generate https://www.w3.org/2019/11/07-clreq-minutes.html xfq 14:27:17 xfq: do you mean UAX #14? 14:27:23 Eric: yes 14:27:23 ... U+2010 (hyphen) is not used in Chinese 14:27:23 ... it is only used for hyphenation in English 14:27:23 ... English uses U+2013 (En Dash) to indicate range 14:27:38 ... Chinese sometimes uses U+2013 for @@ 14:27:38 ... U+2013 is shorter than U+2014 14:27:38 ... I added a note in the Connector Marks section 14:27:42 https://w3c.github.io/clreq/#h-note-23 14:27:48 Eric: The Guobiao standard does not state the corresponding code point for the three types of connector marks 14:27:49 ... we can make the deduction that the long connector mark [—] is U+2014 EM DASH [—] 14:27:49 ... and the tilde [~] can be U+FF5E FULLWIDTH TILDE [～] 14:27:55 ... the width of U+301C (wave dash) is font-dependent and can not be guaranteed 14:27:59 xfq: U+FF5E should be fullwidth 14:28:14 Eric: but the width of U+301C is not clear 14:28:14 ... so I recommend using U+FF5E 14:28:14 ... I am worried that clreq and UAX #14 are not consistent 14:28:36 xfq: UAX #14 behavior can be overriden by browsers if necessary 14:28:42 Eric: since the short connector mark should take half the width of the long connector mark 14:28:43 ... it should be U+2013 EN DASH [–] 14:28:43 ... the position of dash/hyphen is usually not vertically centered 14:28:43 ... it's in the middle between ascender and descender 14:28:49 ... but in Chinese it should be vertically centered 14:28:56 xfq: can we adjust the position of the dash character when lang=zh-* ? 14:29:03 Eric: it is possible 14:29:03 ... but the font needs to support it 14:29:03 ... let's go back to the issue itself 14:29:26 xfq: Koji mentioned that Gecko supports the breaks before hyphens rule only when the hyphen-like character follows Japanese characters, and not when they follow Latin letters 14:29:27 ... and this seems to make sense to be added to the CSS spec 14:29:33 Eric: https://github.com/w3c/csswg-drafts/issues/4419#issuecomment-550116964 14:29:35 ... "I checked JLREQ line break table, and found that it prohibits break before cl-03." 14:29:35 ... it prohibits break only *before* hyphens, not after them 14:29:42 ... so hyphens can be used at line end 14:29:42 ... Chinese is the same as Japanese in this respect 14:29:42 ... we should also check UAX #14 14:29:49 ... https://unicode.org/reports/tr14/ 14:29:49 ... https://unicode.org/reports/tr14/#Table1 14:29:49 ... Em dash is B2 14:29:53 ... hyphens are BA 14:29:55 ... if Em dash is used in Chinese, it may appear at line start, and this is wrong 14:29:58 xfq: so Em dash should be BA in Chinese? 14:30:02 Eric: yes 14:30:06 xfq: Em dash is not mentioned in https://github.com/w3c/csswg-drafts/issues/4419 14:30:06 ... that's a different issue 14:30:12 rrsagent, make minutes v2 14:30:12 I have made the request to generate https://www.w3.org/2019/11/07-clreq-minutes.html xfq 14:30:25 Eric: yes 14:30:26 ... if you use two consecutive em dashes for two-em dash, it might be broken in the middle, per UAX #14 14:30:26 ... U+2E3A TWO EM DASH is not widely supported by fonts and input methods 14:30:32 xfq: Ellipses might suffer from similar issues 14:30:36 Eric: Source Han Sans uses ccmp (Glyph Composition) to render two U+2014 as a U+2E3A 14:30:41 xfq: in summary, the rules for Chinese and Japanese is the same for https://github.com/w3c/csswg-drafts/issues/4419 14:30:47 Eric: yes 14:30:54 Topic: What does fangsong map to for non chinese text 14:30:58 https://github.com/w3c/csswg-drafts/issues/4425 14:31:05 xfq: what font should fangsong should map to for characters outside of Chinese? 14:31:05 ... we need to think more, not only for fangsong, but also for other new generic font families 14:31:12 rrsagent, make minutes v2 14:31:12 I have made the request to generate https://www.w3.org/2019/11/07-clreq-minutes.html xfq 14:41:23 rrsagent, bye 14:41:23 I see no action items