[css-text-4] text-spacing, closing-opening bracket fullwidth punctuation collapsing

[MurakamiShinyu]

https://drafts.csswg.org/css-text-4/#fullwidth-collapsing

• Set fullwidth opening punctuation half-width if the previous character is a fullwidth opening punctuation, fullwidth middle dot punctuation, or ideographic space (U+3000). Else set it full-width.
• Set fullwidth closing punctuation half-width if the next character is a fullwidth closing punctuation, fullwidth middle dot punctuation, or ideographic space (U+3000). Else set it full-width.
• Set fullwidth closing punctuation followed by fullwidth opening punctuation each at "3/4-width", i.e. halfway between full-width and half-width.

I think the last item above, "3/4-width" rule, is not necessary and the first item should be changed to:

• Set fullwidth opening punctuation half-width if the previous character is a fullwidth opening punctuation, fullwidth middle dot punctuation, fullwidth closing punctuation, or ideographic space (U+3000). Else set it full-width.

The reasons are as follows:

• as mentioned in [css-text-4] should the text-spacing property work with OpenType 1.8 updates? #535 (comment), it is not appropriate when we use half-width / full-width glyphs.
• According to JIS X 4051, Table 5, the half-width space between the closing punctuation and the opening punctuation is attached to the former (closing) punctuation. i.e., the closing punctuation should be set full-width and the opening punctuation should be set half-width. (This is unclear in JLREQ but is clear in JIS)
• Existing typesetting software such as InDesign support the above JIS X 4051 rule.

Example 9 table (Demonstration of adjacent-pairs punctuation trimming) should also be changed:

Closing—Opening 　　〕+（　　)　　(

to

Closing—Opening 　　〕+（　　〕(

BTW, the current stylesheet in css-text-4 cannot render well this table. I found the css-text-3 stylesheet has the following style:

    .char { border: 1px dotted gray; }
    .quarter { font-size: 25%; }
    tt[lang="ja"] { font-family: "MS Gothic", "Osaka", monospace }

I think this should be moved to css-text-4 stylesheet, with some fixing:

    .char { border: 1px dotted gray; }
    .quarter { font-size: 25%; }
    samp[lang="ja"] { font-family: "MS Gothic", "Osaka-Mono", monospace }

Note that regular "Osaka" font is not appropriate because its fullwidth punctuations are not really full width (very narrow!) in current macOS font environment. So I think "Osaka-Mono" is better.

[css-meeting-bot]

The CSS Working Group just discussed text-spacing fullwidth punctuation collapsing, and agreed to the following resolutions:

• RESOLVED: Accept change matching JLReq's punctuation spacing, put a note into the spec about maybe needing more complex stuff, follow up with JLReq about the topic.

The full IRC log of that discussion

<Rossen> Topic: text-spacing fullwidth punctuation collapsing
<Rossen> github topic: https://github.com//issues/1668
<TabAtkins> Florian: In CJK, full-width punct takes a full-width box, but they visually fill half o fit
<TabAtkins> Florian: Japanese expects that when they're next to each other (like two close-parens), there will be a big space.
<TabAtkins> s/there will be a big space/there will not be a big space, they'll be collapsed visually/
<TabAtkins> Florian: The font contains spaces, but it needs to be canceled out in some cases.
<TabAtkins> Florian: We have a rule in Text 4 that says when to do this.
<TabAtkins> Florian: One rule is overcomplicated. We did it wrong because JLReq wasn't specific enough.
<TabAtkins> Florian: Case is where you have a closing punct followed by an opening one: `)(`.
<TabAtkins> Florian: If you did nothing it's 2em long, we want 1.5em long.
<TabAtkins> Florian: Closing, half-space, opening.
<TabAtkins> fantasai: Collapse away the adjacent half space.
<TabAtkins> Florian: We specced that each is .75em long.
<TabAtkins> Florian: Proper is to keep all space on closing one, remove all space from opening.
<TabAtkins> Florian: Difference is barely observable, we should match.
<TabAtkins> fantasai: Did the people working on those things consider the case of different-sized fonts?
<TabAtkins> fantasai: Second paren is half the size of the first one, then what should happen?
<TabAtkins> Florian: That's where it becomes observable.
<TabAtkins> fantasai: I think probably 75% on each side isn't the right answer, so we should change it, but also not convinced we should always use the first.
<TabAtkins> Florian: Unsure. Murakami says to do it the other way, and InDesign does it the other way, so we should match.
<TabAtkins> fantasai: One thing we often do is look at print examples, and find where they're not handling cases.
<TabAtkins> fantasai: I think we should choose one or the other; we could use innermost or outermost...
<TabAtkins> Florian: They're same level.
<TabAtkins> fantasai: Always use bigger one?
<TabAtkins> myles_: That'll cause space to change when font-size animates?
<TabAtkins> TabAtkins: It'll do that no matter what.
<TabAtkins> Florian: I think we should match pubs, with a note about if someone has cases not considered, let us know.
<TabAtkins> fantasai: Korean mixes font sizes a lot; rather than ruby they just reduce font-szie
<TabAtkins> Florian: But they use latin punctuation, not full-width, so this doesn't apply.
<TabAtkins> myles_: I think it makes the most sense to do what everyone else does as a first pass.
<TabAtkins> fantasai: Happy with that if we follow up with JLReq to make sure they think about this case.
<TabAtkins> Rossen: ARe you current JLReq laiason?
<TabAtkins> Florian: Not yet, I have something later about that.
<TabAtkins> koji: I think previous spec is ambiguous, just says "put a half space between them".
<TabAtkins> Rossen: So can we resolve to accept change, put a note in, and follow up with JLReq?
<TabAtkins> RESOLVED: Accept change matching JLReq's punctuation spacing, put a note into the spec about maybe needing more complex stuff, follow up with JLReq about the topic.

[MurakamiShinyu]

My mistake, I wrote:

According to JIS X 4051, Table 5, the half-width space between the closing punctuation and the opening punctuation is attached to the former (closing) punctuation. i.e., the closing punctuation should be set full-width and the opening punctuation should be set half-width. (This is unclear in JLREQ but is clear in JIS)

"This is unclear in JLREQ" was not true. JLREQ's Appendix B Spacing between Characters--Table 1 Spacing between characters clearly defines "1/2 be" (half em space, attached to the before character) between cl-02 closing brackets and cl-02 opening brackets.

[frivoal]

That matched what we resolved, so that's fine.

[fantasai]

OK, I committed the edits for this change. Leaving the issue open because while matching JLREQ is easy, it does not seem to be the correct solution in the case of mismatched font sizes. We're not sure what is, so we need feedback from Japanese typesetting experts.

[MurakamiShinyu]

csswg-drafts/css-text-4/Overview.bs

Line 1124 in 107e4be

ISSUE: The above handling of opening—closing bracket pairs

Here, "opening—closing" should be "closing—opening" ?

[fantasai]

Fixed. Thanks @MurakamiShinyu . :)

[fantasai]

Kobayashi-sensei says that the rule to keep the space of the first bracket in this pair is incorrect. (The rules in JIS X 4051 are scoped to a special case where the second bracket is smaller.) The correct behavior is to keep the space of the larger bracket. It is an acceptable approximation to trim 1/4 of each.

[css-meeting-bot]

The CSS Working Group just discussed text-spacing, closing-opening bracket fullwidth punctuation collapsing, and agreed to the following:

• RESOLVED: accept the proposal from fantasai and Kobayashi-sensei

The full IRC log of that discussion

<dael> Topic: text-spacing, closing-opening bracket fullwidth punctuation collapsing
<dael> github: https://github.com//issues/1668
<fantasai> ] [
<dael> fantasai: Earlier version of text spec...this is about combo of closing full width brack and opening full width bracket ^
<florian> or ）（ or 」「 etc
<dael> fantasai: Typically it takes up a full em but that's too much so Japanese typsetting cuts that in half. Usually by deleting whitespace of second glyph. Not right if they're different font sizes
<dael> fantasai: [missed] says correct behavior is keep space of larger or trim 1/4 of each. Change we made was incorrect. WE should change to 1/4 of each glyph or always use the full glyph of larger and cut smaller in half
<dael> florian: He said both is acceptable, but keeping larger is preferred.
<fantasai> s/[missed]/Kobayashi-sensei/
<dael> florian: Impl what do you think? Is it hard to keep the bigger? If yes we can settle for the good enough.
<dael> fremy: I'm not sure we support this kind of font features across text nodes. I'm not sure we'd have a path to this
<bradk> Seems weird that kerning in the font doesn’t handle that on its own
<dael> florian: I suspect it's easier to trim half of the smaller one because we might be able to invoke open type features. If we do 1/4 of each I don't know open type can do that.
<dael> fantasai: I think I agree.
<dael> fantasai: If there's no feedback from impl we propose keep the full size of the larger glyph and trim smaller.
<florian> bradk, it cannot just be kerning, because that's optional behavior, and also when on, needs to work across fonts.
<dael> dbaron: I'm still trying to understand how much action at a distance there is. How much is that making changes at arbitrary disance in text.
<dael> fantasai: It's the adjacent character. It's two adjacent characters and you have to trim to reduce amount of space.
<dael> dbaron: Just adjacent characters?
<dael> florian: Yes. If there's anything, border, linebreak, anything, it doesn't count.
<dael> TabAtkins: Same boundry we use to determine if we can do kerning?
<dael> fantasai: Yeah
<dael> florian: Don't think. If you switch fonts I think no kerning, but this should work.
<dael> fremy: I don't think we have something like this right now.
<dael> fantasai: I don't think anyone does this as L4
<dael> Rossen_: From use case PoV it seems this behavior makes most sense. I don't believe anyone has impl experience so we can make the call on if this is expensive.
<dael> Rossen_: What if we try and decide on what makes most sense and when we get more impl experience we revist
<dael> fantasai: That's fine. And as florian pointed out there's open type to help with trimming and they don't 1/4 trim so it's more consistant
<dael> Rossen_: Objections to resolving as proposed by fantasai and Kobayashi-sensei ?
<dael> RESOLVED: accept the proposal from fantasai and Kobayashi-sensei