RE: [css3-writing-modes] auto and upright for text-orientation

> > 1. "auto", which allows UA-dependent implementation of glyph orientations.
> 
> I don't think we should not be defining property values simply to paper over differences
> in implementations done before the spec is finished.

The reason behind is different.

If I understand correctly, there are some cases where CSS doesn't define exact behavior. The definition of line break opportunities and word boundary for capitalize are examples. I think glyph orientation falls into the same category.

> I don't see what defining "auto" achieves.

What I'm thinking is something like this:

The glyph orientation is UA-dependent. It is suggested that characters in the range of U+0020 to U+007E are sideways, and CJK characters are upright. This specification does not suggest orientations of other code points nor what exactly CJK characters means.

The latter sentence is optional, I just thought the WG may prefer to add some suggestions, but I'm fine with or without.

> > 2. A value to force upright rendering orientation regardless of the
> > code point (the one John proposed before.)
> 
> I think it would be best if you listed the wording you're proposing for this.

Ok, how about this:

UA renders each glyph upright. Vertical metrics and vertical alternate glyphs are used if available. Whether to enable or disable other font features such as ligatures is UA dependent. The behavior when vertical metrics is missing is also UA dependent.

Note: Vertical alternate glyphs may contain rotated glyphs and therefore this value may result in visually sideways glyphs depending on code points and fonts.
Note: This value may typeset some scripts incorrectly.

> > We have been discussing on glyph orientations for the last 11 months.
> > During that, a couple of companies have publicly mentioned the
> > availability of e-book readers in the 2nd half of this year; from late
> > summer to by the end of this year. Several companies have provided
> > evaluation versions of their e-book readers to publishers, and some
> > early publishers have established contents creation rules based on
> > existing implementations. A government project to produce
> > 60,000 e-books has started. It is expected that Japanese HTML/CSS
> > e-books will be available in the order of tens of thousands by the end
> > of this year.
> 
> This is an EPUB issue, not a CSS issue.  If EPUB defined behavior for this then that
> continues.  If they breezed over issues related to this property and ignored a difficult
> problem in the interest of stamping "done" on their spec, that's their decision.  Our goal
> here is to come up with something reasonable that assures consistency across
> implementations.

I don't think so in a few points.

First of all, I said "e-books." They are not all EPUB. There are other formats than EPUB that use W3C specifications as rendering technologies. There are some web sites that show e-books on browsers. Actually, I count only less than half of e-books are EPUB.

Second. It's neither IDPF nor EPUB WG who's in trouble today. Who really in trouble are authors, users, and vendors, including some W3C member organizations. They're not in trouble with packaging formats, they're in trouble with rendering, and there's no one other than CSS WG who can resolve this issue. This is our issue, not for EPUB WG, but for authors, users, and vendors.

And the last and the most importantly, as far as I talked to a lot of people in Japan, nobody thinks the perfect level of consistency in glyph orientations is important enough to delay the spec or products for a year or more. People are surprised when I talked Word and PowerPoint differs from each other, or Windows and Mac, they just don't notice.

Glyph orientations may be only 98% consistent for major use cases if we make it UA dependent. It could be improved to 99% if UTR#50 was properly defined. Even by 1% improvement, I agree it's nice to have. Supporting minor use cases is also nice to have. But I don't think requiring that 1% is a good thing to do, especially given it requires a lot of work. Writing Modes Level 3 is the first version, and I don't expect the first version being perfect. We can keep improving it.

This is an issue of defining the level of consistency we as CSS WG should try to achieve in Level 3, and at this point, I see many people not agreeing with requiring UTR#50 in Level 3.

> There is no existing interoperable behavior here.  Simply saying "implementations don't
> change" doesn't make much sense at all.  If implementation A and B don't do the same
> thing, one or both of them will need to change.

I agree with the first sentence. I don't understand the second sentence, sorry about that, and I disagree with the last sentence.

If implementation A and B don't do the same thing at the level most people don't care, neither of them need to change. That is what's happening today for line break opportunities, and I think glyph orientation is the same kind of issue. If some authors really care, they can add tags to make it even more consistent.


Regards,
Koji

Received on Wednesday, 9 May 2012 22:39:35 UTC