[usf-devel] Re: Comment events
- From: unmei <unmei@xxxxxxxxxxxx>
- To: usf-devel@xxxxxxxxxxxxx
- Date: Sun, 14 Aug 2005 17:42:11 +0200
Luca Della Santina wrote:
This kind of subtitle events comes very useful for storing
translator/typesetter comments to the other people who'll work on the
script;
I think it's already pointed out in Toff's docuementation how you can
use normal XML comments for this ( <!-- comment --> )
They are also useful for making a local backup copy of the
subtitle when you test new feature for that subtitle and you probably
want to come back to the original for or leave the original form in the
script for a latter analisys/documentaion.
Again you can use "<!--" and "-->" around the element.
There are some issues with the XML comments tho.
*XML Parsers don't threat them like "normal" nodes. Some my allow you to
parse within them, some at least give access to the content as text and
some might even totally exlude them from the parse tree. This makes may
pose a problem when you try to show the comment beside an element as
belonging to that element, and most likely coun can't parse it like a
normal element for display (thus the comparision by the user would have
to be based on the "source code").
*I think nested comments are not possible (legal) in XML. This is bad if
you want to comment out an entire subtitle where you have a comment
already directly inside the <text> element (for example a note on a word
or phrase).
Insert a new element type among the <subtitle> section's valid subnodes,
named <comment> that has exactly the same characteristics of the <text>
element except that it will not be visualized during script playback.
And how are you going to do the same with karaoke and the other
<subtitle> child types?
Saying "that has exactly the same characteristics of the <text> element"
is not good IMO - it means you can't turn a karaoke into a comment
because <k> tags and some of the element attributes of karaoke are
forbidden in <text>.
Technically, you could have the visual effect of the latter by setting
an (new) attribute of the element (for example visibility="hidden"), but
agreed, in this way the node stands a bit less out for a source reader.
This apprach also had the problem that a parser that does not understand
that attribute most likely thinks that it were a normal element and
displays it.
Your approach avoids all these problems. A parser that does not know
about the element <comment> has to ignore it (like all elements it does
not know). You don't create a mess with nesting. OK so far good.
But i would really not define it as "identical" to the <text> element.
Better make it "supports all attributes and child elements of all
children of <subtitle>". To mark a backup copy of an element i would
introduce one additional attribute for the <comment> element that
describes the node type it originally was.
Example
<comment element-type="karaoke"><k/>blah</comment>
<comment element-type="text">blah</comment>
<comment>generic comment with notes (not a disabled element of some
other type)</comment>
This way you know what turn the element back into once you want to
reenable it. You don't hhave to guess the old type from present
attributes or child elements. Ans still you can use one comment element
type for all subtitle child types.
No replies means "go on" (unmei?).
Does this mean "you, unmei, should especially comment on it" ?
Or does it mean "you, unmei, are the one that has to implement it"?
If it is the former, ok, i commented :)
If it is the latter, no, im not the one having to do anything. At least
not in pixifier. If there is a new node type, pixifier will ignore it.
And that is what it is supposed to do with <comments>, right? ;)
Unless you want me to write an API function "addCommentText" - but that
would really just be a function recieving the text and trashing it.
http://usf.corecodec.org
Other related posts:
