Further analysis on Italics in vertical flow

Results of Opinion Gathering in Japan

If you quickly ask the question to Japanese authors/publishers/printers, most likely the answer is “right edge up.” If you discuss further, the answer is likely to change to “right edge up for Japanese text, but for Latin text, use Italic face or regular slant right edge down if the font does not have the face.” If you then ask what to do when mixed, most likely they will stuck, and it will be a long and complicated discussion.
Here's the aggregated opinions from such a long and complicated discussion as I understand.

  1. Latin text in sideways rotated orientation must appear in Italic face, or regular slant “right edge down” if the font doesn't have the face. Contrast to the common belief that Italic in vertical flow is rarely used, Italic Latin text in vertical flow in Japanese publications is actually quite common.
  2. For Japanese text:
    1. Italic (oblique) Japanese text is not widely used, which matches to the discussion at CSS WG. But books in certain categories, such as light novels, use more often than people usually might imagine.
    2. Ideally, they want to specify both direction and angles, but such use is primarily for graphical purposes and postponing it to future levels is fine.
    3. If we were to pick one, “right edge up” is ideal for Japanese text.
    4. If “right edge up” has any technical challenges, any representation is fine, but a) the applied text should look different enough to distinguish it from other text, and b) a consistent behavior is desired. The motivation here is that, Italic Japanese text itself doesn't have a long history; only 50 years or so, and authors used to use Italic (oblique) to emphasize a part of text from other parts.
      So if the current representation has technical challenges in HTML/EPUB, but there's a way to emphasize part of text, and authors can expect a consistent result across UA, that would suffice their requirements and they can move on to the new representation.

On the other hand, implementers I interviewed preferred UA dependent behavior. I had a group discussion session of publishers and implementers, but the two parties could not reach to a consensus.

Latin text in sideways orientation

iOS6.1.3-iPad-trim

Italic Latin text in vertical flow on iOS 6.1

Although implementers preferred UA dependent behavior, and the group discussion could not reach to a consensus, what to do with Latin text in sideways orientation is not controversial very much.

Japanese authors/publishers want regular Italic; i.e., use Italic face, or “right edge down” if not available in the font. This requirement matches to the required behavior for Latin scripts in vertical flow, such as they appear in tables.

It should not be too hard for implementations either, and is likely to be consistent even without specified. But the fact that iOS 6.1 does not follow the behavior as shown in the picture indicates the needs to define in the CSS specification.

Let’s assume we are happy with “right-edge-down” behavior for Latin text.

Japanese/Chinese/Korean text in upright orientation

italics-vertical2There are 3 natural ways to synthesize Italic for East Asian characters in upright orientation:

  1. Right edge up, as requested by authors/publishers for Japanese text.
  2. Top edge to right, as implemented in Win/Mac Chrome today.
  3. Right edge down, as implemented in IE and Windows today.

Let’s examine each option.

#1 Right edge up has an issue on mixed text; Japanese and Latin characters slant in opposite directions, and may overlap.

The ideal request from authors/publishers is this combination, but this option has following issues:

  1. Given the nature of the Unicode, characters classified as East Asian and as Latin do not match to the general understanding, and sometimes ambiguous. Therefore this option can cause issues in which character should slant which way.
  2. The actually requested behavior is to switch per context, not per character. We could use content language to switch the behavior to make Latin characters are “right edge up” in Japanese context, but we still need to define the behavior when the content language is not East Asian, in which case Latin text must appear in “right edge down.”
  3. Characters overlapping to each other is not a good solution. Having additional spaces to avoid collision is not a good solution for authors/publishers either because it breaks reading rhythm.

So while this option seems to match to what Japanese authors/publishers requested, there are technical issues where it really does not work well.

#2 Top edge to right is one way to implement naturally. If an implementation renders a glyph in upright in vertical flow, existing code will slant the top edge to right, so this behavior requires the least work for such implementations. But this is the only case where slant is applied orthgonally to the baseline, which poses some issues such as:

  1. Characters will overlap with underlines if drawn on right.
  2. top-to-right-with-rubyRuby and emphasis marks will not align if slanted together, or overlap with base characters if they don't. How to handle such cases need to be determined.
    If we want to slant ruby in the same way as the base character, UA needs an additional code to slant baseline.
  3. top-to-right-em-dashOftentimes UA renders a glyph in upright, but the glyph looks rotated sideways because font has a rotated glyph. This results in inconsistent look, since both sideways-rendered glyphs and upright-rendered glyphs look similarly rotated to users, but they slant differently.
  4. Unicode unifications unified many symbols and punctuation characters between Latin and East Asian scripts. This will result in some symbols and punctuation characters used commonly in Latin script drawn upright, or vice versa.
    This, combined with #3 above, can break applying Italic to regular Latin text. Which characters will break depends on fonts’s tables, but EAW=A characters are the possible candidates.
  5. top-to-right-prohibited-charsThere are some code points that are supposed to connect; U+2014 EM DASH, U+2015 HORIZONTAL BAR, and U+2026 HORIZONTAL ELLIPSIS are the examples. These code points look broken if slanted this way, both in Latin and Japanese. Other examples are U+3033-3035 VERTICAL KANA REPEAT MARK UPPER HALF/LOWER HALF. Implementations need to create a table of code points that should not be slanted.

#3 Right edge down is another way to implement naturally. If an implementation renders vertical flow by rotating glyphs 90 degrees counter-clockwise, then by rotating baseline 90 degrees clockwise, it requires the least work to get this result. Windows GDI, DirectWrite, and Core Text are built to render vertical flow this way.

Issues in this option are:

  1. When author sets Latin fonts with real Italic face as the first font and East Asian font as the second, sets all characters to be upright, and does not use full-width code points, characters from the first font such as ASCII is right slanted, while other characters are down.
  2. It is not the most common way to slant Japanese characters for Japanese authors/publishers, but authors/publishers say this option suffices the original requirements above and is acceptable, and has no other technical issues the spec/implementations need to solve.

The elimination gives me a conclusion that #3 is the least problematic and the most reasonable way to italicise text in vertical flow.

One thought on “Further analysis on Italics in vertical flow

  1. Hiroki Kanou

    Thirty or forty years ago, when phototypesetter prevailed, Japanese `italic’ was
    not skewed, but diamond-shaped because they were compressed diagonally
    by distortion lenses. An advantage is that you can share glyphs with vertical and
    horizontal writing modes.

    Reply

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>