Re: Character orientation in Asian and Mongolian read-direction (verticaltext lines)

liisa wrote:
> Is this a counterpart of ASS \frz ?
> But \ftz is "line rotation"
> line-rot. and glyph-rot. are 2 different things:
>=20
> http://usf.subforge.net/images/font-rotation.png
>=20
No, it wasn't planned as such. I haven't looked into the SSA=20
specifiations "for ages". I was strctly looking for a way to manage the=20
problem with rotated words in upright top-down text. And when you say=20
\frz is for lines, then it is obviously not even by accident the same.=20
The "capability to do funky things" i also only only realized when i=20
wrote the mail, it was not initially planned, but then i saw "heh, when=20
i allow more than just boolean values here, this has potential for=20
becoming style candy"
(actually, i had line-rotation expected to keep the letters normal to=20
the baseline, not notmal to the viewport, but that's OT)

>=20
> There's yet another thing to consider.
> - tate-chuu-yoko
> - ruby direction
>=20
> http://usf.subforge.net/images/tate-chuu-yoko.png
>=20
interpreting this picture i think the ruby direction is already solved=20
with the new attribute:

<text read-direction=3D"Asian"><ruby><rt glyph-rot=3D"-90">eng.=20
explanation</rt><rb>complicated japanese term</rb></ruby></text>

<text read-direction=3D"Asian"><ruby><rt>jpn.=20
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=C2=B0=20
clockwise rotated as seen in your picture)

However glyph-rot cannot be used for tate-chuu-yoko (heh i start to=20
think you invent this stuff for keeping me busy ;D)
The answer to this would be rotate-z as fontstyle attribute. This is=20
procedurally on the point, but it would lack a semantic meaning. If=20
tate-chuu-yoko is a concept that should be identifyable because it "has=20
a meaning" (like ruby binds to the base as "explanation") it were=20
probably preferrable to have a special element for it, if there is no=20
such "meaning" i think it could well be done with rotate-z.

>=20
>>allow values "+90", "0", "-90" and maybe more instead of a simple=20
>>boolean flag such as "upright"|"rotated".
>=20
>=20
> That'd be practical, at least as a starter.
> only a few possible attributes, like
>=20
> glyph-rotation =3D none | left | right | down | inherit
>=20
Actually i would prefer not to use keywords as values even in the very=20
begin. Because "-90" is a simple integer, but it is also a valid float.=20
But if you use keywords and later want to switch to floats for style=20
candy, the keywords are in the way. You either need to support 2=20
datatypes, floats and keywords. Or you drop the keywords, which is=20
rather uncool.
I am not quite sure i understand how you interpret "none" and "inherit",=20
but i assume it were covered by explicity setting "0" in nested elements=20
("none") vs. omitting the attribute in nested elements ("inherit").

If you think numeric values are too ugly for the basic user, we could=20
discuss about supporting both keyword and numeric values. It is not=20
especially more complex, i just preferred not supporting both in the=20
case there was no reason to have keywords.

http://usf.corecodec.org