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

Here are responses to all but your second comment (on ttp:markerMode):

 

1.2 Document Example

<snip>

In Example Fragment - DFXP Styling, five four? style sets of
specifications are defined, with one set serving as a collection of
default styles.

 

Good catch. I've fixed in the editor's working copy.

 

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?

 

7.1.5 p

A p element represents a logical paragraph, serving as a transition
between block level and inline level formatting semantics.

Does this mean that there is an implicit line break between each p
element in the presentation of a collection of sibling p elements? This
appears to be the intention as illustrated by subtitles 6a / 6b and 9a /
9b in the Example Fragment - DFXP Layout - should it be more explicitly
stated?

 

This interpretation is already mandated by item (6) under 9.3.2 in
combination with mandated use of XSL 1.0 formatting semantics (i.e.,
interpretation of fo:block) as specified in the last paragraph of 9.3.2.

 

8.2.2 tts:backgroundColor

In the  Example Rendition - Background Color image, why does the green
area not extend the full font defined text height of the fragment? It
appears to be determined by the extents of the inline fragment plus some
small padding....

 

Good catch. It should extend to the bottom of the purple background of
the paragraph. I'll ask Geoff to update the image.

 

8.2.6 tts:displayAlign

The tts:displayAlign attribute is used to specify a style property that
defines the alignment of block areas in the block progression direction.

What are the implications for vertical presentation? Can you specify a
region as having a vertical orientation, such that display align for a
vertical region causes start and end alignment e.g



V

 

 

E

 

 

R

 

 

T

 

 

I

 

 

C

 

 

A

 

 

L

 

 

 

 

V

 

 

E

 

 

R

 

 

T

 

 

I

 

 

C

 

 

A

 

 

L

 

 

 

 

V

 

 

E

 

 

R

 

 

T

 

 

I

 

 

C

 

 

A

 

 

L





The tts:writingMode style property controls the interpretation of
before, after, start, and end labels. So, given tts:writingMode="tbrl",
the first example above would have tts:displayAlign="before", the second
tts:displayAlign="center", and the third tts:displayAlign="after".
"start" and "end" would be used as values for tts:textAlign (as usual)
to control, in this case, alignment in the vertical dimension (inline
progression dimension).

 

8.2.11 tts:fontStyle

 

Values:             normal | italic | oblique | reverse-oblique |
inherit 

 

oblique | reverse-oblique do not appear to be defined by XSL-FO - should
they be clarified here?

 

Good catch. I will add language in the text to cover this.

 

8.2.15 tts:origin 

 

In Example Fragment - Origin :- there is a spelling mistake ceqnter

 

Fixed in editor's copy.

 

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. 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.

 

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. Another way to handle, but using a simpler, yet manual
approach, would be to use multiple non-breaking spaces before "Come" and
"Please".

 

12.2.2 ttm:role

All values of ttm:role that do not start with the prefix x- are reserved
for future standardization.

 

I would suggest that to facilitate mapping to EIA-708 style captions,
the text function definitions of EIA-708 are added to the set of values
for the 'role' attribute. The text function definitions of EIA-708 are
identified by the following keywords:

*         dialogue - normal words spoken by the characters.

*         reproducedVoice - spoken audio heard by the characters coming
from a phone, radio, PA etc.

*         foreignDialogue - dialogue in a language other than the
primary language.

*         voiceover - narration or voice NOT heard by the characters.

*         audibleTranslation - voice of a translator NOT heard by the
characters.

*         subtitleTranslation - text showing a translation into the
primary language.

*         voiceQuality - a description of voice quality.

*         songLyrics - words being sung.

*         soundEffect - a description of a non-verbal sound or music
heard by characters.

*         music - a description of background music NOT heard by
characters.

*         expletive - an interjectory word or expression (possibly
profane or harsh).

*         hidden - text not intended to be displayed (reserved for use
by the subtitling service equipment or service provider).

 

I have an existing action to add these values. Thanks for the reminder.

 

 

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