Re: Tokyo/SF mini conf call minutes 2/15

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