[usf-devel] Re: Comment events
- From: Luca Della Santina <lucads@xxxxxxxx>
- To: usf-devel@xxxxxxxxxxxxx
- Date: Sun, 14 Aug 2005 19:34:54 +0200
unmei wrote:
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).
As you explained very well, comments cannot be specified like Toff
proposed. We need to find a better way to do that.
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.
You're right, Comments must encapsulate all the avaible subtitle event
types, not just the <text> element.
What do you think about making the new comment element as a container (a
parent) for nodes we want to comment, like this:
Subtitle not yet commented:
<subtitle start="0:00:00.000" stop="0:00:05.000">
<text>Spoken sentence</text
<text>element we want to make as comment</text>
<image contet-type="inline" filename="foo.bar">Base64string</image>
<image contet-type="inline" filename="foo.bar">Base64string we want
to make as comment</image>
</subtitle>
becomes like this when commented:
<subtitle start="0:00:00.000" stop="0:00:05.000">
<text>Spoken sentence</text
<image contet-type="inline" filename="foo.bar">Base64string</image>
<comments>
<text>element we want to make as comment</text>
<image contet-type="inline" filename="foo.bar">Base64string we
want to make as comment</image>
</comments>
</subtitle>
This approach has the following advantages:
1) you can include any line type into comments (opened even for future
line types)
2) a parser that don't know about <comment> element simply ignores it
and all the children nodes of it.
3)it is really simple to comment-uncomment an element because you simply
move the node, the previous approach needed you to at least change the
node name
4) nodes that are commented do not need any modification (no
element-type="karaoke" or similar that needs more processing when
commenting-uncommenting)
What do you think about it?
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.
I was simply meaning: "let's discuss especially with you on this matter
and when a good solution comes out let's include even this feature in
the USF proposal".
Regarding of implementation, there is no need for pixifier to care about
comments. Comments are an editor-side and a pixishow-side feature:
In a subtitle editor they are very usefull for the reasons i presented
in my last email.
In PixiShow they can be treated as a "candy" and a new option can be
added like "show comments" that converts comments to dialogues on-the-fly.
Regards, Kaiousama.
http://usf.corecodec.org
Other related posts:
