Join GitHub today
GitHub is home to over 20 million developers working together to host and review code, manage projects, and build software together.
[css-text-4] text-spacing, "3/4-width" in fullwidth punctuation collapsing #1668
Comments
frivoal
self-assigned this
Aug 1, 2017
frivoal
added
the
css-text-4
label
Aug 1, 2017
css-meeting-bot
commented
Aug 4, 2017
|
The CSS Working Group just discussed
The full IRC log of that discussion<Rossen> Topic: text-spacing fullwidth punctuation collapsing<Rossen> github topic: https://github.com/w3c/csswg-drafts/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. |
frivoal
added
the
Needs Edits
label
Aug 10, 2017
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
MurakamiShinyu commentedAug 1, 2017
https://drafts.csswg.org/css-text-4/#fullwidth-collapsing
I think the last item above, "3/4-width" rule, is not necessary and the first item should be changed to:
The reasons are as follows:
Example 9 table (Demonstration of adjacent-pairs punctuation trimming) should also be changed:
to
BTW, the current stylesheet in css-text-4 cannot render well this table. I found the css-text-3 stylesheet has the following style:
I think this should be moved to css-text-4 stylesheet, with some fixing:
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.