- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Thu, 30 Jan 2025 16:38:25 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-fonts-5][css-inline-3] Text Edge Metrics Registry`, and agreed to the following: * `RESOLVED: Start a shared registry on layout-affecting lines as a joint effort between CSS and i18n` <details><summary>The full IRC log of that discussion</summary> <emilio> fantasai: we've created a new feature, text-box-trim, that relies on knowing the strong top/bottom edges of the font<br> <bramus> ScribeNick: emilio<br> <emilio> ... we only have metrics for some writing systems<br> <emilio> ... e.g open type gives you cap height, but the top might or might not be it<br> <emilio> ... we've requested this 8 years ago<br> <emilio> ... and they still have not done anything about it, but maybe they don't know what it might look like<br> <emilio> ... so in order to get things moving somebody needs to collect this info<br> <emilio> ... so I propose it to be a joint effort<br> <emilio> ... w3c has the concept of registry<br> <emilio> ... we can create one where each metric is a writing system<br> <emilio> ... where we can have what the top / bottom are<br> <emilio> ... and if they don't correspond with latin then we need more metrics<br> <emilio> ... also examples and pictures<br> <emilio> ... and optionally how to derive that metric if you don't have it<br> <emilio> ... that's basically the idea<br> <emilio> astearns: if we could collect this info, what would we use it for?<br> <emilio> fantasai: one, tell opentype so that they can add metrics<br> <emilio> ... also we need to add keywords in text-box-trim to reference those edges<br> <florian> q+<br> <r12a> q+<br> <emilio> astearns: but if OT hasn't provided a metric in the format and fonts for that writing system aren't consistent there's nothing we can do with that keyword<br> <astearns> ack florian<br> <emilio> fantasai: well we could derive it from heuristics / existing metrics<br> <emilio> florian: agree it'd be useful, and someone needs to do this<br> <emilio> ... the keywords won't be super useful until fonts get there but they're also not useless<br> <emilio> ... in terms of who gives us info for the registry, there's 2 groups<br> <emilio> ... people givin examples<br> <emilio> ... on this language the top matches x other language or what not<br> <emilio> ... that could be anyone<br> <emilio> ... but then there needs to be a second group<br> <emilio> ... that reviews the former<br> <emilio> ... and as soon as their line is different from other line and we just collect<br> <emilio> ... that might give us too many lines<br> <emilio> ... and some of them might be the same<br> <emilio> ... so there's an interest on getting as many people as possible to contribute to adding data<br> <astearns> ack r12a<br> <emilio> ... but then we need another group to triage<br> <emilio> r12a: if we had these labels, how is it useful if OT has them?e<br> <emilio> s/e//<br> <emilio> ... we have hanging/roman/alphabetic baseline<br> <florian> q+<br> <emilio> ... I had the impression that you'd have those baselines defined but also you have the height right? But not sure how that would look on languages that have both upper and lowercase<br> <emilio> ... is it script-specific?<br> <emilio> ... e.g. x-height is not the same in many script<br> <emilio> ... those are questions I have about what this is for<br> <astearns> ack florian<br> <emilio> florian: 2 examples<br> <emilio> ... initial-letter, you align the top of the enlarged letter with the top of the regular text<br> <emilio> ... what is it? cap height? x height? hebrew top? thai top?<br> <emilio> ... if the language has a top that doesn't match cap / x height we need to know<br> <emilio> ... same if you're vertical-aligning to any line that isn't latin / cjk<br> <emilio> ... same for text trimming, and you're dealing with a metric that isn't cap / x height<br> <emilio> ... e.g. hebrew<br> <r12a> qq+<br> <emilio> ... so we need either opentype to tell us where that line is<br> <emilio> ... or have a way of compute it<br> <emilio> fantasai: or adding a font descriptor that tells you<br> <astearns> ack r12a<br> <Zakim> r12a, you wanted to react to florian<br> <emilio> ... I know where the line is even though<br> <emilio> r12a: so absolute or average line? In my ??? notes I have some diagrams and it really varies by font<br> <emilio> ... so question is would we be wanting per font metrics rather than per-script metrics?<br> <emilio> ... there's wide differences even within the same script<br> <emilio> ... the extent to which ascenders go up and down<br> <emilio> fantasai: which is why we want the font or font descriptor to provide it, but the line has a name which in latin might be the cap height, but in hebrew might be the aleph line...<br> <astearns> q+<br> <emilio> ... if we didn't have a cap height on designers would need to tweak the alignment to match it<br> <emilio> ... and same in hebrew or thai<br> <emilio> ... we need to know the name of the line and whether it matches an existing metric<br> <emilio> florian: so the position of the line is per font<br> <emilio> ... but the existence of the line is per script<br> <emilio> astearns: the writing system might have a traditional design line but how different fonts deal with that might or might not match with that line<br> <r12a> q+<br> <florian> q+<br> <emilio> ... so in order for this to be effective we'd need a way of matching the design line with particular font metrics from the font descriptor or so<br> <emilio> ... so that in one font they get the right line<br> <astearns> ack astearns<br> <emilio> ... which wouldn't be in regular CSS but on the font-face descriptor<br> <ChrisL> q+<br> <emilio> florian: yeah but in order to allow a descriptor to tell us where the line is we need to agree on the existance and name of the line<br> <emilio> ... in english we have x/cap height<br> <ChrisL> rrsagent, here<br> <RRSAgent> See https://www.w3.org/2025/01/30-css-irc#T16-29-03<br> <emilio> ... a design for a particular font the os might be higher and not really respect those lines<br> <emilio> ... yet in latin scripts there's an x and cap height and they're typically relevant<br> <florian> q-<br> <emilio> ... and in some scripts those are not defined<br> <astearns> ack r12a<br> <emilio> r12a: I'm starting to think that what we're hoping to do here is to define generic lines for fonts or possibly define generic lines per script and once we have defined what lines are appropriate we can start using those<br> <emilio> ... it might be better to start with "what are the functions for which we want to use these"<br> <ChrisL> q-<br> <emilio> ... e.g. what is the line to use to align first-letter?<br> <emilio> ... what is the the line to align with a particular point of the page<br> <emilio> ... rather than trying to create some generic repository of lines, start from the use<br> <emilio> fantasai: that's why I think we need to look at the line for alignments<br> <emilio> r12a: didn't see that reflected on the discussion<br> <emilio> astearns: we have things people would want to use lines for today, but for some scripts we don't yet have the places where they'd like to use their own layout-affecting lines<br> <ChrisL> q+<br> <emilio> ... so I think in creating this registry we will find things that need to be added<br> <emilio> ... to create layout in less popular writing-systems<br> <emilio> fantasai: if we focus on the thing that everybody needs to do (align things to other things and spacing) I think we'd get most of the answers we need<br> <astearns> ack ChrisL<br> <emilio> ChrisL: Is this registry a temporary thing while we propose it to ?? or are we going on our own direction<br> <emilio> astearns: this was discussed, we want to nag opentype to do this thing<br> <emilio> fantasai: and we're not defining a technical feature, just collect this information<br> <emilio> ... which would provide info on what keywords we add and metrics we need<br> <emilio> ChrisL: once we have it would be good to give a heads up to the right people, even if it's not really ready yet<br> <emilio> astearns: so proposal is to start collecting these layout affecting lines in various typographical systems<br> <emilio> ... and that'd be a joint effort between CSSWG andf i18n?<br> <ChrisL> q+<br> <r12a> pretty picture: https://r12a.github.io/scripts/arab/ug.html#baselines<br> <emilio> r12a: I think sounds fine if people can find the time<br> <emilio> fantasai: florian and I can find the time<br> <astearns> ack ChrisL<br> <noamr> In hebrew the equivalent of the x height is the Mem height (ם). I think this information is openly available for some languages?<br> <emilio> ChrisL: I was thinking that the various gap analysis for different languages would be useful<br> <emilio> ... so that collects the experts from one language and [missed]<br> <fantasai> noamr, awesome. I've been wondering about what it's called. :)<br> <emilio> r12a: I think it'd be cool to collect an initial set of what we need first<br> <emilio> ChrisL: agreed<br> <emilio> RESOLVED: Start a shared registry on layout-affecting lines as a joint effort between CSS and i18n<br> <noamr> fantasai: I think my grandpa defined some of this stuff for Hebrew decades ago :)<br> <dbaron> s/fantasai:/fantasai,/<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/11384#issuecomment-2625000031 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 30 January 2025 16:38:26 UTC