Re: [csswg-drafts] [css-text-4] text-spacing, closing-opening bracket fullwidth punctuation collapsing

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`

<details><summary>The full IRC log of that discussion</summary>
&lt;dael> Topic: text-spacing, closing-opening bracket fullwidth punctuation collapsing<br>
&lt;dael> github: https://github.com/w3c/csswg-drafts/issues/1668<br>
&lt;fantasai> ]  [<br>
&lt;dael> fantasai: Earlier version of text spec...this is about combo of closing full width brack and opening full width bracket ^<br>
&lt;florian> or ）（ or 」「 etc<br>
&lt;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<br>
&lt;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<br>
&lt;dael> florian: He said both is acceptable, but keeping larger is preferred.<br>
&lt;fantasai> s/[missed]/Kobayashi-sensei/<br>
&lt;dael> florian: Impl what do you think? Is it hard to keep the bigger? If yes we can settle for the good enough.<br>
&lt;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<br>
&lt;bradk> Seems weird that kerning in the font doesn’t handle that on its own<br>
&lt;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.<br>
&lt;dael> fantasai: I think I agree.<br>
&lt;dael> fantasai: If there's no feedback from impl we propose keep the full size of the larger glyph and trim smaller.<br>
&lt;florian> bradk, it cannot just be kerning, because that's optional behavior, and also when on, needs to work across fonts.<br>
&lt;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.<br>
&lt;dael> fantasai: It's the adjacent character. It's two adjacent characters and you have to trim to reduce amount of space.<br>
&lt;dael> dbaron: Just adjacent characters?<br>
&lt;dael> florian: Yes. If there's anything, border, linebreak, anything, it doesn't count.<br>
&lt;dael> TabAtkins: Same boundry we use to determine if we can do kerning?<br>
&lt;dael> fantasai: Yeah<br>
&lt;dael> florian: Don't think. If you switch fonts I think no kerning, but this should work.<br>
&lt;dael> fremy: I don't think we have something like this right now.<br>
&lt;dael> fantasai: I don't think anyone does this as L4<br>
&lt;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.<br>
&lt;dael> Rossen_: What if we try and decide on what makes most sense and when we get more impl experience we revist<br>
&lt;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<br>
&lt;dael> Rossen_: Objections to resolving as proposed by fantasai and Kobayashi-sensei ?<br>
&lt;dael> RESOLVED: accept the proposal from fantasai and Kobayashi-sensei<br>
</details>


-- 
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/1668#issuecomment-424793122 using your GitHub account

Received on Wednesday, 26 September 2018 17:00:07 UTC