Clreq Editors' Call

07 May 2020


Bobby, Eric, huijing, xfq, Xidorn

Meeting minutes

Go through the pull request list



xfq: https://‌github.com/‌w3c/‌clreq/‌pull/‌281/‌files
… the definition of type area is only in the English version
… not in the Chinese version
… this PR is for adding the Chinese text
… the English text is from https://‌github.com/‌w3c/‌clreq/‌issues/‌56

Bobby: about the Chinese of "table of contents"
… should we use 目次 instead of 目录?

Eric: type area is also in the Glossary

xfq: yes, the definition in the Glossary was from GB 9851.2-2008, 3.3
… the definitions in the main text and the glossary do not have to be 100% the same
… as long as it is consistent it's fine

Eric: is page number a part of the type area?

Bobby: no

Eric: what about notes?

Xidorn: I don't think headers and footers are part of type area

Eric: "type area" in Chinese is basically the same as "hanmen" in Japanese, but different from "kihon-hanmen"

Bobby: sometimes headers, footers, and notes are part of type area

xfq: How should we modify the text?

Eric: I have a book on typography that says headers and page numbers *are* considered as a part of type area
… type area is the part between 天头 and 地脚
… but whether headers and footers are considered a part of 天头/地脚 is not clear enough
… I think all of the "printed" parts are considered type area

Bobby: we can remove the "It is surrounded by space containing headers, footers, notes, etc." part

Eric: agreed

xfq: I'll push a commit to remove that


xfq: this is a simple PR. Should we merge this?

All: agreed.


xfq: waiting for Richard's reply

Positioning of : and ; in Chinese


xfq: this issue is a question on how fullwidth colon and semicolon are rendered in Chinese & Japanese
… Richard made a summary and asked if it's correct

Eric: the "rotated and centred vertically in vertical text" in "Traditional" should be "centred horizontally in vertical text"
… i.e., the same as horozontal text

Bobby: agreed

xfq: in clreq we have the following text
… "Although pause or stop punctuation marks may be positioned differently within the character square in vertical writing mode and horizontal writing mode, neither need to be rotated."

Rewrite of Compression Rules for Punctuation Marks


Eric: I changed the way of rewriting
… see https://‌github.com/‌w3c/‌clreq/‌issues/‌221#issuecomment-625177822
… in Japanese, the processing of punctuations is 1) Removing 1/2em space (in total) 2) Solid setting 3) Add spacing back
… i.e., punctuations are half-width by default and spacing is added
… in Chinese, there is no "Removing 1/2em space" process, so only removing/compressing (1/2 or 1/4 em) space is needed, no need to *add* spacing
… i.e., punctuations are full-width by default and spacing is removed/compressed
… as I described in https://‌github.com/‌w3c/‌clreq/‌issues/‌221#issuecomment-625177822
… spacing around some punctuations can be adjusted, while others can not
… Japanese is relatively simple, but Chinese is more complicated
… because how the character face is handled and positioned relative to the character frame is different in Mainland China, Hong Kong, and Taiwan

[Eric describes the new text]

Eric: I turned the exhaustion of every situation into an overview because exhaustion is too complex, as you can see in the appendix of jlreq
… before discussing the compression rules, we must first define where the compression can happen (left/right/top/bottom)
… Japanese doesn't have this issue since their punctuations are half-width by default
… I encourage people to take a closer look at my comment in https://‌github.com/‌w3c/‌clreq/‌issues/‌221#issuecomment-625177822
… we can discuss this again next time

xfq: are you suggesting that we change the section title from "Compression Rules for Punctuation Marks" to "Width Adjustment for Punctuation Marks"?

Eric: either "compression" or "adjustment" is OK for me
… as long as the title and the text match

[Discuss the image in https://‌github.com/‌w3c/‌clreq/‌issues/‌221#issuecomment-625177822]

Eric: horizontal text in Hong Kong and Taiwan often have no compression rules
… comparing with line adjustment rules, the compression of adjacent punctuation marks is relatively simple
… I can add more illustrations for the compression rules section

Go through the issue list



xfq: jlreq is also discussing this issue (for Japanese)

Bobby: Bopomofo sometimes break words using spaces
… especially in Bopomofo-only text

[xfq describes this issue]

xfq: Should we add spaces (U+0020) between between Han and Latin characters?
… If spaces should be added, how to deal with the pages without spaces added?
… If spaces should not be added, how to deal with pages that have been added with space characters?

xidorn: I'm leaning towards only discard if both sides (before and after) the line break are part of the space-discarding character set
… although it's not perfect for Chinese and Western mixed texts *not* adding U+0020

[Discuss the status of the text-spacing CSS property]

[Discuss the quarter em spacing issue and JIS X 4051 in https://‌github.com/‌w3c/‌jlreq/‌issues/‌163]

Bobby: I remember some discussions in TPAC 2015 on line breaking issues of Chinese and Western mixed texts

xfq: how should we handle Yijing Hexagram Symbols / Tai Xuan Jing Symbols / Counting Rod Numerals
… and Enclosed CJK Letters and Months / Enclosed Ideographic Supplement?

xidorn: No one will write a whole paragraph with these characters
… the probability of line breaks near these characters is very low

Bobby: I don't think hard wrap Chinese text in HTML is good practice

xfq: the counting rods block also contains Western tally marks

Eric: is this really a clreq issue?

xfq: I don't think we need to write this in the clreq document
… but we need to answer the question from CSSWG

[xfq introduces the background of https://‌github.com/‌w3c/‌csswg-drafts/‌issues/‌337]

[Discuss the status of css-text-3]

Eric: typography is difficult!

xidorn: css-text-3 is "rough interoperability" in https://‌www.w3.org/‌TR/‌2019/‌NOTE-css-2018-20190122/

Next telecon time

June 10 (Wednesday), 19:00-20:00 (UTC+8)

Minutes manually created (not a transcript), formatted by scribe.perl version 117 (Tue Apr 28 12:46:31 2020 UTC).