W3C home > Mailing lists > Public > www-style@w3.org > March 2003

CSS3 Text: glyph-orientation and bidi

From: fantasai <fantasai@escape.com>
Date: Wed, 05 Mar 2003 03:34:33 -0500
Message-ID: <3E65B699.4050800@escape.com>
To: www-style@w3.org

CSS3 Text, Section 3.3
http://www.w3.org/TR/2003/WD-css3-text-20030226/#GlyphOrientation

   Conformance Requirements for glyph-orientation-vertical
   -------------------------------------------------------

     # Conforming user agents may do the following in increasing
     # levels of supports:
     #
     #   1. support only the 90deg value,
     #   2. support only the 'auto' and 90deg value,
     #   3. support the 'auto', 0deg, 90deg, 180deg and 270deg values,
     #   4. support all values above and any number of additional values.

     | It is true that the minimal conformance value (90deg) is
     | not very useful for CJK characters, but it is sufficient
     | for other characters that don't need to be kept upright.
     | The new text includes 'auto' in the second list item and
     | above which implies font and platform support (typical
     | for a CJK support scenario).

   If there is no support for CJK, then 'auto' will be 90deg
   anyway, so there is no need for the first level. And it's
   a bit strange that support for the initial value is not
   required.

   Proposed changes:
     Make either 'auto' a conformance requirement for
     glyph-orientation-vertical.

     Under description of <angle>:
       Take out
         # Conforming user agents must at least support either
         # the value 90deg or all of the following values:
         # 0deg, 90deg, 180deg and 270deg. User agents may
         # support other values.

       Because it's both redundant and inconsistent with the
       conformance requirements stated later.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Interpretation of Degree Values in Glyph-Orientation-Vertical
-------------------------------------------------------------

      # A value of "0deg" indicates that all glyphs are
      # oriented with the bottom of the glyphs toward the
      # inline progression, resulting in glyphs which are
      # stacked vertically on top of each other. A value
      # of "90deg" indicates a rotation of 90 degrees
      # clockwise from the "0deg" orientation. For
      # characters which have this property set to 90 or
      # 270 degree, reordering is first applied according
      # to the Unicode Bidi algorithm and then the resulting
      # glyphs are rotated according to the <angle> value.
      # The rotation specified by this value is applied to
      # the glyph representations of all assigned Unicode
      # character codes.

    I wrote (comment 131):
      > The system would be less error-prone if 0deg were
      > defined to have all glyphs oriented with the bottom
      > towards the bottom of the block and 90deg to have the
      > bottom of all glylphs in the direction of the block
      > progression.
      >
      > This way, I can specify "vertical-orientation-vertical:
      > 0deg" for something and it will come out "upright"
      > whether writing mode is 'tb-lr', 'tb-rl', 'bt-lr', or
      > 'bt-rl'. I can also specify "vertical-orientation-
      > vertical: 90deg" for a run of horizontal script and/or
      > punctuation (e.g. for <code>) and it will display in
      > the correct direction in all four vertical writing
      > modes.

   The reply was:
     | It is generally preferred to have glyph orientation
     | related to inline orientation,

   Why? Don't you want to keep the bottom of the glyph towards
   the next _line_?

     | it also keeps the notation consistent with SVG which
     | use the same properties and has no concept of 'block'.

   Changing the direction of the degrees would have no affect
   on SVG since SVG only has tb-rl, not tb-lr. In right-to-left
   block progression, 90deg clockwise from upright *is* 90deg
   opposite the block direction. This change would make '90deg'
   align all horizontal scripts properly in both horizontal
   flows.

   Also, unless you change 90deg to mean "90deg in the direction
   opposite the block progression" rather than "90deg clockwise"
   and 0deg to mean "toward the bottom of the block" rather than
   "toward the inline-progression", the text for 'auto' is
   incorrect as it now stands.

   This is how it *should* work:
     http://fantasai.tripod.com/www-style/2003/directions/flow-diagram.gif

   Under the current text, however, 90deg is always to the right
   of 0deg, and 0deg is in the direction of the inline-progression
   so the result would be more like
     http://fantasai.tripod.com/www-style/2003/directions/flow-diagram2.gif

   Note that within a block the compass should be consistent regardless
   of inline progression:
     http://fantasai.tripod.com/www-style/2003/directions/vertical-bidi.gif

   Proposed changes:

      Section 3.1:
        # The glyph orientation determines the orientation of
        # the rendered visual shape of characters relative to
        # the inline-progression.

        Change to "relative to the block-progression".

      Section 3.3:
        # A value of "0deg" indicates that all glyphs are oriented
        # with the bottom of the glyphs toward the inline-progression,

        Change to "A value of '0deg' indicates that all glyphs are
        oriented with the bottom of the glyphs toward the bottom of
        the block."

        # A value of "90deg" indicates a rotation of 90 degrees
        # clockwise from the "0deg" orientation.

        Change to "A value of '90deg' indicates a rotation of
        90 degrees from the '0deg' orientation--clockwise in
        right-to-left block-progression and counterclockwise in
        left-to-right block-progression."

        # This property specifies the orientation of glyphs relative
        # to the inline-progression and block-progression...

        Change to "specifies the orientation of glyphs relative to
        the block-progression". (It should not be relative to the
        inline progression.)

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Affect of Glyph Orientation on Bidi Groupings
---------------------------------------------

   # The bidi algorithm and the 'glyph-orientation-vertical' property
   # have the following interaction:
   #
   #   1. The bidi algorithm is applied separately to each contiguous
   #      text range having the same glyph-orientation-vertical value.

   The glyph-orientation values should be compared after being rounded
   to the nearest multiple of 90 degrees. If I want the letters in my
   company's name rotated 15 degrees, the bidi algorithm should not be
   affected.

   #      In other words a change in the property value resets the bidi
   #      algorithm.

   What do you mean by "reset"? Do the embedding levels drop down to 0/1?
   Do the boundaries of the element acquire the paragraph's direction
   settings or its own direction settings? Does whitespace around line
   breaks get ordered in the element's direction instead of the
   paragraph's? How does this interact with the suppression of Bidi
   described for certain glyph-orientation values?

   # 2. When the glyph-orientation-vertical value is 270 degree...

   When it _rounds_ to 270 degrees. 271 degrees should behave the
   same way, even in a UA that supports 271 degrees and therefore
   doesn't round the actual value. You should explain somewhere
   that when the spec assigns behaviors based on certain glyph-
   orientation values, the assignment applies to all values that
   would be the equivalent if rounded to the nearest multiple of
   90 degrees.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Brackets in Vertical Text
-------------------------

   # Ideographic punctuation and other ideographic characters
   # having alternate horizontal and vertical glyph shapes shall
   # use the vertical shape of the glyph.

   What happens to non-ideographic punctuation, if its orientation
   is 0deg? An upright open parentheses doesn't appear to enclose
   anything in vertical English.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

References to CSS3 Block & Line
-------------------------------

   While there are interdependencies among modules, you should avoid
   unnecessary dependencies in the text. This leaves the other module
   free to develop without being tied to overly-specific assumptions
   made about it in an older module.

   # ... then the current text position is incremented according to
   # the vertical metrics of the glyph, and the glyph is aligned using
   # the vertical alignment-point as determined by 'alignment-adjust'
   # [link to the CSS3 line module] and 'alignment-baseline' [link to
   # the CSS3 line module]. Otherwise, the text position is incremented
   # according to the horizontal metrics of the glyph and the glyph is
   # aligned using the horizontal alignment-point as determined by
   # 'alignment-adjust' and 'alignment-baseline'.

   Change to "the glyph is aligned using the vertical alignment point
   as described in the CSS3 Line module". Make the same change for
   horizontal metrics/alignment, and take out the note about alignment-
   -point and -baseline or change it to a more general note.

   Note that this text occurs twice in CSS3 Text--once for
   glyph-orientation-vertical and once for glyph-orientation-horizontal.
   Both should be changed.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

CSS3 Text, Section 3.4
http://www.w3.org/TR/2003/WD-css3-text-20030226/#embedding

Embedded Objects
----------------

   # ... mark-up had been stripped, >non-textual entities such as images
   # treated as neutral characters,< and the resulting character sequence
   # had been passed to an implementation of the Unicode bidirectional
   # algorithm for plain text...
   #
   # Note: For non-textual entities such as images, when their 'unicode-bidi'
   # property has a value other than 'normal', and the 'direction' has the
   # value 'rtl', the resulting directionality is equivalent to character
   # type R (according to the types defined by the Unicode Bidirectional
   # algorithm).

   Change "non-textual entities such as images treated as neutral characters"
   to "non-textual entities such as images treated as object replacement
   characters (U+FFFC)" and delete the note.

   ## For the purpose of the bidirectional algorithm, inline objects (such as
   ## graphics) are treated as if they are an OBJECT REPLACEMENT CHARACTER
   ## (U+FFFC).
                -- http://www.unicode.org/reports/tr9/tr9-10.html

~fantasai
Received on Wednesday, 5 March 2003 03:34:08 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 27 April 2009 13:54:20 GMT