W3C home > Mailing lists > Public > public-tt@w3.org > March 2005

RE: Timed Text Authoring Format - Distribution Format Exchange Pr ofile (DFXP)

From: <Johnb@screen.subtitling.com>
Date: Thu, 17 Mar 2005 11:36:41 -0000
Message-ID: <11E58A66B922D511AFB600A0244A722EE57D83@NTMAIL>
To: gadams@xfsi.com
Cc: public-tt@w3.org
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 2 November 2009 22:41:32 GMT