RE: [css3-writing-modes] A report from a meeting w/Japanese publishing group

Kobayashi-san and I have different opinions here.

A bit of history in this area; before the Unicode, the rule which glyph to show upright and which sideways by default was pretty clear, and it was interoperable across applications and OSes. In late '90, Unicode was introduced, and we found out that the logic we used to no longer works in Unicode. Most software I know went to rely on font information to solve the problem, but since many did it slightly differently, we lost interoperability.

Now, during the development of CSS Writing Modes, fantasai and John pointed out that the interoperability of glyph orientation is important. I have forgotten of its importance for decades but agree that it is important, so we're trying to solve the problem.

In addition, CSS has different requirements from those applications (wants to split runs before font is determined,) so we can't use similar method. It's a bit of challenge, but I think it's very valuable to solve the issue that way, since it gives interoperability across applications. Today, for example, Word and PowerPoint are not interoperable in this area.

The Writing Modes module defines two things:

1.    The default orientation of each code point

2.    How authors can change its default orientation by applying styles

We're trying to solve 2nd issue in CSS Writing Modes, and 1st issue in Unicode.

The default orientation is hard to solve though, especially for symbols and punctuation since you can find both (upright and sideways) usage in real world, and either way we define, we could find weird cases where the opposite works good. So it's matter of which use cases you would put priority on, and that makes the discussion hard.

Kadokawa is a big professional company, so they can develop a tool to wrap characters whose default orientation are differ from their expectation with <span>s and apply text-orientation property, so they just want the spec/behavior stable early.

But still we need to come up with some reasonable default orientation for other, regular authors, and that's what people working on UTR#50 are doing.


Regards,
Koji

From: bradyduga@gmail.com [mailto:bradyduga@gmail.com] On Behalf Of Brady Duga
Sent: Monday, January 16, 2012 4:46 AM
To: koba
Cc: MURATA Makoto; www-style@w3.org
Subject: Re: [css3-writing-modes] A report from a meeting w/Japanese publishing group

Thank you for the detail on all these items. It's very helpful for me in understanding the issues. My final comment was referring to the original message in this thread. Specifically:

"They also mentioned that the glyph orientation in vertical text flow is one of the issues they are looking into, which is one of the hottest topic in writing-modes[3] and UTR#50[4]."

And

"It looked to me that they were a bit surprised that many symbol and punctuation glyphs used in their contents appear in sideways in today's implementations, more than in other existing digital publishing platforms."

On Sun, Jan 15, 2012 at 2:57 AM, koba <koba@antenna.co.jp<mailto:koba@antenna.co.jp>> wrote:
> If I can just restate the issues in a very simplified manner to see if I am
> correct in my understanding of the problem:
>
> 1. In a vertical text flow, some glyphs may need to be rendered differently
> then in a horizontal flow (rotated or replaced)
Yes. Moreover, some characters may only be used for horizontal writing
mode, and some other characters may only be used for vertical writing
mode.

For example, please refer to:
http://www.w3.org/TR/jlreq/
3.1.1 Differences in Vertical and Horizontal Composition in Use of Punctuation Marks

> 2. This cannot always be determined algorithmically
Yes.

Antenna House Formatter determines the direction of glyph by very
heuristic method.

> 3. The writing modes module addresses this with styles to determine glyph
> orientation
This is difficult question. CSS writing mode can solve the issue only
partially.  For example, it can specify to rotate, but can not specify to
change (replace)  the shape of glyph.

The second problem is the behavior of graphics symbols (non-character)
are to be determined one by one.

I do not expect CSS writing mode module to solve everything.

> 4. Currently, glyph selection is a function of the underlying font engine
> (eg 'vert' gsub table in OpenType), not CSS (or Unicode)
>
Yes. The problem is some fonts do not supply such information as 'vert',
but in the future there will appear more intelligent/good fonts.

> Is item 4 the problem under discussion in the blog post?
Partially, yes.

But my overall intention is different.

Unicode TR#4 tries to classify every characters into U, S, SB, T.
I supose it is impossible to classify some characters to one class. For
example, latin alphabet is U for 2.3.2.b.1-i fig. 24, but S for 2.3.2
b.1-ii fig.25.

Please refer to 2.3.2 Major Differences between Vertical Writing Mode
and Horizontal Writing Mode.

As a result, the behavior of latin alpabet is U or S, it depends on
author's intent and writing style. It is not appropriate field for any
standard. Though, engineers may need default behavior for latin
characters.

My propose for Unicode TR#4 will be such that it determine minimum
set of characters for which glyphs are to be rotated or for which the
chape of glyphs are to be replaced.

> Is that the  original issue Koji raised?
I do not understand which issue you refer.

> I apologize if these are obvious questions, I
> am having a little difficulty following the discussion - the Google
> Translate page of the blog post was surprisingly good, but I think some of
> the important details were lost.
No problem. I hope my explanation is good.

Regards

Tokushige Kobayashi

--
koba <koba@antenna.co.jp<mailto:koba@antenna.co.jp>>
http://www.antenna.co.jp
http://www.cas-ub.com
http://blog.cas-ub.com
twitter @TokKoba