[usf-devel] Re: Character orientation in Asian and Mongolian read-direction (verticaltextlines)
- From: mion <webmaster@xxxxxxxxxxx>
- To: usf-devel@xxxxxxxxxxxxx
- Date: Sun, 14 Aug 2005 09:21:12 +0900
unmei <unmei@xxxxxxxxxxxx> wrote:
>
>
> 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)
For me, tate-chu-yoko in the vertical subs has been one of the
technical problems since 2003. Not just invented today ;)
This SSA sample from 2003 includes tate-chu-yoko too.
http://ld-anime.subforge.net/tmp/vertical-subs
Also, if you do some google by "tate-chuu-yoko" or
"tate-chu-yoko" you'll find quite a few pages in english,
among other things:
http://etc.agnesscott.edu/Help/1_12_8_3.html
> >>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.
Numbers are ok too.
Actually, vertical subs are not very common at all.
I'd say, you don't have to spend too much time for this area
at least now that you have many things to do.
> 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").
Well, it was just a random thought.
For extensibility, the way to explicitly specify the default
would be needed. But in this case, "0" is just fine.
>
> 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
>
http://usf.corecodec.org
Other related posts:
