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> 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>
> http://www.antenna.co.jp
> http://www.cas-ub.com
> http://blog.cas-ub.com
> twitter @TokKoba
>
>
>