- From: fantasai <fantasai@escape.com>
- Date: Wed, 05 Mar 2003 03:34:33 -0500
- 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 UTC