usf???

[starwarsandrisk]

okay.... well.... i've been lookin for information about USF and what its all about... but i havn't been able to pinpoint it and how it works?... how would i go aobut using and trying these out?....

[wiflye81]

Hi,
First you have this page http://usf.corecodec.org/ it explain all the current syntax, you also have http://corecodec.org/projects/u96/ witch is IMHO the best USF editor.

[Liisachan]

Media Player Classic can render USF subtitle, and iirc TCMP too.
USF is XML and will probably be usuful especially for "Unicode" languages. But atm, it's only alpha or pre-alpha, specs are not finalized yet. So it is advisable to try it only for experimental purpose...

[pixolex]

And any news for USF integration in MKV?

[unmei]

sadly no new on mkv integration. Toff is busy with TCMP, Haali who is also somehow into subtitles is working on pocketmvp (iirc), i'm currently on some "big thing" for u96 (therefore no update for so long).

The good news are, once i have this "big thing" on a solid base (ready for integration), there is virtually no way around embedding a matroska muxer ..and once i have to deal with such a muxer i will most likely also look into how one could mux USF into mks... With the hope mkvmerge or VDM would take these mks as as they wouldnt have to pack, just to merge it with the A/V part. I won't try a mux into mkV soon tho, because dealing with that would require to handle A/V streams already present etc..

Concerning the state of the format itself, u96 already does some things that are not clearly defined in the specs (effects, embedded fonts/pictures), and some module in the "big thing" already now features a stinky load of new attributes and a few new tags. However these are not really interesting for real-time playback as they require quite a lot of processing, but they allow for better editing and doing anything you can do in ass. Basicly it is full per-character styling and effect.

Calling it "big thing" hopefully makes somehow clear it will not be ready in the next few days..:rolleyes:

To Liisachan, i have to admit i did think about it a bit, but could not find a satisfactory solution for read-direction and ruby-text till now. A few more thinking and some kicks from other people might help ;) ..and yes, TCMP has USF support - imo the better than vsfilter.

As for gabest, i fear he has so many things going on that have a huge user base, we can't really count on him making the next step in such an experimental field (were it supporting usf from inside mkv/muxing it or improving the parser).

[Liisachan]

Originally posted by unmei

To Liisachan, i have to admit i did think about it a bit, but could not find a satisfactory solution for read-direction and ruby-text till now. A few more thinking and some kicks from other people might help ;)

That's too bad. Vertical subs would be less important, but supporting RUBY is a must if you are going to support Japanese subs seriously, as subbers in Japan use RUBYed subs quite often even in Karaoke.

If what can be done with SSA/ASS (sample pics made with ASS [deleted])cannot be done with USF, fubbers would be demotivated to use USF.:o

[unmei]

aaah more tokyo mew mew goodness =D

it would help me much if you could provide me with the ass way of doing it, since i start to grow a specialized part of my brain for converting format statements between usf and ssa/ass logic i could figure out how the analogue could be in usf.
I know you posted ssa fragments before, but if you don't want to post your most valuable tricks on a forum, can you send it per mail (unmei at matroska org) or or dcc in #matroska please?

btw i will be free from IE-preview's limits in not that far furure it seems now (http://tachikoma.no-ip.org/pixi-test3.png).

[Liisachan]

first, what is called "ruby" is a kind of diacritic in japanese langauge, which is used normally in daily life--in books, in movies, etc. Very roughly, "ruby" is like diacritics sitting on the letter "e" like in è é ë ê etc.

Originally posted by unmei

I know you posted ssa fragments before, but if you don't want to post your most valuable tricks on a forum, can you send it per mail (unmei at matroska org) or or dcc in #matroska please?


The more our tricks are valuable, the more we should share them. Sharing knowledge and experience is what makes everyone skilled and happier. Just look at this thread titled Japanese subtitles in SSA? (http://forum.doom9.org/showthread.php?s=&threadid=55312). Some "closed" fansubbers are likely to hide their "techniques," but my scripts are open-source. Especially when we are subbing in MKV, you can de-mux the SSAs from that MKV anyway.

However, RUBY in SSA is not wonderful; there are no tricks; we are just putting small texts using {\pos}
like this (http://mypage.naver.co.jp/freenet/ass/). That is a physical, brute way.

Thoretically, in USF, like in CSS3, RUBY can be defined in a structural way, like:

<ruby>
<rb>Ruby Base</rb>
<rt>Ruby Text</rt>
</ruby>


The problem is, how the renderer could render RUBY? MSIE can do that, but Mozilla cannot, which suggests that RUBY is not easy to render, to say the least. Basically, a render will:
(1) decide where to render the Ruby Text;
(2) calculate the parameters to define the small rectangular just above the Ruby Base; and
(3) render the Ruby Text in a smaller font (alignment: justify) in the area defined by (2)

In most naive cases, those are easy; but what if there is a word wrap? What if there is a collision? What if the Ruby Text is too long for the Ruby Base (in that case, you'd have to add extra spaces between letters of the Ruby Base so that the Ruby Text can sit properly on it) ....... There are a lot of possibilities to consider.

If CSS3 is officially out, probably there will be GPLed codes to handle <ruby> properly; <ruby> should be supported if you fully support xhtml 1.1, too. So I guess eventually someone will find the proper codes and modify em so they can handle RUBY structure in USF :)
I'm not going to talk only for subbers for Japanese language, but structural support of RUBY will be more than welcome for them.

It is obvious that SSA/ASS cannot support RUBY in a structural way, while RUBY is supported in CSS3 as a structure; so this will be one of those things that only USF can do.

[unmei]

thanks, i somehow thought you had found a less "brute" way in ass :D.

For the actual rendering, i don't feel like have to be limited by M$ IE any longer. With my new rendering engine i could handle the normal case quite straight forward, but the special cases you mentioned are really not simple to solve. The word wrap inside the ruby is especially tricky, but my renderer as it is right now would put the whole thing on the next line, so it only really has a problem if the ruby base alone is longer than the allowed line. Collisions are imo not a real issue as atm each "chunk" (same formatting) can expand the line height in order not to collide with the above and each <subtitle> rendered returns its enclosing envelope for following <subtitle>s to be moved accordingly.

The too long ruby text could be handled by increasing the base's scale-x or spacing attributes accordingly if the ruby text's font size cannot be decreased any further.

But there still remain cases where a correct handling will be problematic. I think about further markup inside the ruby base. Here the users sanity will probably the only thing to rely on ;) It would probably be wise to allow the <font> tags attributes inside <rb> and <rt> but then disallow any further markup inside them.

Also i have no working code for karaoke rendering atm, and you example imply it's important in karaoke. Maybe karaoke will further complicate the ruby rendering in ways i cannot think about right now..

After all, ruby processing will be quite computing intensive ..but so are others of the new attributes i use and the <fx> tag. These things are clearly only for non-real-time rendering on todays average computers.

[edit=typos]

[Liisachan]

Hi

I'm not sure whether this is the right place to post this, but I'd like to propose one (or two) new text-alignment types for USF, so that subbers can eaily use a "nested" alignment as you can see in this pic (http://park14.wakwak.com/~flower/usf/80.jpg).

What is a "nested" alignment to be exact? Let me explain:

*

The fact is, I was just told by a Japanese subber that there should be a "new" alingment type for sub texts, which is somehow between SSA {\a1} and {\a2}
To be exact: when there are more than one lines in subtitles, like

abcdefg\N
hijk

they want them to be aligned like


<-- screen width --------->
__________abcdefg__________
__________hijk_____________


ie
(1) the longest line will be centered (equal margin-left & margin-right)
(2) other lines will have the same margin-left with (1) [then margin-right will be decided automatically]

In HTML, this would be something like

<div style="text-align: center">
<p style="text-align: left">
abcdefg<br />
hijk
</p>
</div>


Hence I called it a "nested" alignment.

The sample is here (http://park14.wakwak.com/~flower/usf/80.jpg). According to that subber, this alignment style is used (not always but) quite often in Japanese subs in movies as in this real sample (http://park14.wakwak.com/~flower/usf/pc_prv01.jpg). And more than one subbers told me that they really wanted to use this style. (That's where this story began.) I told them that they could use SSA {\a1} with proper left-margin, but I realized that would be not very nice because left-margin wouldn't be fixed (as this is basically centering)

I suppose this kind of "nest" might be possile in USF by a mixture of some means, but if it is so common as they say, why won't we add one or 2 new pre-defined alignment types to already-defined 9 alignment types (TopLeft, ..., MiddleCenter, ..., BottomRight):
10. BottomCenteredLeft
11. BottomCenteredRight (for the similar alignment for Right-to-Left languages such as Hebrew and Arabic)

Technically, this alingment should be not difficult for a renderer; so I assume that USF should support these positioning types so that it will be universal/multi-purpose as its name says, as long as such alingment types are really in use and some subbers do need them. Or the USF specs had been already finalized?
....that's it.
tyia :)

[Sylf]

I'm not sure if it's a wise idea just to add two such positions predefined. If you start defining all the nested positions, as far as horizontal subs are concerned, we would have 27 different possibilityes. (If we start including vertical subs... 81 possibilities?) Rather than pre-defining such positions, wouldn't it make more sense to allow actual nesting of the alignment itself?

I'm not familiar with USF syntax yet, so I'm sorry if I sound like an idiot.

Or, possibility #2 - make the position numbers permanently 2-digits. And have "outer" positioning displayed at 2nd digit, and "inner" positioning at 1st digit. So, 22 could be BottomCenterCenter, and 21 is BottomCenterLeft, etc...

[BetaBoy]

Liisachan , unmei will be doing an update to USF that will increase the amount of effects USF is capable of doing... other then that you need to talk to him and Toff about what you are suggesting.

I have asked Toff to comment on this....

[[Toff]]

Another way would be to add another attribut called textalignment or inneralignment with the possible value "left|top|right|bottom".
This may be better cause it seems interesting only for text.

[Liisachan]

Originally posted by Sylf
I'm not sure if it's a wise idea just to add two such positions predefined. If you start defining all the nested positions, as far as horizontal subs are concerned, we would have 27 different possibilityes. (If we start including vertical subs... 81 possibilities?) Rather than pre-defining such positions, wouldn't it make more sense to allow actual nesting of the alignment itself?

That's exactly what I thought, Sylf. Something like:


<subtitle start="00:00:00.000" stop="00:00:05.000">
<box alignment="BottomCenter">
<text alignment="TopLeft" speaker="Elftor">
What the hell are you talking about?
</text>
</box>
</subtitle>


Purely theoretically, even withiout thinkin about vertical subs, there would be already 9^2 = 81 possibilities because of 9 "outer" alignment types and 9 "innner" types.
(1) Come to think of it, BottomCenter itself is already nested in nature. Logically we can decompose it into 2 nested tags: one for Bottom, the other for Center in the Bottom.
(2) Practically, it will be a pain to write nested tags for each sub texts. If the same positioning is repeated many times, it would be logical and clean and easy-to-maintain to have it pre-defined under an specific name in a <style> in the <styles> section: we might want to add sub-alignment attribute, like:


<style name="myStyle1">
<position
alignment="BottomCenter"
sub-alignment="TopLeft"
vertical-margin="10%"
relative-to="Window" />
</style>

OR very logical person might want to make it like this, using a new attribute value relattive-to="DirectParent"
[code]
<style name="myStyle1">
<position
alignment="BottomCenter"
vertical-margin="10%"
relative-to="Window">
<position
alignment="Left"
horizontal-margin="0%"
relative-to="DirectParent" />
</position>
</style>

[Liisachan]

Originally posted by BetaBoy
Liisachan , unmei will be doing an update to USF that will increase the amount of effects USF is capable of doing... other then that you need to talk to him and Toff about what you are suggesting.

I have asked Toff to comment on this....
Thanks BetaBoy :) I hope unmei is reading this thread, but I will PM him anyway.

Originally posted by [Toff]
Another way would be to add another attribut called textalignment or inneralignment with the possible value "left|top|right|bottom".
This may be better cause it seems interesting only for text.

I second it. Nested tags would be nasty, especially if you have to write one for each line. A simple new attribute would make it really simple... you could then just define "inner-alignment" in <style>. Besides, we could define an adequate default value for "inner-alignment" so anyone who is not interested in nested alignment can just omit it and everything will go fine.....


[edit::add]
I've just realized something:
(1) conventional alignment types are, actually, to align the imaginary box in which you see sub texts: so it's block-level as CSS ppl say.
(2) new alignment discussed here is line-level, to be "poured" into the above-mentioned box.
I'm now guessing that things were not clear in SSA because we didn't (or couldn't) distinguihs these 2 levels. To distinguish "display: block" and "display: inline" might be a good idea to make USF specs solid n clear, giving USF even more modernity that other sub formats are missing.
[/edit::add]

[unmei]

i finally found some time and motivation the last days..
While you were thinking about this new alignment type i saw sorting out useful elements in SVG.

I wrote a new proposal for a next draft of USF and thereby included a new position attribute <line-align> which takes one of the values left, center, right, top, middle, bottom. It being a position attribute means you can use it in styles and effects (not actually animatable tho) <position> and a <text> (or same level) node directly.

the proposal is at corecodec (http://usf.corecodec.org/usf_0.17proposal4.html).

The proposal also includes the mentioned crippled SVG, all the styling and positioning attributes i introduced when i wrote my own rendering engine (not finished, for u96 and beyond) and an extended notion of the karaoke element to allow flashier "sfx". Further it covers the embedded files and maybe more new stuff i already forgot was not yet in draft 0.16.

[Liisachan]

thanks a bunch Unmei :D it's so sweet and seems quite promissing;
speaking of "spacing" do we already have "vertical spacing" or "line-height"?

[unmei]

you think of the "thickness" of the line space, not the height of the written text right? No we don't, but i will add it to the proposal this afternoon. If you thought about the height of text, the scale-x and scale-y are for deforming text this way..

I have a little problem with where to add 'line-spacing' tho. It seems unlucky to add it to font aattributes since it is something common to a entire text line. It should probably go into the position attributes (like aine-align) then it would be available at the level of text, karaoke (,image, svg) elements but also in a style or keyframe position element.

do you know how this property is called in CSS? 'line-spacing' would be analoque to 'line-align' but maybe we should stick to the names people already invented for these properites..

[Liisachan]

Originally posted by unmei
do you know how this property is called in CSS? 'line-spacing' would be analoque to 'line-align' but maybe we should stick to the names people already invented for these properites..

It's line-height.
Test these and you'll soon understand what I mean.

p.narrow {
font-size: 20px;
line-height: 1.1;
}
p.wide {
font-size: 20px;
line-height: 1.6667;
}

<p class="narrow">some long text here....</p>

<p class="wide">Here goes another long long long text....</p>

[unmei]

line-height in CSS refers to the entire height (including the text, not only the white space between text).

Now i would prefer a attribute to specify additional (omitted) space in the white space only. This way you could add or remove pixel without having to consider the height the text is rendered. With the line-height logic you could do this (like you did) by specifying a factor of the default calculated height but not with pixel (or you would need to know how many pixel high the unmodified text was). With a attrbute modifying the white space only you could specify pixel, but factors (percentages) would either have not to be allowed, or interpreted with the entire text height as base (like with the line-height attribute).

Of course we could name a attribute 'line-height' but make it work like 'line-spacing'. This could be confusing for people knowing CSS tho..

line-??="2" //add two pixel to the white space
line-??="-2" //cut two pixel off the white space
line-??="200%" //would look like a empty line inserted

if pixel values are allowed, either factor is not allowed (but percentage), pixel values must have a sign ("+2") or pixel values are required to have a 'px' unit suffix (iirc USF nowhere else uses a 'px' suffix..)

[unmei]

http://usf.corecodec.org/usf_0.17proposal4.html (23.apr)
http://usf.corecodec.org/USFxSVG_proposal1.html (1.may)

(i had some quite long remarks to add, but when i submitted i wasnt logged in anymore => lost it => lost patience)

[Liisachan]

btw, unmei, do you think you should completely finalize the spec before MKV begins supporting USF as a track?
Or would it be possible that we'll update the spec even after the 1st USF support by MKV?

IMHO, it would be realistic to version-up USF( like USF1, USF2, USF3...) , getting users' feedback

[ChristianHJW]

Originally posted by Liisachan
[B]btw, unmei, do you think you should completely finalize the spec before MKV begins supporting USF as a track?
Or would it be possible that we'll update the spec even after the 1st USF support by MKV?

IMO it would be a good thing to test what we have right now and clearly mark it as alpha, because the best feedback is always coming from people using stuff .... an existing matroska muxer, however it was done, could IMO be easily updated once the USF specs change until the final version ....

[unmei]

i think it should be well possible to mux a initial set of USF into matroska before everything is finalized. This is what the X in XML means after all ;) Without really thinking it through, i'd say everything that is in draft 0.16 (what is up on the website since a year) is more of less frozen. I don't think anyone is going to remove, reinterpret or rename these elements and attributes.

Furthermore this (draft 0.16) might be a good first set as most of the things i added recently are rather special, focused on the more demanding typesetter and also most of them are just unplayable in real-time (thus targeted at hardsubbing).

Now for how muxing would work, a muxer must be able to ignore elements and attributes it doesn't understand or doesn't want to include in the generated track. With a general XML parser this is very easy, you just look for and pick nodes you want and everything else is ignored. So, as the programmer decides to add more USF elements to the muxer's capabilities she just adds handling routines for them :)

For playback of muxed content, i don't know how exactly that would have to work ..maybe the demuxer would rebuild a USF file and then pass that to a normal USF renderer or there could be a renderer dedicated to binary usf (if someone still wants to use binary code in the muxed content).

Now ..who does it ?? :P not me in the next half year i guess.. i'm so cluttering my projects recently ..like i have about 4 or 5 different half-finished modules for u96 ..yeah yeah i know ..but _once_ i can stick them all together and it works, u96 will be like a totally different application :) damn i get so excited over it, but at the same time i fear getting lost in all those subprojects :/

[Liisachan]

Originally posted by unmei
Furthermore this (draft 0.16) might be a good first set as most of the things i added recently are rather special, focused on the more demanding typesetter and also most of them are just unplayable in real-time (thus targeted at hardsubbing). I'd say, one or two things form 0.17 would be very nice to be included om the 1st alpha:

(1) line-align (at least {Left | Center | Right } as I think {Top | Middle | Bottom} is for vertical subs )
This is feedback from real end users. It's practical and, unlike Rubies etc., easy to implement. If end users' requests are already fulfilled in the 1st alpha release, it'll be likely that they are giving more feedback, getting more interested, having good feelings toward this new project, thinking devs are quick and ready to hear users. That'll be a good start...

(2) <embedded> Maybe... special consideration should be taken for this, because it was already supported in the original SSA specs, but not supported now in the SSA muxed in MKV. Probably (2) is harder than (1) to realize, but anyway font embedding is not a very special demand, but rather common especially in softsubs.

Thank you -nyu

[Yusaku]

I was reading news today and thus realized USF ices are finally moving again :)

Ok, here's my rant, now placed in correct place. It is just random thoughts, but the main idea is to allow much better positioning than now with almost no work needed to do on renderer's side (matrice calculations are really simple)

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

I took a glimpse at the specs and the DTD, and I must say that IMO at
current state it lacks the most in the area that has the biggest potential
to gain from XML format - the ammount of text effects usable is relatively
small - basicaly scale, font weight, outlines, shadow.

Ok, my random thoughts:

Even at current ASS specs implementation, the format allows for wider
palette of effects due to a lot of functions. Functional approach is very
bad idea for XML, though, so I would propose adding a 4D OpenGL style
transformation matrix of 16 float numbers to the "fontstyle" element. With
default matrix (1 on diagonals, 0 elsewhere) the rendering would work as
before. With different coefficients, the position, rotation, size, side etc.
(all possible stretchings, movings, ...) could be realized without the need
for zillions of rotation and scaling functions. Possibly also make some
matrix aliase names (like "MirrorByXAxis") and aliases with smaller matrices
with only some parameters to be filled left (rotate by X degrees in
direction of x/y/z) for people using notepad and not graphic editor - but
after some experience 4D matrices are not too evil, so it is just optional.
The implied matrice algebra is quite neat (already have nice effect but need
to rotate it to fit on shopsign in scene? Just multiply by position/rotation
matrix - currently IMPOSSIBLE in ass)

scale-x and scale-y could be dropped, absolute positioning could be left as
override for final positioning for effects (redundant, but convenient).

This way, defining of style like "Star wars banner text" would be possible
without too much trouble (major pain in ASS, although possible)

Yusaku

PS: I hope unmei is reading this - I do not have his email...

PPS: Having 3D control over integrated SVG would be quite neat as well -
imagine the effect possibilities ;)

PPS: Reread #3 - rotation is possible even now, but having the matrice as a
parameter of "PositionAtributeList" instead of current set of random
parameters copying ASS would be neat - there are a lot of possible
positionings not covered by current list

[Yusaku]

ad ruby/ofurigana/reading hint (depending if you believe Liisachan/japanese textbooks/Microsoft ^___^) support: I think the best would be to have it as tag directly in the text, like italics etc.:

<subtitle>This is a <ruby hint="uncomprehensible">
unmegsvknvujfnudfvkjdlfkle</ruby> text</subtitle>

would render as

uncomprehensible
This is a unmegsvknvujfnudfvkjdlfkle text

uncomprehensible being written in smaller font

i.e. on the same level i, u, br tags are defined - advantage is that if parser doesn't support <ruby> tag, it'll just print out the text without ofurigana

Edit: Ad rendering problems - in most cases there should be no problem. If a wordwrap occurs inside of a ruby, it is clearly subtitle problem and cannot be solved in any pleasant way - just do not segfault in that case, but ignore it. If ruby is wider than text it belongs to, increase character spacing of the text below until it fits.

[Liisachan]

Er... well, you dont need o- (not o-furigana but furigana)
and it's officially called RUBY in CSS3, or W3C Recommendation 31 May 2001: http://www.w3.org/TR/ruby/

Originally posted by Yusaku

<subtitle>This is a <ruby hint="uncomprehensible">
unmegsvknvujfnudfvkjdlfkle</ruby> text</subtitle>



Gerenally, the Ruby Text can has its own style,
so the Ruby Text cannot be an attribute, but it should be ordinary (taggged) stylable text, like...if we write this as <ruby hint="man">Anthropos</ruby>, how could we style the text for man......?


<ruby><rb>Anthropos</rb><rt>man</rt></ruby>

rb {
color: black;
}
rt {
font-size: 60%;
color: green;
}

If needed, this should be even possible:
<ruby><rb>FOO</rb><rt some_attribute="qux">bar</rt></ruby>

[unmei]

so I would propose adding a 4D OpenGL style transformation matrix of 16 float numbers to the "fontstyle" element.

OGM! If you really meant fontstyle, this is a direct attempt to assassinate me :)
Making any transformations of the fontstyle is very dangerours IMO, that is also why i removed the rotation and offset from fontstyle (i had this implemented a bit, but it will either require a lot of try and error from the user, or kill the programmer).

Including such a transform in the positions on the other hand were not that difficult to program tho. The only thing there is, if you leave the current attributes in there must be a clear specification of the order the transforms are applied (currently i use scale>>rotate>>translate) and if you wanted to remove the current attributes, you have to be aware that the rotations were in draft 0.16 and i think already in much earlier versions. I'm not completely against it, it is just something to think about. Unfortunately XML is very good for adding stuff but poor for removing. To me it is not a practical problem to remove them. I think i never used them personally and i could still include a little routine in u96 to convert rotates in input usf into corresponding matrix transformations. It just openened the possibility that previously legal files are declared illegal now.



Updated the DTD and html (added the attributes line-spacing and read-direction to the position-attributes list)

Maybe i think a bit too much in terms of programming, always only considering something if i already know how i would implement it :o
Probably i should just collect all ideas -no matter what i think of them- in a fresh DTD and then after a while look what it has grown into. It's weekend i hope i come to it ..but not now its 6:30 am in my part of the world and i need sleep :p

[Yusaku]

Hehe.

Indeed, I was writing the "rant" as I was trying to parse the DTD in my head, so there are... inconsistences :)

Yes, I meant positions. Now that I think about it once more, I think it indeed could be just added at the beginning of processing pipeline (before scaling) - as it is more natural to write positioning using "scale" and "rotate" in XML by notepad, but this could be great option for visual editors like U96. (i.e. the four bounding pixels can be moved over the screen; plus a possibility of rotating by x/y/z axes)

The order is in this way, so that you could apply modifications to the position in sensible way using only text editor if you have some subtitle already done in GUI (i.e. there's a weirdly perspective modified sub that you just want to enlarge a bit)

[unmei]

i have some problems with the interpretation of "3D" in USF. To me rotate-x and rotate-y were always equivalent to "scale-y cos(angle)" and "scale-x cos(angle)" , in short the whole thing was 2D only (like SVG btw), but with 2D you don't need a 4x4 matrix, 3x3 is enough.

Also i thought about it a bit for myself and then talked back to my math prof to make sure, but you cannot represent the "star wars transform" with a matrix. What you could do were assuming the Z-direction converges to a single point at some distance, then obviously rotating a bit around the x (or y) axis will produce that effect.

But at this point i start to be sceptical about the whole 3D and transform thing, because if you start with convergence points it will get a lot more complex. Of course you could add a attribute "convergence-distance" to some node, but i fear this sort of stuff would lead to USF becoming a little Open-GL and this is definitly not what i want. I guess i will have to talk back to Toff about the 3D issue, maybe he really intended this kind of direction..
But personally i would prefer to stay in 2D plane (3x3 matrix is ok) and then add some candy with other dedicated functions to be reseved for the "insane people" to achieve stuff that cannot be done with 2D and 3x3 matrices.
As a workaround for the star wars effect i think about a perspective attribute maybe in the form of perspective(axis,%), were axis could be +x,-x,+y,-y and the side in axis direction would become % of the original extent.

This can easily be done on the final generated bitmap, which is also the way i perform the other operations (therefore scaling UP stuff with my software will not look good, better make the original big and scale down;)

Ruby:
Some days ago i thought about how to implement it in the parser (rasteriser) and i think i came up with a way that integrates well with the existing logic of the parser, actually the changes look very simple (in concept stage that is:p)

But somehow i had Liisachans synthax wrong in my head and therefore planned it with that other synthax. However Liisachan used CCS-like styles in her example and i think this is not what she meant to include in USF since we already have a synthax for describing styles. Ah well, i'll just give an example, and you tell me what you think about it.

<ruby>
<rb>
<font color="#000000">Anthropos</font>
</rb>
<rt style="myRubyStyle">
man <font size="-2" color="#7f7f7f">greek</font>
</rt>
</ruby>


It is really not much different. Just note that <rb> and <rt> can have markup like usual (but i'm pretty sure my parser will always break badly if you use a <br/> inside either <rb> or <rt>). Also both nodes should have a style attribute to allow for a compact notation as most of the time you probably want <rt> to have a different style then you can do it without adding another <font> aoround everything inside that node. Also <rt> should have two additional attributes determining it's size and position (like with all referred styles inside the markup, its position node is ignored). width is a percentage <= 100% and the ruby text will be scaled such that the entire ruby text has a width such percentage of the ruby base. The ruby text is centered over the ruby base. The height at wich the ruby text flows over the ruby base is given by the position attribute (could also be called different, like "elevation" for example). It is also a precentage but can be negative and bigger than 100%. At 0% the bounding box of the ruby rext is placed exactly on top of the base bounding box. Negative percentages lower its position, positive raise it. -100% would then be a ruby text with its bounding box touching the ruby base's bounding box from the inside.
The DTD fragment i think about:

<!ELEMENT ruby (rt,rb)>
<!ELEMENT rb (%BasicTagAndText;)*>
<!ATTLIST rb style CDATA #IMPLIED>
<!ELEMENT rt (%BasicTagAndText;)*>
<!ATTLIST rt style CDATA #IMPLIED
width CDATA #IMPLIED
position CDATA #IMPLIED>

[Liisachan]

I've just made this page to demonstrate some of most common RUBY structures with XHTML codes and pics where the code is rendered by MSIE.

http://ld-anime.faireal.net/usf/ruby

Hope this will help you (devs).
I could make any other examples if needed.
Feel free to ask me if there's anything unclear. :)

[unmei]

thanks Liisachan.

could you enlighten me what the <rp> tags are for? they seem to do nothing .. always enclosing a single '('')' pair that doesn't get rendered.. Actuallly this tag seems useless to me.
Further i noticed, my firefox renders the last two examples different that the prerendered pictures from IE6 ..i wouldn't say unusable, just different:

http://www.hta-bi.bfh.ch/~seilf/doom9/ruby-firefoxvsie1.pnghttp://www.hta-bi.bfh.ch/~seilf/doom9/ruby-firefoxvsie2.png


I know this thread is about usf and not my own clumsy renderer, but still i have to get this off my chest: these two last examples are also exactly where i expect my renderer to break (or at least fail to show it like intended).

BTW what you think about the DTD fragment i included in the last post ..is that OK like this or do you think it needs changes / has some real problems etc..

[Liisachan]

As for <rp> elements, could you check this page?

Rp (Ruby Parenthesis) (http://www.blooberry.com/indexdot/html/tagpages/r/rp.htm)


<ruby>
<rb>HTML</rb>
<rp>(</rp> <rt>HyperText Markup Language</rt> <rp>)</rp>
</ruby>


If the renderer knows RUBY, <rp> elements will be ignored, and you'll see the ruby text "HyperText Markup Language" above the ruby base "HTML".
If the renderer does NOT know RUBY, then it will ignore every markups--<ruby> <rb> <rp> and <rt>--which will give you:
HTML(HyperText Markup Language)
That makes sense. In short. <rp>'s are for fallback mechanism.

Your firefox examples are surely acceptable, but the way IE6 handles them is preferable--it's exactly the way most ppl in japan expect.

As for DTD: there would be some questions...
(1) So, do we need <rp> ?
(2) do we need "width" attribute for <rt> ? In most cases, the position of the ruby text will be automatically decided, so the renderer will be confused if "width" is specified, isnt it?

Everything except those two seem fine to me atm.
Probably we'll see when we release a real beta renderer.
Hope CoreCodec will be back again soon.

As a side note, RUBY is not just for a few weird subbers. Almost all subbers in Japan and subbers who know Japanese quite well would be eager to use it.....:)

[unmei]

my thought behind "width" was, that as the renderer probably has to ignore size attributes specified in a style this direct attribute could be used control the size of the ruby text. I admit it is a bit weird, and if it turns out useless or impractical we could still remove it.

And for the ruby parentheses, i understand the concept now. It is surely a clever idea. But i'm a bit torn apart whether i should be for or against them in USF.
On one hand it is clever, and as ruby might be rather special it could be good to have a fallback mechanism for as the probability of a renderer implementing it is maybe not that high. On the other hand, USF has no such mechanisms elsewhere - it never had to have them since everything before was rather simple, or else a renderer output were still useful if it ignored a tag.. Also the logic for a renderer supporting ruby will be a bit more complex as it has to remove normal text from the output (the parentheses). - I guess i'll have to think about <rp> a bit more.. ..whether to actually put it in a specs draft and also how i could implement it..

I hope my posts lately make some sense ..i'm working at quite different stuff atm ..the chaotic puzzle u96 0.2 starts to form larger chunks. Even tho that renderer will be part of it, my priority atm is to stitch stuff together even if the parts are unfinished (otherwise i would really start to lose oversight).

[Liisachan]

personally i dont think we need <rp> if:

1. All USF renderes MUST support <ruby>; and
2. So, no fallback mechanism is needed.

That's simper.

On the other hand, USF is XML; which means USF is not just subtitle data. It's an XML application data, supposed to be flexible as can be. You could use it as another purpose than subtitling, like viewing it on your browser with XSL... so, even tho we dont actually need <rp> in our "ideal" USF renderers that can handle RUBY, still having <rp> might be a good idea to bridge the gap between XHTML and USF. Viewing all the subs as a table in HTML might be helpful for fans or fansub editors...

I'm guessing, for clever USF renderes that know <ruby>, just ignoring text data from <rp> till </rp> would cost only a little, wouldnt it?

Anyway keep doing a good job with your new tool, unmei :)
I'm really sick to use ASS {\pos} to put a ruby text phsycally and USF is a way to go!!!

[unmei]

i got one of my schoolmates a bit interested in USF.
Chances are tiny i fear, but if he really looks into it, this could be a great thing for USF on *Nix / MacOS. At least he knows what a DTD is, is familiar with *Nix opensource habits and sure knows programming in C/C++ a lot better than i do. He was thinking about beefing up the mplayer subtitle renderer as to understand some of the XHTML/USF tags.
But like i said, don't expect something.. he was a bit pissed when he saw a USF reader for mplayer in a mailing list dated december 2003 but could find no trace of it in the mplayer CVS :rolleyes: and is anyway busy with porting some kernel thing i don't understand from linux to his macOS.

Anyway, just wanted to mention it because it would be great to have USF getting some ground in the linux land..