- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 16 Sep 2020 17:03:15 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-fonts] Proposal to extend CSS font-optical-sizing`. <details><summary>The full IRC log of that discussion</summary> <dael> Topic: [css-fonts] Proposal to extend CSS font-optical-sizing<br> <dael> github: https://github.com/w3c/csswg-drafts/issues/4430<br> <dael> Rossen_: A rather large issue<br> <dael> myles: This font-optical-sizing property takes 2 values, auto and none<br> <Rossen_> q?<br> <dael> myles: Optical sizing is a way for letters to effect shape of outlines. On large sizes letter shapes are more delicate for visual beauty and when small serifs are elongated. Fonts can morph shape<br> <dael> myles: Impl with a variable feature. Inside the fonts the variable axis is set to the font size.<br> <dael> myles: Webkit sets to css pixel size. I think all browsers do, but not sure.<br> <dael> chris: They do not which is the problem<br> <dael> myles: Okay<br> <dael> myles: Another piece of information is open type spec which defines that axis says that this is supposed to be set to font size in points. Not css points, but points. Relevant to MacOS and iOS.<br> <dael> myles: Actual proposal is to extend syntax to not just be none and auto but add a number that's more expressive so authors can say if they want font size to be css pixels, css points, or something else.<br> <dael> myles: I have opinions but want to let others speak.<br> <dael> myles: I guess I can mention why I think it's bad. There is a right answer which is what open type spec says. On MacOS and iOS the OSs have a coordinate system. Designed such that 72 typographic points = 1 physical pixel.<br> <chris> q+<br> <dael> myles: In webkit we want integral sized pixel blanks on physical pixel boundaries. We have 1 css pixel = 1 typographic point. Gives crisp backgrounds. 1 css inch = 4/3 typographic inches.<br> <dael> myles: Means if you want length supplied in typographic points the way you get that on webkit is you supply css pixels. That's how we've defined it. It's correct though not intuitive. The spec...no reason to increase flexibility because we're doing it correctly.<br> <dael> chris: Backing myles up. He's explained how it comes to correct way. Others have seen that webkit sets in css pixels but don't have the rest so it comes out wrong. It's a problem. Easiest solution is for other browsers to fix it which is as simple has multiplying by 4/3.<br> <Rossen_> ack chris<br> <dael> chris: I think the proposal which is on this thread and on opentype list they assume browsers won't change so they need to fix it in the spec. I would prefer the other browsers did it so they get correct size and then we don't need anything else.<br> <dael> chris: jfkthame did point out the way the others browser do it. I hope he's on.<br> <dael> fantasai: Quesiton. If I write a document in MS word and say font size is 12 pt and have optical sizing enabled, print it. export to HTML. print that. Sizes are 12pt in both cases. Do I get different results?<br> <dael> chris: Interesting. Size in both prints and size on screen. I don't know.<br> <dael> fantasai: Authors would expect to render the same<br> <dael> chris: Yes<br> <dael> fantasai: Can we make sure that happens? I'm confused as to what is happening but I think that should be a constraint.<br> <faceless2> There is no support in PDF or PostScript for variable fonts. So any optical-sizing axis adjustments are done before the print layer, in the application.<br> <chris> q+<br> <dael> myles: Relevant piece here is the scale...on MacOS and iOS we have 1 typographic point = 1 css pixel. When you print that may not be true. COuld come out same even if you see on screen different for OS.<br> <dael> fantasai: Suppose I have a doc I'm looking at on screen. Optical sizing axis has significant differences. Will I get different shape text when print? Should I?<br> <dael> myles: You could, yes. CSS units to typographic units is different when printing. Could be because we've picked this scale because of screens. When printing don't have that.<br> <dael> fantasai: Optical sizing is change in glyph shape. What does it have to do with crispness of glyph?<br> <dael> myles: Sorry. We've scaled entire css coordinate system by 1/3. That's b/c in web today authros say 4px for things like border and margins. All over the place. If we made it such that 1 css inch = 1 typo inch the px length would not map to a physical pixel. Solved by scaling hte entire css coordinate system by 1/3 so things lie on pixel boundaries more often.<br> <dael> fantasai: ...okay<br> <dael> chris: True of original mac. Seems like high dpi devices there are more options. I guess these are micro-pixels?<br> <dael> myles: I'd like to not talk retina.<br> <dael> chris: I would because they're relevant<br> <bradk> Not every iPhone has a Retina display<br> <dael> myles: There's a 3rd system. There's phsyical if you measure crystal size. Not relevant b/c impacts by manufacturing process. More relevant is typographic b/c that's what OS is designed with.<br> <dael> myles: If I want something 1 inch big on an app I'll use pixels. Assumption is that because OS is designed with a coord system if you make something a certain number of points in the coord system it'll look close on the phsyical screen.<br> <chris> q-<br> <dael> Rossen_: At the hour and need to wrap. We're in the middle of the conversation. I see chris and fantasai on the queue so I encourage them to continue discussing on the issue and we can resume next week.<br> <dael> fantasai: Summary- What i'm saying is on the OS system level in different apps. Non web borwser 1pt = 1px. Within css 1 pt and 1 px and not same. So 1 css pt is different. When you print the points are equat to each other. We have inconsistent matchups. Issue is that WK choose to go along one set of eq. lines and hte people filing the issue picked a different set.<br> <fantasai> s/saying/understanding/<br> <dael> Rossen_: Let's resume in issue. myles when you feel it's ready please bring it back<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/4430#issuecomment-693537765 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 16 September 2020 17:03:17 UTC