W3C home > Mailing lists > Public > public-css-archive@w3.org > October 2017

Re: [csswg-drafts] [css-text-decor] ink skipping should conform to glyph shape

From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
Date: Wed, 25 Oct 2017 16:50:12 +0000
To: public-css-archive@w3.org
Message-ID: <issue_comment.created-339395729-1508950211-sysbot+gh@w3.org>
The Working Group just discussed `ink skipping should conform to glyph shape`, and agreed to the following resolutions:

* `RESOLVED: Add the statement that stroke should follow the curve of the glyph as well as adding a non-normative note that points out anything not captured in the GH issue and add better pictures.`

<details><summary>The full IRC log of that discussion</summary>
&lt;dael> Topic:  ink skipping should conform to glyph shape<br>
&lt;fantasai> s/tweeked/tweaked/<br>
&lt;dael> github: https://github.com/w3c/csswg-drafts/issues/1093<br>
&lt;dael> fantasai: There was a complaint about how impl, when they cut off the underline they cut off a striaght line. You don't want the underline to stop with a blunt edge and then have a gap between glyph edges, you want it to follow the edges of the glyph.<br>
&lt;dael> fantasai: The spec doesn't say anything specific so I was thinking we could have advice, you should have underline edges hug glyph.<br>
&lt;dael> fantasai: There was a concern on performance which is why I'm suggesting a should. An impl could decide to do  it if font size is large enough, but not in  general case. That would resolve a lot of perf considerations. I think spec should offer this advice.<br>
&lt;fantasai> https://www.ietf.org/rfc/rfc2119.txt<br>
&lt;fantasai> proposed text: "stroke endings should follow the curve of the glyph"<br>
&lt;dael> myles: You can have a desc ofo good typography. There's more to good underlining then having it follow contors of glyph. You'll want a larger explination of good typography of underlines and that doesn't feel like it should be a normative description. It feels another spec or note.<br>
&lt;dael> florian: Are they big enough that they cannot be phrased as shoulds?<br>
&lt;dael> florian: Do you think it's too high level for normative?<br>
&lt;dael> myles: Yeah.<br>
&lt;dael> myles: If you're going to have a couple paragraphs on good typography it shouldn't be normative.<br>
&lt;dael> Rossen_: I'm hearing one proposal for adding the should which suggests how a good typography works for underlining and I head some push back on why is this normative and not informative somewhere.<br>
&lt;dael> dbaron: One comment on myles statement. I don't want to get into a situation where you need to be an expert in other fields to impl the spec. The spec ought to say what you need to do to impl. If there's advice on good typography that should be known by an impl it should be on the WG to have that as part of the behavior the spec desc.<br>
&lt;dael> myles: I think the spec does  that as is.<br>
&lt;dael> fantasai: It desc certain nec. things. We'd like the impl...given the option we'd say yes you should have the curve follow the glyph curve. What follow means, you have to think about that, but that's why we shouldn't be over specific. That's why we word things with an appropriate level of specificity so you know what to do.<br>
&lt;dael> myles: Point I was trying to make...for ex if the spec says underline shoudl follow control of glyph and impl could use mask-base and then you have underlines in the curve of the g and htat's worse typography. If you're going to have this it needs to be much longer. If it's a general of how underlines should work...<br>
&lt;dael> fantasai: Typography is very broad. If you want more desc on ways you can mess thi sup, that's fine. typography of underlines in general is out of scope for this.<br>
&lt;dael> myles: Right. Doing this..<br>
&lt;dael> fantasai: It's not out o scope for the spec. L4 has the ability to adjust underline and will have much more detail. This topic isn't position, this is where you don't draw a line. A desc here should assume position and thickness was chosen already.<br>
&lt;dael> myles: I'm not talking position and thickness.<br>
&lt;florian> q?<br>
&lt;dael> Rossen_: myles is your push back on adding this statement very strong or is this something you can live with.<br>
&lt;dael> myles: I'm not going to object.<br>
&lt;dbaron> If the spec says "use the position and thickness specified in the font metrics" then position and thickness aren't something that implementors need to think about<br>
&lt;dael> Rossen_: Okay. And fantasai if this was a non-normative note would you be okay or would you pref the should.<br>
&lt;dael> fantasai: I'd prefer the should so it's clear to impl this is the behavior that we want. We can add a note saying there's things you need to watch out for and if myles wants to point out anything not in the issue when doing the note I can add that.<br>
&lt;dael> Rossen_: In summary you propose to add the scroke of the underline shoudl follow the curve of the glyph. That's the text?<br>
&lt;dael> fantasai: Yes and a note ot address myles concerns.<br>
&lt;dael> myles: We should also add a picture because the one in the spec is 2px tall.<br>
&lt;dael> fantasai: Good idea. We can have some of those g<br>
&lt;dael> dbaron: Will the note have the thing about maybe only large font sizes?<br>
&lt;dael> fantasai: I can do that.<br>
&lt;dbaron> s/only/doing it only at/<br>
&lt;dael> Rossen_: Proposed resolution: add the statement that stroke should follow the curve of the glyph as well as adding a non-normative note that points out anything not captured in the GH issue and add better pictures.<br>
&lt;dael> RESOLVED: Add the statement that stroke should follow the curve of the glyph as well as adding a non-normative note that points out anything not captured in the GH issue and add better pictures.<br>
&lt;fantasai> s/not captured/captured/<br>

GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/1093#issuecomment-339395729 using your GitHub account
Received on Wednesday, 25 October 2017 16:50:19 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 5 July 2022 06:41:19 UTC