- From: Glenn A. Adams <gadams@xfsi.com>
- Date: Thu, 17 Mar 2005 11:20:04 -0500
- To: <Johnb@screen.subtitling.com>, <public-tt@w3.org>
- Message-ID: <7249D02C4D2DFD4D80F2E040E8CAF37C03C353@longxuyen.xfsi.com>
_____ From: Johnb@screen.subtitling.com [mailto:Johnb@screen.subtitling.com] Sent: Thursday, March 17, 2005 11:01 AM To: public-tt@w3.org Subject: RE: Timed Text Authoring Format - Distribution Format Exchange Pr ofile (DFXP) Glenn, Just to bottom this thread.... The timing attributes were added to <tt/> to support timing on <set/> children of <region/> whose ancestors are <layout/>, <head/>, then <tt/>. I'm not exactly sure what you can do with timing in both the body and tt elements that cannot be achieved just in thebody element, but it was more of a question than an issue.... [GA] For one thing, you can express that <tt/> is a par timing container, and that <body/> is a seq timing container. You can also express that <tt/> establishes a larger timing window than <body/>, e.g., have a 2 hour duration for <tt/> but a 30 min duration for <body/> starting at some offset. As regards the mixed alignment line, it is an uncommon scenario (though not as uncommon as might be thought - since saving space is often an issue in subtitling). I guess XSL-FO is bound by preconceptions of the web-page as output - since, as you identify, support for such features exists in print oriented languages. Can the fo:inline-container object be used to support the mixed alignment line concept? [GA] No. In the absence of the ability to set text-alignment on a span, I think **my** most likely DFXP implementation of this behaviour would be to create a transparent region for the right aligned section and overlay it. This does however mean that explicit line breaks and careful authoring would be required, since otherwise collision would be almost certain to occur. [GA] The group already had discussed this matter in the past and had settled on this approach (overlaying regions) if one really wanted to do this. BTW - a conversion of DFXP into XSL-FO is a good validation of DFXP - but I would suggest that most practical conversions will be direct to the target distribution format. I.e. for me... DFXP to Teletext, or DFXP to Line21. [GA] Conversion from DFXP into XSL-FO is not mandated by DFXP; rather, the possibility of such a mapping is mandated (subject to certain extensions) in order to formalize the DFXP formatting/layout semantics model. The alternative would be that DFXP would have to fully specify a format/layout semantics model such as the CSS Box model or the XSL Area model. The WG felt that we should reuse as many existing W3C specifications as possible rather than re-inventing; as a consequence, we evaluated the use of both CSS and XSL FO models, and adopted the XSL FO model as our semantics, primarily based upon our perception that XSL FO had done a better job of formalizing layout and folding in internationalization support (note that much of this has also been adopted in subsequent CSS Level 3 work, but has not yet been promoted to REC; we preferred to work with XSL FO partly because it is finalized as a REC). best regards John Birch. -----Original Message----- From: Glenn A. Adams [mailto:gadams@xfsi.com] Sent: 17 March 2005 13:53 To: Johnb@screen.subtitling.com Cc: public-tt@w3.org Subject: RE: Timed Text Authoring Format - Distribution Format Exchange Pr ofile (DFXP) _____ From: Johnb@screen.subtitling.com [mailto:Johnb@screen.subtitling.com] Sent: Thursday, March 17, 2005 6:37 AM To: Glenn A. Adams Cc: public-tt@w3.org Subject: RE: Timed Text Authoring Format - Distribution Format Exchange Pr ofile (DFXP) 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? The timing attributes were added to <tt/> to support timing on <set/> children of <region/> whose ancestors are <layout/>, <head/>, then <tt/>. 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 createan 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? We base our basic formatting/layout semantics on XSL 1.0, which does not support text-align on inline-level formatting objects. The closest feature in XSL that would support this would be the use of inline margins, e.g., <fo:block text-align="end"> <fo:inline>Hello?</fo:inline> <fo:inline space-start.minimum="0px" space-start.maximum="200px" space-start.opt="200px">Come In!</fo:inline> <fo:character character="
"/> <fo:inline space-start.minimum="0px" space-start.maximum="200px" space-start.opt="200px">Please have a seat</fo:inline> </fo:block> Supporting this in DFXP would require introducing an equivalent of the space-* properties of XSL, which involves a level of complexity that may not be appropriate for this profile (and will certainly require discussion by the WG). If I were using TeX, I would handle by inserting an \hskip or \hfil command possibly with a \penalty command before or after to adjust line break precedence rules. 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! Thisapproach 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! I suspect this is what you will end up doing in DFXP as well. 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] 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/ 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 16:20:04 UTC