- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Sun, 08 Mar 2009 21:21:03 -0700
- To: www-style@w3.org
Summary:
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
Introductions
-------------
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
http://www.w3.org/2007/02/japanese-layout/docs/aligned/japanese-layout-requirements-en.html
Official JLTF draft is
http://www.w3.org/TR/jlreq/
Review of Paged Media
---------------------
fantasai offers to discuss the specs that are relevant to the JLTF
requirements
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
version.
<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
hanmen
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
used.
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
bis(4-chlorophenyl)-1,1,1-trichloroethane
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
text?
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
breaking
<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
justified.
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
justification:
Anan-san: How does "inter-graphemic" apply to east asian languages?
Many: it is there primarily for scripts like indic scripts that have grapheme
clusters.
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
wanted?
jdaggett: what is desired for letter spacing is to add/subtract a percentage
of the character advance rather than a fixed amount between all
characters.
<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
character
<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
subtracted?
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
latin
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
change.
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
fonts.
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
performance-expensive
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