[usf-devel] Re: Character orientation in Asian and Mongolian read-direction (verticaltext lines)
- From: unmei <unmei@xxxxxxxxxxxx>
- To: usf-devel@xxxxxxxxxxxxx
- Date: Sun, 14 Aug 2005 01:19:22 +0200
liisa wrote:
Is this a counterpart of ASS \frz ?
But \ftz is "line rotation"
line-rot. and glyph-rot. are 2 different things:
http://usf.subforge.net/images/font-rotation.png
No, it wasn't planned as such. I haven't looked into the SSA
specifiations "for ages". I was strctly looking for a way to manage the
problem with rotated words in upright top-down text. And when you say
\frz is for lines, then it is obviously not even by accident the same.
The "capability to do funky things" i also only only realized when i
wrote the mail, it was not initially planned, but then i saw "heh, when
i allow more than just boolean values here, this has potential for
becoming style candy"
(actually, i had line-rotation expected to keep the letters normal to
the baseline, not notmal to the viewport, but that's OT)
There's yet another thing to consider.
- tate-chuu-yoko
- ruby direction
http://usf.subforge.net/images/tate-chuu-yoko.png
interpreting this picture i think the ruby direction is already solved
with the new attribute:
<text read-direction="Asian"><ruby><rt glyph-rot="-90">eng.
explanation</rt><rb>complicated japanese term</rb></ruby></text>
<text read-direction="Asian"><ruby><rt>jpn.
explanation</rt><rb>complicated english term</rb></ruby></text>
(of course also possible by referring to styles)
(assuming the japanese text should be upright and the english 90Â
clockwise rotated as seen in your picture)
However glyph-rot cannot be used for tate-chuu-yoko (heh i start to
think you invent this stuff for keeping me busy ;D)
The answer to this would be rotate-z as fontstyle attribute. This is
procedurally on the point, but it would lack a semantic meaning. If
tate-chuu-yoko is a concept that should be identifyable because it "has
a meaning" (like ruby binds to the base as "explanation") it were
probably preferrable to have a special element for it, if there is no
such "meaning" i think it could well be done with rotate-z.
allow values "+90", "0", "-90" and maybe more instead of a simple
boolean flag such as "upright"|"rotated".
That'd be practical, at least as a starter.
only a few possible attributes, like
glyph-rotation = none | left | right | down | inherit
Actually i would prefer not to use keywords as values even in the very
begin. Because "-90" is a simple integer, but it is also a valid float.
But if you use keywords and later want to switch to floats for style
candy, the keywords are in the way. You either need to support 2
datatypes, floats and keywords. Or you drop the keywords, which is
rather uncool.
I am not quite sure i understand how you interpret "none" and "inherit",
but i assume it were covered by explicity setting "0" in nested elements
("none") vs. omitting the attribute in nested elements ("inherit").
If you think numeric values are too ugly for the basic user, we could
discuss about supporting both keyword and numeric values. It is not
especially more complex, i just preferred not supporting both in the
case there was no reason to have keywords.
http://usf.corecodec.org
Other related posts:
