- From: <Johnb@screen.subtitling.com>
- Date: Thu, 17 Mar 2005 11:36:41 -0000
- To: gadams@xfsi.com
- Cc: public-tt@w3.org
- Message-ID: <11E58A66B922D511AFB600A0244A722EE57D83@NTMAIL>
Glenn, Thanks for the speedy reply - some more comments inline :-) best regards John Birch -----Original Message----- From: Glenn A. Adams [mailto:gadams@xfsi.com] Sent: 16 March 2005 17:55 To: Johnb@screen.subtitling.com Cc: public-tt@w3.org Subject: RE: Timed Text Authoring Format - Distribution Format Exchange Pr ofile (DFXP) 7.1.1 tt If begin and (or) end attributes are specified on the tt element, then they specify the beginning and (or) ending points of a time interval for a document instance in relationship with some external application or presentation context. The temporal begin and end points determined by an external application or presentation are referred to subsequently as the external time interval. Is it necessary to have begin and (or) end attributes for both the tt element and the body element? Could this be simplified so that begin and (or) end is only specified on the tt element? No. Neither is required. Is there something in the text that led you to infer that both were required? Ahhh.... I didn't make myself clear.... What I meant to say was.... does the DXFP specification need to support a begin / end attribute on both the tt element and the body element? Would it be possible to simplify the DXFP **specification** by removing timing attributes from one of these elements, since I cannot see any situation that requires both elements to have timing attributes. IMHO a document using timing attributes on both tt and body can be **equivalently** represented by a single set of timing attributes on just one of these elements. Am I missing something? What is gained by having timing attributes at both levels in the document hierarchy, given that both tt and body can only occur once in a document instance? 8.2.19 tts:textAlign Applies to: p Can we allow tts:textAlign to apply to span as well. Otherwise, I don't believe it is possible to have: Hello? Come In! Please have a seat No. You cannot do this in a single paragraph. You would have to overlay two regions on top of one another and have one of them use a transparent background. A bit ugly - and prone to problems with text collisions which I would hope to avoid! Imagine if the second phrase were modified to read "Come In! I've been waiting to meet you." Text alignment (in the inline progression dimension) applies to the positioning of line areas within a block area. A text alignment on a span would always pertain individually to each inline area produced by the span, and since each such inline area is bounded by glyph areas at both start and end edges, there would be no extra room in which to move those glyph areas within the inline area. Is there no way to create an inline block area that fills to the end of the line (region)? I am assuming that the DXFP for the above would be: <p id="subtitle5" begin="10:00:00:00" end="10:00:05:00" style="rightaligned"> <span tts:textAlign="left"> Hello? </span> <span begin="10:00:02:00"> Come In!</br>Please have a seat </span> </p> Or: <p id="subtitle5" begin="10:00:00:00" end="10:00:05:00" style="rightaligned"> <span tts:textAlign="left"> Hello? </span> <span begin="2:00"> Come In! </br> </span> </p> <p id="subtitle 6 " begin="10:00:02:00" end="10:00:05:00" style="rightaligned"> Please have a seat </p> So why can the first span not create an inline area that is left aligned within the region and contains the text Hello?, terminating in area just after the ? When the second span activates - can the inline area generated not stretch from the previous inline area until the end of the line - there is an explicit break in the first example and an implicit break in the second? Another, but more complex means for handling this would be to introduce a construct or mechanism that works similar to TAB in traditional word processors. Ugghhhh! Really really Ugghhhh! I am not sure how you could use a tab construct, you would need to position the tab by knowing how long the rendered second phrase (the right aligned part) was - since the right aligned part would actually be left aligned to the tab. Another way to handle, but using a simpler, yet manual approach, would be to use multiple non-breaking spaces before "Come" and "Please". Ugghhhh! This approach would not work for regions that were specified with relative (proportionate) sizes and would not achieve the same results for different font sizes (or indeed fonts). Admittedly, this is how the above effect is currently achieved though! Regards, Glenn _____ From: Johnb@screen.subtitling.com [mailto:Johnb@screen.subtitling.com] Sent: Wednesday, March 16, 2005 10:48 AM To: public-tt@w3.org Subject: RE: Timed Text Authoring Format - Distribution Format Exchange Pr ofile (DFXP) Glenn, et al, I have a number of minor comments / questions regarding the draft that I have placed in the attached Word document. Apologies for using this format but it allows me to easily illustrate certain points regarding formatting without generating images. I have a couple of other points that I will make in separate emails. with best regards John Birch. -----Original Message----- From: Glenn A. Adams [ mailto:gadams@xfsi.com <mailto:gadams@xfsi.com> ] Sent: 14 March 2005 16:51 To: public-tt@w3.org Subject: Timed Text Authoring Format - Distribution Format Exchange Profile (DFXP) A new update of the Timed Text Authoring Format 1.0 - Distribution Format Exchange Profile (DFXP), is now available at [1]: http://www.w3.org/TR/2005/WD-ttaf1-dfxp-20050314/ <http://www.w3.org/TR/2005/WD-ttaf1-dfxp-20050314/> The TT WG solicits your comments on this new draft as soon as possible, as a very rapid turn-around is expected in order to publish a first Last Call (LC) draft. Please sent comments either to this list or, if you prefer privacy, to me directly. Regards, Glenn Adams
Received on Thursday, 17 March 2005 11:21:34 UTC