- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Thu, 17 Feb 2011 14:59:39 -0800
- To: Koji Ishii <kojiishi@gluesoft.co.jp>
- CC: John Daggett <jdaggett@mozilla.com>, Stephen Zilles <szilles@adobe.com>, MURAKAMI Shinyu <murakami@antenna.co.jp>, "www-archive@w3.org" <www-archive@w3.org>
On 02/14/2011 11:32 PM, Koji Ishii wrote: > 17:00 15-Feb-2011 DST (SF) > 10:00 16-Feb-2011 JST (Tokyo) IRC log: http://krijnhoetmer.nl/irc-logs/css/20110216 Also reproduced below. See http://lists.w3.org/Archives/Public/www-archive/2011Feb/ for an archived copy of this message. Tokyo/SF CSS/i18n discussions ============================= Topic: Inline-level Alignment http://dev.w3.org/csswg/css3-writing-modes/#inline-alignment SteveZ: One is, when we revised CSS2.1 spec last fall, I did some homework. We were figuring how to align inlines in the linebox and where to place the half-leading SteveZ: The conclusion that we drew from that, and is in the CSS2.1 spec now, is to use the stypo ascender and stypo descender and the win (sp?) ascender and win descender if not present. SteveZ: Defining central baseline as halfway between the two seems to make sense. SteveZ: but there is a caveat SteveZ: There is no good source for what the embox is. SteveZ: Adobe has an ideographic baseline in their fonts, which they use for alignment. SteveZ: They said to use the ideographic baseline as the bottom of the embox SteveZ: In Adobe fonts this is usually -120, since 0 is alphabetic baseline SteveZ: That was the input I got from Adobe SteveZ: Suggestion to put a note, similar to the note that's in the CSS2.1 spec for inline positioning to determine what ascender and descender to look at, SteveZ: And put suggestion for using 12% down from alphabetic fantasai: Don't all fonts have ascender/descender info? SteveZ: Pretty much all fonts have alphabetic baseline SteveZ: ... this is suggestion on what to do if baseline tables are missing Koji talks about some really weird fonts with zero descender SteveZ: Adobe and MS have fixed fonts as some of these issues have come to light. Wouldn't trust Windows 3.1 heuristics today. -!- jdaggett has joined #css fantasai: If ideographic baseline is better than descender, then we can suggest using that if it exists fantasai: and fallback to descender fantasai: I don't think we should use -120 instead of descender fantasai: is ideographic baseline the same as the bottom always? SteveZ: I think it's defined as the bottom, but I'll take an action to check. SteveZ: Nat McCully on the Adobe InDesign team sent me the name of the ideographic baseline that should be accurate if it exists. SteveZ is looking this up, should report back exact name soon. <kojiishi> http://www.microsoft.com/typography/otspec/baselinetags.htm Koji describes his microsoft.com link to baseline table keywords fantasai: Ken Lunde talked about the ICF lines. fantasai: Basically, the embox is the design space for the glyph fantasai: but the glyph ink rarely extends to the full area of that space fantasai: the ICF box is the area inside which the glyph is drawn fantasai: It is slightly smaller than the embox. fantasai: Depending on what you're doing, it is sometimes better to do baseline alignment to the ICF box edges <kojiishi> The link above says "The ideographic character face (ICF), also known as the average character face (ACF), specifies the approximate bounding box of the full-width ideographic and kana glyphs in a CJK font." SteveZ reads from an email SteveZ: The ideo is the embox bottom; idtp is embox top (these are baseline names) Koji: Question then is how much do these values differ from ascender and descender, or are they identical. fantasai: I can definitely update the spec to reference these baselines, and then use ascender/descender if they are missing. SteveZ: Also copy note about ascender/descender in OT fonts from CSS2.1 ... SteveZ: So for central baseline you want to add half of design space to ideo baseline fantasai: idtp doesn't seem to be very common, because it's not used for baseline alignment fantasai: ideo seems to be in the baseline table, even though it's supposed to be the same as descender, because it's used for baseline alignment fantasai: but since idtp is usually missing and would have to be replaced with ascender, wouldn't it make more sense to use ascender + descender? fantasai: after all, we are synthesizing a baseline (the central baseline); using any metrics should make sense. SteveZ, reading from some document: The bottom of the ideographic embox and the value of stypo descender are supposed to be the same. SteveZ reads an example from the document fantasai: So why not use ascender+descender? We have to use it for alignment anyway SteveZ: Should use romn baseline, first SteveZ: Then use ascender+descender fantasai: but you need ascender+descender to do leading anyway SteveZ: ... SteveZ: The win ascender and win descender are designed for clipping, so a reasonable fallback from stypo values, but not really the same thing. fantasai: So, if you have romn baseline, but no ascender/descender info, what do you do about leading? SteveZ: Well, let's write up the best we have, and then have jdaggett look at it because he as to deal with it, and he'll tell us if we're wrong. fantasai: Well this looks like fun. SteveZ: Remember, font is a four-letter word beginning with f. Koji describes fonts with ascenders and descenders that cross out of the embox. SteveZ: I think what we want to say is that the ascender and descender that's related to the embox of the font, not necessarily of any individual character, is what we want. fantasai: Zapfino is a commonly-given example of that kind of font fantasai: Actually, I often write like that when I'm writing letters. Koji: Your current text says "ascender/descender edges of the embox", so it probably describes well enough. SteveZ: The catch is that people won't realize the other metrics won't do that. fantasai: We can copy over the note, and add a little more info on what the various things represent. Koji: What about the issue on missing alphabetic baseline? SteveZ: Let me ask about that one. fantasai: So, first you'd want to use ascender+descender to find romn, then...? SteveZ: Use 120. fantasai: 12%, in case design space is different fantasai: Ok, so my actions here are to copy over the note from CSS2.1 and add detail about what stypo and win difference are fantasai: Write in romn fallback to ascender+descender calculations fantasai: if zero is not at the bottom, use zero fantasai: and if zero is at the bottom, use 12% fantasai: And find out from font mystics whether this divination technique is valid :p koji has a concern about what 12% is referencing stevez says it references the design space, which scales with the size of the font Koji: So about vertical text SteveZ: In rotated text, the roman baseline is the same as in horizontal text fantasai note to self -- need to write aobut mixed orientation text fantasai: If you're not rotating, then why is there an alphabetic basline? SteveZ: I assume the Latin character is centered left-to-right fantasai: top-to-bottom alignment is an advance width issue, not a baseline alignment issue fantasai: The alphabetic baseline is irrelevant if you're setting text upright fantasai: In the case where the text is upright, you always want to use the central baseline. SteveZ: Some fonts have tables for vertical <murakami> I think characters in text-orientation:upright should be aligned same as text-combine:horizontal with one character. SteveZ: so that's where you ought to start murakami, yes, that would be central alignment murakami, but we have to figure out what exactly that means :) fantasai: So, let me guess here at what the best we can do fantasai: ... fantasai: the ascender/descender values are not axis-dependent, are they :/ fantasai: So, if we have a proper font, and all the text is in that font, we're just creating a stack of emboxes fantasai: that all line up fantasai: And the font is responsible for positioning the glyph within that embox fantasai: and adjusting the advance height to be correct fantasai: Is there such a thing as advance height? <kojiishi> http://www.microsoft.com/typography/otspec/vmtx.htm Koji: It's a vmtx (vertical metrics) table fantasai: So we just make a stack of emboxes using the advance height and aligning the left and right edges of all the emboxes fantasai: And the font is responsible for positining the glyph in that embox using its gpos feature? fantasai: That's if it has all the data fantasai: So if it's missing information, then we have to figure out what it's missing and substitute in? Koji: so we probably want to follow Murakami-san's suggestion to match text-combine fantasai: How do you know if gpos information is missing for vertical? SteveZ: gpos table is missing? but it's used for other things fantasai: We could check for vert feature SteveZ looking at gpos table info SteveZ: "Positioning glyphs with TrueType 1.0" and it shows horizontal and vertical metrics example <szilles> http://www.microsoft.com/typography/otspec/gpos.htm <kojiishi> http://www.microsoft.com/typography/SpecificationsOverview.mspx SteveZ: But I don't think we want to get into stuff like gpos SteveZ: The diagram is nice though fantasai: We can link to it fantasai: "The UA should synthesize whatever metrics are missing to the best of its ability." ? SteveZ: Should be good for now. SteveZ: If we could give better advice we should, to get more consistency. SteveZ: because fonts are so bad, esp. with vertical Koji: text-combine is atomic inline? fantasai: .. I think it's just inline. But behaves like a single glyph fantasai: If it was atomic inline, it would align to margin edge, and width/height would apply to it and stuff. Koji: So the behavior of baseline of text-combine is defined in property itself. Koji: Ok, I think we are good for now. Anything else we want to discuss? SteveZ: Yeah, I think we're good. Koji: Tokyo Workshop, will send email. Koji: For MV F2F, we have agenda for telecon tomorrow Skipping next week's call. Steve and fantasai will be on east coast Meeting closed.
Received on Thursday, 17 February 2011 23:00:18 UTC