- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Fri, 16 Sep 2022 22:55:24 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `Revisit ic character`. <details><summary>The full IRC log of that discussion</summary> <TabAtkins> Topic: Revisit ic character<br> <TabAtkins> github: https://github.com/w3c/csswg-drafts/issues/7577<br> <TabAtkins> astearns: So issue is whether the change the current "water" character used as the ic reference to the "eternal" charact5er.<br> <TabAtkins> astearns: I propose we make this change, don't see a reason not to.<br> <TabAtkins> heycam: It generated a surprising amount of confusion.<br> <TabAtkins> heycam: Just because it looks so similar to the typical one used for calligraphy<br> <TabAtkins> [looking for Myles]<br> <TabAtkins> [reviewing elika's comments in the thread]<br> <TabAtkins> astearns: My take on her input is that it woudl be fine either way; we did have reasons for that particular character, but there aren't reasons not ot use the other one<br> <TabAtkins> TabAtkins: One reason in the thread is that the water character is prioritized higher in CJK split fonts, so it's more likely to have been loaded already, versus the eternal character<br> <TabAtkins> astearns: It was noted that this isn't necessarily problematic, fonts can change<br> <TabAtkins> TabAtkins: Sure, they could put any char there. But it's not there now.<br> <TabAtkins> heycam: I think we should change; I think it's unlikely we'll encounter situations where fonts have differnt glyph coverage taht is an actual problem.<br> <TabAtkins> heycam: And without the change we'll likely get a slow trickle of people asking why we're using that character.<br> <TabAtkins> [fills in myles on context]<br> <TabAtkins> myles: I think approximately zero people will notice either way<br> <TabAtkins> astearns: A decent number of people seem to have noticed our current value and would welcome the change.<br> <TabAtkins> astearns: And the only technical argument against the change is the bit about it being more quickly loaded in many situations.<br> <TabAtkins> astearns: But it's been argued convincingly to me that it's an artifact of current font subsetting.<br> <TabAtkins> astearns: And someething that could change.<br> <TabAtkins> [fills in fantasai]<br> <TabAtkins> fantasai: Depends.<br> <TabAtkins> fantasai: First, do people actually want to implement this?<br> <TabAtkins> fantasai: I heard someone say they want to change the spec but we wont' change impl<br> <TabAtkins> astearns: Is it testable?<br> <TabAtkins> fantasai: yes<br> <TabAtkins> myles: you make a font with different characters<br> <TabAtkins> astearns: is it testable with current existing fonts?<br> <TabAtkins> heycam: in a subsetting situation and you forget a later one that has the eternal in it, but seems unlikely<br> <TabAtkins> myles: I think it's fine to change and see if problems arise<br> <TabAtkins> fantasai: Second reason is there is the ideographic character face top line and bottom line, which are two metrics we need for alignment of CJK characters<br> <TabAtkins> fantasai: If those metrics aren't in the font, we might ahve to measure them.<br> <TabAtkins> fantasai: So if you have to measure, is it better to measure water, eternal, or does it not matter?<br> <TabAtkins> fantasai: It will matter, since they have different heights<br> <TabAtkins> fantasai: WHich is better? We should ask Ken Lunde or someone at Adobe<br> <TabAtkins> fantasai: bc that's a practical implementation<br> <TabAtkins> fantasai: It would be great symbolically if we use eternal, but if it objectively gives us worse results we shoudln't use it<br> <TabAtkins> myles: what were the metrics?<br> <TabAtkins> fantasai: ICFT line<br> <TabAtkins> fantasai: [describes the ICFT]<br> <TabAtkins> fantasai: The characters are drawn in teh box, slightly inside the em square<br> <TabAtkins> astearns: For this issue, the character we use for ic extent doesn't necessarily specify what the UA would use for this purpose<br> <TabAtkins> fantasai: Right but if we used a different character for each usage, that's not amazing<br> <TabAtkins> astearns: My point is there might be an even differnt character better for that, as it's more close to the edges<br> <TabAtkins> astearns: So is one or other of these chars more or less likely to hit what the browser will use for this approx?<br> <TabAtkins> fantasai: I looked at a bunch to look at this, and a lot you'd think would be good are actually *smaller* than water<br> <TabAtkins> fantasai: Like the one that's just a box, due to optics it's actually smaller than the ink extent of water and eternal<br> <TabAtkins> fantasai: So I tried to find a char that used as much space as possible, and was reasonably frequent, that's how I got water<br> <drott> q+<br> <TabAtkins> fantasai: Dont' ahve a problem with eternal, just want ocnfirmation this won't give us worse results for othe rpurpose<br> <astearns> ack drott<br> <TabAtkins> drott: In trying to figure out this change, it seems like one of the concerns is people coming across the spec and taking issue with the char.<br> <TabAtkins> drott: So maybe being less specific and just saying "a representative character"<br> <TabAtkins> fantasai: We want interop, and dont' want people to pick a bad char without giving thought<br> <TabAtkins> fantasai: Same as for ch unit, we didn't say a representative char, we said 0<br> <TabAtkins> myles: Unsure how interop measuring ink is in reality because browsers can use diff points<br> <TabAtkins> myles: Also in OT, some points can have semantic meaning beyond just glyph bounds, which browsers would want to use<br> <TabAtkins> fantasai: Yeah point is just you don't want the 1 character, for example, bc it's a vertical line. So we want the same char.<br> <TabAtkins> fantasai: It's definitely not very much. But I want somebody who knows how they're typically drawn to confirm it won't be a regression.<br> <heycam> q+<br> <TabAtkins> myles: So 2 options are character that's representative of ic and the other metrics we're interested in, or use separate characters for each.<br> <TabAtkins> astearns: We'r enot speccing the char for the box dimensions if the info's not available in the font.<br> <TabAtkins> fantasai: The ic unit is different from the icft, diffrent from the advance width<br> <TabAtkins> fantasai: Better to use one char for all of these, rather than diff for each.<br> <TabAtkins> astearns: But right now we only specify ic, right?<br> <TabAtkins> fantasai: No, WM uses a char to specify width of tatechuyoko<br> <TabAtkins> myles: interested in knowing what browsers follow those specs right now<br> <TabAtkins> fantasai: If we want to change it bc people are mad, we can do that and I won't object, but I think it would be good to actually find out if this would be practically better or worse.<br> <TabAtkins> myles: This topic isn't urgent, so I don't think we need to push to resolve it right now if we want extra info.<br> <TabAtkins> astearns: I'll action myself to talk to Adobe fonts people about metrics, particularly when they're not in the font.<br> <TabAtkins> astearns: One clarifiction, fantasai asked explicitly about willing to implement<br> <drott> q+<br> <TabAtkins> astearns: myles you said we should try it and see?<br> <TabAtkins> myles: If the spec changes we're willing to try<br> <heycam> q-<br> <TabAtkins> astearns: So no change to the spec today, I'll see what info I can get, perhaps someone with Google Fonts connections?<br> <TabAtkins> drott: Yeah, we have some perf concerns of bracketing of CJK fonts.<br> <TabAtkins> drott: We haven't done a lot of investigation about this yet, so we'll have to look at this more closely.<br> <TabAtkins> drott: But we do currently expect water to be in the first bucket.<br> <TabAtkins> drott: And can see if Google Fonts is willing to make a change to keep eternal in the first bucket<br> <astearns> ack drott<br> <drott> s/bracketing/bucketing/<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/7577#issuecomment-1249922051 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Friday, 16 September 2022 22:55:26 UTC