[CSSWG] Minutes and Resolutions Tokyo F2F Wed PM: Japanese Layout Task Force Joint Meeting


   Discussed various tricky issues that will feed into various CSS drafts, including:

   - Effect of ruby on line-height
   - Japanese line breaking rules and their variation
   - Brief interchange on justification
   - Using 'letter-spacing' for tracking and tsumegumi
   - punctuation-trim, fonts, and fullwidth/halfwidth identities of punctuation
   - Glyphs and implementation of text-emphasis dots
   - Hanging punctuation

====== Full minutes below ======

Meeting: CSSWG and JLTF Joint Meeting 2009 Tokyo F2F
Scribe: Steve Zilles


   CSSWG is joined by
     - Kobayashi-sensei, master of Japanese typography
     - Kobayashi-san, Justsystems, chair of JLTF
     - Yasuhiro Anan-san, Microsoft
   The current JLTF draft is
   Official JLTF draft is

Review of Paged Media

   fantasai offers to discuss the specs that are relevant to the JLTF
   fantasai: there are 3 relevant specs plus GCPM
   fantasai: the first spec is Paged Media that covers the description of the
             page, its margins, headers and footers, ...
   fantasai: there is a default page, plus pages for first, left and right
             pages and a set of named pages.
   fantasai: the content has to fit inside the page box else it gets clipped
   fantasai: the current Paged Media model does not have a concept of "spread"
             (that is two facing pages together), that is a topic for a future
   <fantasai> Note to self: css3-page should not clip to the page area, but to
              the padding box of the page box

Line Height and Ruby

   K-san: what about line-stacking-strategy?
   dbaron: Some of the goals of the line box module are contradictory; e. g.,
           since an author cannot really know what font (and other) resources
            will actually be used.
   dbaron: the current line stacking rules are not ideal for Western topography
           and they certainly do not consider things like Ruby annotations.
   Discussion of line-stacking-strategy
   dbaron: We might want different options for what gets considered
   Anan-san, Kobayashi-san: ruby above the first line spills outside the kihon
   Steve: Do we flag this as an issue to come back to later?
   fantasai: yes. We don't have anyone working on a module that involves this.
             Nobody will be able to fix it within the next 6 months
   K-san: figure 37 of the current JLTF draft shows the ruby outside the
          Kihonhanmen on the first line.
   dbaron asks if the ruby crosses the midline between two lines
   yes, it does
   K-san: The line gap is usually smaller than the line width, e.g. 2/3
   Kobayashi-san: Ruby is usually 1/2 the size of the font size
   K-san and K-sensei: the ruby chars are set without and "leading" between the
                       base characters and the ruby characters; this assumes
                       internal leading in the fonts.
   Anan-san: The current MSFT implementations grow the line-height to
             accommodate ruby, but this is not correct
   Anan-san: the ruby characters should fit within the line-gap
   Steve: One reason that line-stacking-strategy was created was to allow a user
          to specify whether he wanted to guarantee that no overlap (the CSS
          rule) or he wanted to guarantee consistent spacing between lines
   Steve: Since CSS tries to guarantee no overlap of lines, it would be
          reasonable to have the Ruby chars taken into account in determining
          the actual line height.

Continue Review of Paged Media

   fantasai: CSS3 Page module covers margin boxes, their position, their content
   fantasai: for styling the boxes the many of the normal CSS properties can be
   fantasai: page numbers can be inserted
   fantasai: various paper sizes can be selected
   fantasai: the current rules in Paged Media select the paper size, and
             determine the page area by setting values for the margins. This
             does not guarantee a specified numbers o lines or line lengths
   fantasai: this morning we proposed that Paged Media would allow explici
             setting of the Width and Height using the rules of CSS2.1
             section 10
   fantasai: this allows explicit setting of the Kihonhanmen size in EMs and
             centering the resultant area on the paper.
   fantasai: named pages provide a kind of styling template that can be applied
             to different sections of the content (using selectors)

CSS3 Text and Line Breaking Rules

   fantasai: The second document is CSS Text which is, itself, not a complete
             module (it is an extract of a prior module.
   fantasai: it covers white space control, line breaking and word boundaries.
   fantasai: We know that Japanese has its own line breaking rules which are
             different than western text rules.
   fantasai: There are some named rules for controlling line breaking
   Anan-san: Appendix 3 of the JLTF document has an explicit description of
             line-breaking for Japanese based on character classes
   Anan-san: There are at least two sets of rules for line breaking: basic ones
             such as the Unicode line breaking rules
   Anan-san: and stricter rules that cover a more complete set of cases, such
             as those in Appendix 3 of the JLTF report
   Anan-san: for example, Firefox does a better job of handling rules than some
             other implementations
   Anan-san: Microsoft Word adopted an earlier version of the rules in JIS4051
             and, therefore, allows some breaks that would not be expected.
   fantasai: for western text, there are 2 options, break where allowed by the
             language and break anywhere (including inside a word)
   fantasai: for japanese, there are also two options: loose and strict, with
             strict being the default. Specifying what these mean, however,
             is a problem.

   Murasaki-san: breaking before small kana is fairly common in Japanese
   K-san: There are three levels: newspaper level, magazine level, book level
   Murakami-san: Many books use normal level, not strict level
   <fantasai> Kobayashi-san discusses house rules
   <dbaron> Perfect line breaking rules for English probably don't exist either.
            Consider finding the allowed breaks in
   K-san: There are also "house rules" used by a particular publication house
   K-san: we do not, however, need to have rules at that level of detail
   K-san: Although some implementations use house rules, we can still define
          some base levels
   Murakami-san writes: loose, normal, strict
   K-sensei: there are 4 options: loose, normal, strict and very-strict
   very-strict forbids breaks before small-kana, the sound lengthen mark and
     decoration marks.
   K-san: almost all publications do not not use very-strict
   From now on we will use levels 1,2,3 and 4 where 4 is most strict and 1 is
     least strict
   Level 4 is not often used.
   K-san agrees that the JLTF will define the rules for the 4 classes of
     line-breaking rules.
   fantasai: could we also get a textual summary of the rules that would give
             an author an sense of what to expect without tracing through
             the table?
   fantasai: and which level is the default level?
   K-san/K-sensei: level 3 is the default
   fantasai: do these breaking rules also cover numbers and foreign language
   fantasai: for example, there is a property value that applies to latin text
             that allows breaking anywhere within a word.
   Steve: This occurs, for example, in Korean usage.
   K-san/K-sensei: Japanese link-breaking does not allow line-breaking inside
                   a word.

   Resuming after a break

   fantasai: The WG thanks the JLTF for agreeing to provide us guidance on line
   <dbaron> We also need to keep the line-breaking compatible with English. :-)
   <ChrisL> dictionary-based English hyphenation ftw!

CSS3 Text and Justification

   fantasai continues summary of CSS3 Text
   fantasai: text-wrap gives control over chuncks of text beyond the word level
   fantasai: Alignment (horizontal) controls aligning to start, end, center,
             justify and control over last line as well
   Anan-san/K-sensei: there are cases in Japanese in which a single line is
   fantasai: in CSS, a single line is also a last line.
   fantasai: because a window can always be resized, one cannot guarantee that
             a "single line" will fit within the window so ti would be justified
             in two or more lines unless wrapping is forbidden
   Murakami-san: if there is only one character on the last line where is it
                 placed with Justtify?
   <fantasai> Issue: text-align-last: justify center;
   <trackbot> http://www.w3.org/Style/CSS/Tracker/issues/97

   fantasai: there is control over which space adjustments are used for
   Anan-san: How does "inter-graphemic" apply to east asian languages?
   Many: it is there primarily for scripts like indic scripts that have grapheme
   Anan-san: Japanese characters with diacrictics for voicing do form a grapheme
   <fantasai> Issue: If the same about of extra space that is being used between
              full width characters (for justification) is also put between half
              width characters, then the alignment of two half width characters
              with one full width character will be broken.
   <trackbot> http://www.w3.org/Style/CSS/Tracker/issues/98
   <dbaron> (I asked a few minutes ago what happens with halfwidth characters
            and justification.)
   <fantasai> ISSUE: make sure justification allows not justifying between
              various bits of punctuation
   <trackbot> http://www.w3.org/Style/CSS/Tracker/issues/99
   Anan-san: the vertical kana repeat mark upper half should not be split from
             the lower half mark during justification
   jdaggett: Implementations that use the typographic data in a font should
             not be considered non-conforming

CSS3 Text and Tracking, Letter-spacing, and Tsumegumi

   fantasai: there is spacing that does "tracking"
   fantasai: Word spacing does not (should not) apply to the Ideographic Space.
   Anan-san: Tsumegumi controls the reduction of spaces between characters up
             to the collision of the glyphs
   jdaggett: letter spacing is problematic becuase when kerning is involved you
             want a multiplicative property rather than a adative one.
   fantasai: the current design has a percentage of the letter space; what is
   jdaggett: what is desired for letter spacing is to add/subtract a percentage
             of the character advance rather than a fixed amount between all
   <fantasai> Issue: percentage should be wrt character advance, (before or
              after kerning?)
   <trackbot> http://www.w3.org/Style/CSS/Tracker/issues/100.
   Note that kerning changes the advance between certain characters
   <fantasai> Steve says after kerning
   fantasai: that would create uneven spacing in, e.g. "milling"
   Steve: the specification of these properties should not require the
          implementation of bad typography; it should allow an implementation
          to do "better than a minimum level"
   <dbaron> fantasai, so why are you introducing a new feature (% letter
            spacing) if you don't think it does something reasonable?
   <fantasai> dbaron, we're missing a measurement that accounts for the
              character advance width
   <fantasai> dbaron, so I picked a way to reference the advance with of a space
   <fantasai> dbaron, right now you can reference ems
   <fantasai> dbaron, but that gives weird results if you compare a
              narrowly-designed font with a widely-designed one
   fantasai: with evenly spaced tsumegumi, how do measure the space added or
   discussion: the tracking value is not applied to the full character advance,
               but (in an as yet undefined way) to the space between characters
               after kerning is done
   Anan-san/K-sensei: the tsumegumi can be specified in ems because the amount
                      is typically a percent of the font size.
   Anan-san: the letter-spacing applied to cjk would usually be too much for
   Anan-san: so you may need a way to separate
   Anan-san/K-sensei: when a line has mixed latin and ideographic text the
                      space adjustments are not uniform across the line but are
                      different for the different kinds of text
   ChrisL: rather than have different letter spacing values for each language,
           it would be better to markup each section of text with its language
           and use selectros to apply differn letter spacing values to the
           different spans
   K-san: I like ChrisL's solution because it also handles cases where in a span
          things like the font-size is changed and the letter spacing needs to
   fantasai: but, there will be cases where the foreign text is not marked up
             and there needs to be a way to deal with those cases.
   K-san: tsumegumi like this is usually only used for short bits of text in
          large fonts, such as headings
   K-san: so this solution should be sufficient
   fantasai: trying to use Unicode ranges to control the letter-spacing is not
             a good idea because it does not deal with punctuation characters

CSS3 Text and Punctuation Kerning

   fantasai: punctuation-trim property - this handles the conversion of full
             width punctuation to half width
   jdaggett: asks how this interacts with information in kerning tables in the
   jdaggett: is this in addition to or instead of kerning?
   It is really hard to know if such kerning data is in the font which makes
     it difficult to tell whether the lower level engine (e.g. Uniscribe) will
     do the transform or not.
   Anan-san: Also, the same Unicode code-point is different depending on what
             language the font was designed for

   K-san: Three issues interrelated: where to break the line, where to position
          characters by default, where to adjust (justify) the line
   K-san: There are several places to solve the issue. The CSS level, the font
          level, OS-level
   K-san: Justsystem and MSFT, between ours the handling of parentheses is
          slightly different
   K-san: CSS should explicitly define its position, this will be helpful to
          other parties

   Anan-san: Technically we can define the pairs at the font level, but once
             you put the characters in the line you may want different results
Scribe: fantasai
   fantasai: so do we assume the font is wide or not?
   no real answer
   Murakami-san: Antenna House implements punctuation-trim
   Murakami-san: It applies only to CJK fonts
   Murakami-san: That have fixed-em width
   Murakami-san: full-width brackets only
   Murakami-san: Not applied to narrow punctuation
   Murakami-san: Interaction with kerning is not a problem.
   fantasai: how do you know if it's full-width?
   Murakami-san: MS Mincho has full-width fixed-width glyphs for punctuation
   Murakami-san: But MS P Mincho has narrower glyphs for Japanese punctuation
   Murakami-san: Antenna House punctuation-trim controls MS Mincho, but not
                 MS P Mincho
   jdaggett: With a proportional font, the "half-width" characters are
             proportionally spaced
   jdaggett: whereas in a full-width font they are not (end of summary of P
             vs not P)

   K-san: In Unicode, fullwidth punctuation marks usually have half-width
          default size
   K-san: in the JLTF document
   K-san: In Japanese typsetting tradition, especially hot-metal era, usually
          the punctuation marks are 1/2 em size
   K-san: So when the punctuation mark need to be 1em we add 1/2em space
   K-san: Steve and us made 6 hours discussion on this at the last meeting
   K-san: And we decided to describe every punctuation mark as 1/2 width size
          as a default
   K-san: And with some other half-width space added
   K-san: Our document is based on such an agreement
   Steve: The reason that the discussion took 6 hours was primarily because
          there were several kinds of terminology being used in different
          parts of the document
   Steve: this contributed confusion on the part of the non-Japanese speakers
          who were tyring to read the document and weren't sure how many
          different principles were used
   Steve: So we picked one that made sense to the ppl writing the document and
          use that consistently

   jdaggett: Fonts, and OpenType especially, have many ways of doing the same
             thing. E.g. kerning
   Murakami-san: professional Japanese fonts use fullwidth punctuation
   discussion of P Gothic black magic
   Anan-san: You can do pairs kerning in Uniscribe, but it's
   Anan-san: ...
   jdaggett: FF uses Uniscribe for a lot of text rendering
   jdaggett: for desktop, it's ok
   jdaggett: for mobile device, ehhh
   Murakami-san: Meiryo also has fixed full-width punctuation
   Murakami-san: even though Latin is proportional

Scribe: Steve
   K-san: the JLTF is willing to consider having levels w.r.t the
          punctuation-trim as will be done for line-breaking
   fantasai: the CSS WG has to explain the requirements for punctuation-trim
             in a way that implementers can implement it.

CSS3 Text and Text Decoration

   fantasai: underline position does not really support Japanese because the
             convention in Japanese is to use underlines on horizontal text
             and before-edge lines in vertical text
   K-san: the spacing of the "underline" relative to the character box is up
          to the implementation; they may or may not be useful information
          for this in the font.

   fantasai: text-emphasis
   K-sensei: Kendots should be used only for vertical text
   K-san: there are two code point for the dots; it is the context of usage,
          horiz or vert, that determines which glyph is used, independently
          of which code point is used to represent the dots
   Note, also, that the "dots" do not occur in the content, they are generated
     by CSS UA.
   K-san/K-sensei: w.r.t. middle dot or the accent character, the normal size
                  of the full width character is used, but 1/4 em is trimmed
                  off the top and bottom of the character in a dot above the
                  character or from the left and right of the character in a
                  dot on the before edge.
   K-sensei: Ruby and dots will not be used together; therefore dots should be
             ignored (for Japanese) if specified with ruby.
   K-sensei: if text with Ruby annotation is to be emphasized, it can be done
             by using brackets before and after the emphasized text

CSS3 Text and Hanging Punctuation

   fantasai: hanging-punctuation currently has 3 values
   <shinyu> http://lists.w3.org/Archives/Public/www-style/2007Oct/0204.html
   Murakami-san presents his proposal
   Start allows the bracket to occur prior to where the first non-punctuation
     character is to occur
   End does the same for the last line
   end-edge allows hanging on end of every line
   ChrisL: is there a use case for "start-edge" in analogy to "end-edge"
   fantasai: if there is an indent of the first line, then hanging means into
             the indent space, not the content area.
   fantasai: what punctuation characters are allowed to hang with "end-edge"?
   Murakami-san/K-sensei: only 4 characters (stop, ideographic stop, comma and
                          ideographic comma) can hang with "end-edge"
   Murakami-san/fantasai: for "start" the punctuation that hangs are opening
                          brackets and quotes; for "end" they are ending
                          brackets and quotes.
   It was agreed that there is no Japanese use case for "start-edge".
   <fantasai> end should have end-auto functionality
   <fantasai> forcing the punctuation to hang should be 'force-end'
   K-sensei: there is a requirement for a "forced-end" value which forces the
             final stop to be hanging and then justifies the chararacters that
             remain on the line.
   fantasai and Murakami-san: Replace "end-edge" with "end"; replace "start"
                              with "first" and "end" with "last"
   This renaming leaves "force-end" meaning that the hang is forced on any
     line that ends with one of the four punctuation symbols that can hang
     with "end"
   Murakami-san suggests maybe 'end' might be confusing with 'forced-end' for
     Western typographers
   Western typography typically only hangs the hyphen, and it's not common
   Suggestion: 'allow-end' 'forced-end'
   Other suggestion, need 'hypens' value? since Japanese doesn't hang hyphens
   fantasai: suggests that "end" be called "allow-end" to make it relationship
             to "force-end" to be more clear.

At 6:10, the meeting adjourned for the day.
<RRSAgent>  http://www.w3.org/2009/03/04-css-minutes.html

Received on Monday, 9 March 2009 04:21:47 UTC