Re: example of vertical and horizontal layout of Japanese

Shinyu Murakami wrote:

> > Note how the underline on the URL displays, it's rendered to the left
> > in the vertical layout.  In Japanese text layout this is incorrect, an
> > emphasis line like this should appear on the right.  For Chinese, from
> > what I understand, this is correct however, an emphasis line is drawn
> > on the left.  So if the logical property 'border-after' was used for
> > underlining a particular range of text, the "flipped" version would
> > still need to be changed, it would draw to the left in the vertical
> > text case which would be incorrect for Japanese. Seems like you also
> > need to define precisely what text-decoration: underline means in the
> > vertical case.
> 
> See the definition of the text-underline-position property of CSS3 Text:
> http://dev.w3.org/csswg/css3-text/#text-underline-position
> 
> | Name:  text-underline-position
> | Value: auto | before-edge | alphabetic | after-edge
> | Initial: auto
> |...
> | auto
> |     ... In vertical line layout, if the language is set to Japanese
> |     or Korean, the underline should be aligned as for before-edge.
> 
> Japanese ebook readers that can switch writing modes render underline
> this way.

Ok, that's good, that handles how 'text-decoration: underline' behaves but
this doesn't cover the border-bottom case.  The only way to apply a
color, thickness, or dash to an underline is via border-bottom for
horizontal text.  If you use border-after instead, that doesn't
translate correctly to border-right in the Japanese vertical text case,
it translates to border-left.  In this case, you'll need to specify
border-after (border-bottom) in the horizontal case, border-before
(border-right) in the vertical case for Japanese text.

> Almost all text layout softwares that support Japanese layout can
> switch writing modes (horizontal or vertical) and the underline
> position is automaticaly adjusted, the indents and spaces between
> blocks are writing mode relatively defined. We can use same settings
> for both writing modes and only small refinement is needed.
> margin-start (starting indent) and margin-before (space before block)
> are very natural for us.

The idea of logical layout properties makes sense but the problem is
that in CSS you're trying to retrofit it on top of existing physical
properties. For example, I think a number of properties in CSS3
Backgrounds and Borders would need logical versions, the border-radius
and border-image property sets both appear to require logical
variations.  And other properties appear to need at least additional
values, like 'text-justify', since existing 'text-justify' values don't
make sense for vertical text.

A large page of HTML with horizontal text is essentially a page with a
very large height, somewhat different from the layout of single print
pages. Consider a page like the one below, containing a the text of
Natsume Soseki's "I Am a Cat" (the story of a far more intelligent
species than our own):

  http://www.aozora.gr.jp/cards/000148/files/789_14547.html

What should happen to this page when writing-mode is switched to tb-rl? 
In IE8 you'll see the very *end* of the document, since the text block
is now very wide instead of very tall and the left most part of that
block in view corresponds to the end of the document. Page down won't work,
you'll need to scroll over to the far right, then read by clicking left.

The Azur reader software (http://www.voyager.co.jp/azur/) can view this
document in horizontal or vertical mode but breaks it up into discreet
page chunks with multiple rows of vertical text, such that the page down
key still has meaning.  This is why I suggested before that I thought
"multi-column" support of some sort would be important since the natural
progression of large blocks of text would be unnatural in the vertical
text case.  The exact configuration of columns or rows of text varies by
the aspect ratio of the Azur window, it's only symmetrical stylistically
when the page is closer to square.

Regards,

John Daggett

Received on Monday, 7 June 2010 15:22:18 UTC