RE: [css3-text] script-specific functionality

> Therefore, I suggest removing 'text-trim' from this
> specification and consider addressing the functionality
> nearby to the 'font-kerning' property.

Precisely speaking, the 'text-trim' property is not "kerning". Kerning information is created by font designer and stored in font files, so it makes sense to have it in font specification. This feature is not stored in font file, but is algorithmic spacing control between two character classes, which may add or remove inter-character spaces, so I think here right after 'letter-spacing' is the right place.

The terminology "fullwidth kerning" was chosen because the idea exists only in East Asia, and closed effect in Latin typesetting was kerning, but it may be confusing. I'll think changing it.


> The 'line-break' property lists three values without
> really defining them. Some rules for Japanese and
> Chinese are suggested, but the spec doesn't say how
> to interpret these values in for other languages other
> than leaving it to the UA. The specification must be
> more precise if we want interoperable results.

The list includes East Asian code points only because the feature is needed only for them. We have investigated all possible scripts we can. "A list of code point plus some additions for Chinese and Japanese" means there are no special additions for other languages.

> This line needs some explanation:
>
>  ‘auto’ is equivalent to the value of the ‘text-align’ property
>  except when ‘text-align’ is set to ‘justify’, in which case it is
>  ‘justify’ when ‘text-justify’ is ‘distribute’ and ‘start’ otherwise.
>
> What's the use case and is it worth introducing the interdependency?

It's a nature of 'justify' where alignment for the last line and for the rest are different. I you think about regular justified paragraphs, all lines except the last one should be justified. So, when 'text-align' is 'justify', 'text-align-last' must be 'start'.

> The specification adds this functionality to better control
> justification:
>
>  text-justify: auto none inter-word inter-ideograph inter-cluster distribute kashida
>  word-spacing: 2 new values describing minimum maximum spacing
>  letter-spacing: 2 new values describing minimum maximum spacing
>
> However, microtypography is not mentioned. 
>
>  http://en.wikipedia.org/wiki/Microtypography


I didn't know the terminology, but according to the Wikipedia, it looks like it's our responsibility which methods to use. The 2 new values of letter-spacing allows justification using tracking (the first one in the list). As far as I investigated, even In Design doesn't seem to use other methods, so I think current definition is good enough for most high-end typesetting.

> Do we know what knobs (say) InDesign offers in this field?
> Do they offer values comparable to 'inter-ideograph' and
> 'inter-cluster'

In Design offers switching composer algorithm. If you choose "Japanese composer", it will be 'inter-ideograph'. If you chose "Latin composer", it will be 'inter-word'. I'm not sure if Adobe offers Thai version of In Design though.

> I'm not convinced it makes sense to set these types of
> values in a style sheet. For example, what does it mean
> to say:
>
>  <p style="text-justify: inter-cluster">候选</p>
>
> It seems more natural to describe "justification opportunities"
> between various types of characters.

Hmm...I was thinking this feature defines "justification opportunities" between various types of characters. What did I miss?

Your example doesn't make sense since you're using the value for clustered scripts such as Thai against Chinese, which is not a clustered script.

This is an interesting point though. I'm not sure what the difference between 'inter-ideograph' and 'inter-cluster'. The spec says the difference is "inter-graphemic boundary" or "grapheme cluster boundary". I'm not familiar with the former terminology, nor I can find it in UAX #29.

> It seems that the purpose of 'text-autospace' is to magically
> add space around (say) English text inside Chinese?
> Without there being space characters or markup in the text?
> I suggest we rather encourage the use of markup as this also
> allows the specification of the language. E.g.:
>
>    span:lang(en) { padding: 0 0.5em }
>
>    候选 <span lang="en">foo</span> 候选

Close, but no. It's not about English and Chinese, it's about Latin characters within East Asian languages. It's not necessarily English, just proper nouns or room numbers. I don't expect East Asian authors to mark every Latin characters as lang="en". Also, your styles adds padding to all "en" spans, not only between Chinese and English. I can't see it can replace the functionality.

> Alternatively, OpenType features should be able to handle this, no?

This is very similar to what 'text-trim' offers; define spaces between two character classes. OpenType offers features between two glyphs, but not between two character classes. If it's about glyphs, it's font feature, but if it's about character classes, it's application feature.

> What's a typical use case for 'each-line'?

I'm sorry that I don't have answers to this question. Fantasai?

> 'hanging' may be useful, but the name doens't sound right to me
> -- the result isn't always a hanginge first line. Isn't 'invert' better?

I'm okay with this. Anyone else?

> About the 'hanging-puctuation' property:
>
>  - it seems that an ending quote cannot hang?

Correct. See the picture at Wikipedia:
http://en.wikipedia.org/wiki/Hanging_punctuation

If you have use case for an ending quote to hang, I'd be happy to know.

>  - does the 'force-end' value really force stops/commas to hang? So,
>   unless the comma appears at the content edge, it is moved there?

Yes to the first sentence. I'm not sure if I understand 2nd sentence correctly; if stops/comma appears at the line end, it hangs, even when the line can be formatted/justified without doing so. This is one of the style variations used in East Asia. I haven't seen this style used in Latin script.

> Emphasis marks seem to have much in common with rubies.
> I suggest it is moved to a ruby-centric spec.

Its drawing scheme is similar to Ruby, but it's about text decorations. Ruby is text annotations. Although implementations may share some code to render the two, I think the functionality is different.

> I suggest we remove the 'text-outline' property -- 'text-shadow'
> should cover it.

I don't have answer to this question, sorry again -- fantasai?


Regards,
Koji

-----Original Message-----
From: www-style-request@w3.org [mailto:www-style-request@w3.org] On Behalf Of Hakon Wium Lie
Sent: Friday, April 08, 2011 3:00 AM
To: www-style@w3.org
Subject: Re: [css3-text] script-specific functionality

I wrote:

 > Other properties also have issues, I'll try to go through more.

Here's more.

Overall comment: The draft goes into a great level of detail in some specific areas for some specific scripts, while more general functionality -- which could be useful for more scripts -- is not addressed.

For example, the draft adds functionality for kerning fullwidth punctuation characters (the 'text-trim' property), while the more general issue of kerning is not addressed. I'd rather start by addressing the more general issue of kerning, like css3-fonts does.

  http://dev.w3.org/csswg/css3-fonts/#font-kerning-prop


Therefore, I suggest removing 'text-trim' from this specification and consider addressing the functionality nearby to the 'font-kerning'
property.

--

The 'line-break' property lists three values without really defining them. Some rules for Japanese and Chinese are suggested, but the spec doesn't say how to interpret these values in for other languages other than leaving it to the UA. The specification must be more precise if we want interoperable results.

--

The use case for the 'text-align: match-parent' should be made in the spec.

--

This line needs some explanation:

  ‘auto’ is equivalent to the value of the ‘text-align’ property
  except when ‘text-align’ is set to ‘justify’, in which case it is
  ‘justify’ when ‘text-justify’ is ‘distribute’ and ‘start’ otherwise.

What's the use case and and is it worth introducing the interdependency?

--

The specification adds this functionality to better control
justification:

  text-justify: auto none inter-word inter-ideograph inter-cluster distribute kashida
  word-spacing: 2 new values describing minimum maximum spacing
  letter-spacing: 2 new values describing minimum maximum spacing

However, microtypography is not mentioned. 

  http://en.wikipedia.org/wiki/Microtypography


In particular, changing the widths of glyphs is how many current publications improve justification. Perpaps CSS can play a role by setting optimum/maximum/minimum constraints on microtypography? It may be that this is compatible with extending 'word-spacing' and 'letter-spacing', but I'd rather not extend these properties until we see the whole picture.

Do we know what knobs (say) InDesign offers in this field? Do they offer values comparable to 'inter-ideograph' and 'inter-cluster'. Or perhaps they offer something like 'inter-letter'? I'm not convinced it makes sense to set these types of values in a style sheet. For example, what does it mean to say:

  <p style="text-justify: inter-cluster">候选</p>

It seems more natural to describe "justification opportunities"
between various types of characters.

The 'kashida' value seems specific to Arabic. However, elongation is also used in other languages, though, and I suspec we will see more of it with OpenType features. If we want this value, I suggest we use an English name for it, e.g. "elongation" or "expand".

In conclusion, I suggest we try to get the overview of the microtypography situation before adding/extending text-justify, word-spacing, and letter-spacing.

--

It seems that the purpose of 'text-autospace' is to magically add space around (say) English text inside Chinese? Without there being space characters or markup in the text? I suggest we rather encourage the use of markup as this also allows the specification of the language. E.g.:

    span:lang(en) { padding: 0 0.5em }

    候选 <span lang="en">foo</span> 候选

Alternatively, OpenType features should be able to handle this, no?

--

What's a typical use case for 'each-line'?

--

'hanging' may be useful, but the name doens't sound right to me -- the result isn't always a hanginge first line. Isn't 'invert' better?

--

About the 'hanging-puctuation' property:

  - it seems that an ending quote cannot hang?

  - does the 'force-end' value really force stops/commas to hang? So,
    unless the comma appears at the content edge, it is moved there?

--

Emphasis marks seem to have much in common with rubies. I suggest it is moved to a ruby-centric spec.

--

I suggest we remove the 'text-outline' property -- 'text-shadow'
should cover it.

--

I suggest Elika adds her (impressive list of) affiliations to the draft somewhere.

Cheers,

-h&kon
              Håkon Wium Lie                          CTO °þe®ª
howcome@opera.com                  http://people.opera.com/howcome

Received on Friday, 8 April 2011 03:53:27 UTC