Disposition of comments for the Timed Text Working Group

Single page view

In the table below, red is in the WG decision column indicates that the Working Group didn't agree with the comment, green indicates that a it agreed with it, and yellow reflects an in-between situation.

In the "Commentor reply" column, red indicates the commenter objected to the WG resolution, green indicates approval, and yellow means the commenter didn't respond to the request for feedback.

CommentorCommentWorking Group decisionCommentor reply
LC-2976 Andreas Tai <tai@irt.de> (archived comment)
4.1 General
From IMSC 1:
"In addition, the Text Profile subtitle document SHOULD be associated
with the Image Profile subtitle document such that, when image content
is encountered, assistive technologies have access to its corresponding
text form."

As far as I could see there is no defined method to link a Text profile
document to an Image Profile document through an element in the document
themselves. So it may helpful to add that his has to be done through an
external setting.
We have added the sentence "The method by which this association is made is left to each application" to the revised Section 5.1 at https://dvcs.w3.org/hg/ttml/raw-file/tip/ttml-ww-profiles/ttml-ww-profiles.html yes
LC-2973 Andreas Tai <tai@irt.de> (archived comment)
It would be good to give more emphasis that a presentation processor
should not reject a document "with foreign namespace elements or

Examples for possible edits:
a) "...*The subtitle document SHALL be processed but* such elements and
attributes may be ignored by the presentation processor or
transformation processor."

b) "A *conforming* subtitle document may contain elements and attributes
that are neither specifically permitted nor forbidden by a profile."

It may be a good idea to align this paragraph with the section in TTML
5.3.2. As far as I can see it is not explicitly forbidden to use the
IMSC namespaces for extensions. So either in IMSC 1 5.3 or somewhere
else an additional constraint may be added.
We have permitted ("may") elements and attributes that are not explicitly permitted or prohibited by a profile, and aligned with TTML1 the wording regarding namespace mutability. See revised Section 6.2 and last paragraph of Section 6.3 at https://dvcs.w3.org/hg/ttml/raw-file/tip/ttml-ww-profiles/ttml-ww-profiles.html yes
LC-2974 Andreas Tai <tai@irt.de> (archived comment)
5.10 Features (Common features) #length-cell feature
IMSC 1 states that the #length-cell feature shall not be used. The
line-padding extension uses the cell metric. Not sure if this causes a
problem. On the one hand the extensions are "outside" of TTML 1 on the
other hand they use the cell metric as defined by TTML 1.

5.10 Features (Common features) -#length feature
The #length feature includes the support of the "c" metric
(http://www.w3.org/TR/ttml1/#feature-length). So you may add a
restriction here.
Exception made to #length-cell for ebutts:linePadding. See revised #length-cell constraint at https://dvcs.w3.org/hg/ttml/raw-file/tip/ttml-ww-profiles/ttml-ww-profiles.html yes
LC-2975 Andreas Tai <tai@irt.de> (archived comment)
3. Conformance
The term "subtitle document" is not defined in IMSC 1 and TTML 1 but
used frequently in a normative context. It may be helpful to define it
in Section 2.
We have replaced the term "subtitle document" with "Document Instance", which is a defined term, at https://dvcs.w3.org/hg/ttml/raw-file/tip/ttml-ww-profiles/ttml-ww-profiles.html yes
LC-2977 Andreas Tai <tai@irt.de> (archived comment)
5.7.3 itts:forcedDisplay - value matrix
In general I would welcome a bit more text about the details of value
combinations. There is text for "displayForcedMode=true,
itts:forcedDisplay=false" but not for "displayForcedMode=true,
itts:forcedDisplay=true". Maybe a matrix would be helpful with
tts:visibilily (visible, hidden), displayForcedDisplay parameter (true,
fase) annd itts:forcedDisplay (true, false).

5.7.3 itts:forcedDisplay - Informative Note
The first note could possibly be improved if it is noted that this has
an effect only if a "non-transparent background" is directly defined for
the region (e.g. in most cases I have seen for the usage of EBU-TT-D the
background will be applied through the content elements).
See revised second paragraph of Section 6.7.3 and Note 1 at https://dvcs.w3.org/hg/ttml/raw-file/tip/ttml-ww-profiles/ttml-ww-profiles.html

While NOTE 1 might apply only when non-transparent background is used on a region, the intent of the note is broader: warning authors that making all elements within a region hidden does not necessarily hide the region.
LC-2978 Andreas Tai <tai@irt.de> (archived comment)
5.7.4 ittm:altText - Optionality of attributes
For the XML Representation you may repeat the part from 2.3 TTML 1 where
it states that bold-face attribute names are required and the others are
optional (personally I would prefer the keyword "REQUIRED" after the
attribute name). Without that it may not be clear if the attributes are
optional or required.

5.7.4 ittm:altText - Typo
End of "Note:": Replace ". ." with "."
The specification now explicitly references the documentation conventions of TTML 1.

See "Documentation Conventions" section and revised Section 5.7.4 at https://dvcs.w3.org/hg/ttml/raw-file/tip/ttml-ww-profiles/ttml-ww-profiles.html
LC-2979 Andreas Tai <tai@irt.de> (archived comment)
5.10 Features (Common)
#timing: It may be helpful to describe what you mean with the same
syntax (e.g. is 00:00:01, 00:00:01.0 and 00:00:01.000 a different syntax?)
See revised #timing constraint at at https://dvcs.w3.org/hg/ttml/raw-file/tip/ttml-ww-profiles/ttml-ww-profiles.html yes
LC-2980 Andreas Tai <tai@irt.de> (archived comment)
6.3 Features (Text Profile)
#textAlgin: A reference to the definition of the "defaultRegion" in TTML
1 would be helpful. I assume that ony the TTML experts know what the
defaultRegion is (e.g. some implementers gave in a TTML document
"defaultRegion" as value for xml:id).
Default Region is now a defined term at https://dvcs.w3.org/hg/ttml/raw-file/tip/ttml-ww-profiles/ttml-ww-profiles.html yes
LC-2981 Andreas Tai <tai@irt.de> (archived comment)
8.2 Reference Fonts
A reference to presentation processors and transformation processors may
be helpful. A presentation processor SHALL lay out the text according to
the metrics and a transformation processor should use this metrics for
any calculation.
See clarified text at Section 7.3 at https://dvcs.w3.org/hg/ttml/raw-file/tip/ttml-ww-profiles/ttml-ww-profiles.html yes
LC-2968 Simon Hailes <Simon.Hailes@screensystems.tv> (archived comment)
Dear all,

As the public review period nears its end, I'd like to highlight a positive addition to the imsc spec to facilitate image based subtitling.

A basic image based subtitling script file will normally contain:
Image name/url
Image position
Optionally, image size may be specified, and the overall size of the canvas may be specified.

Imsc by inclusion of backgroundimage just about allows for these. But the specification of image size and position is very convoluted.

For image based subtitling, position and size of the image in relation to the video is paramount.

It would be really good if tts:origin and tts:extent were enabled on div for image based subtitling; at the moment I cannot see how they are allowed. Please correct me and include a sample in the document if I am wrong.
It would also be good to be explicit about image scaling. Ideally, the image should be scaled to match the specified image extent (with some notes that if this scaling is close to 1:1 after taking into account player size, etc., then the decoder may prefer not to scale to retain quality).

This modification would make image based subtitling in imsc a relatively simple and easy to understand construct. It makes it almost as simple to write as current extant image + script formats, and (I would imagine) make it relative easy to parse.

Modified example from http://en.wikipedia.org/wiki/User:Cwmwenallt/SMPTE-TT (i'm not claiming this was correct to start with!).

<tt xmlns:smpte="http://www.smpte-ra.org/schemas/2052-1/2010/smpte-tt"
<region xml:id="imageRegion" tts:color="transparent" tts:origin="0% 0%" tts:extent="100% 100%" >
<set begin="0.19305s" end="0.21581s" tts:origin="0px 2px" tts:extent="4px 8px" />
<set begin="5.89876s" end="8.09467s" tts:origin="230px 50px" tts:extent="243px 58px" />
<set begin="8.20106s" end="10.1922s" tts:origin="202px 50px" tts:extent="302px 64px" />
<set begin="10.3032s" end="12.2943s" tts:origin="180px 402px" tts:extent="341px 32px" />
<div region="imageRegion">
<div begin="0.19305s" end="0.21581s" smpte:backgroundImage="Subtitles_EN/SPU0.png">
<p>[Example SMPTE-TT file]</p>
<div begin="5.89876s" end="8.09467s" smpte:backgroundImage="Subtitles_EN/SPU1.png">
<p>Hello Wikipedia</p>
<div begin="8.20106s" end="10.1922s" smpte:backgroundImage="Subtitles_EN/SPU2.png">
<p>This is a basic Example</p>
<div begin="10.3032s" end="12.2943s" smpte:backgroundImage="Subtitles_EN/SPU3.png" >
<p>of pop on style captioning with preformatted background images</p>

Becomes (I did not add the required namespace):

<tt xmlns:smpte="http://www.smpte-ra.org/schemas/2052-1/2010/smpte-tt"
<region xml:id="imageRegion" tts:color="transparent" tts:origin="0% 0%" tts:extent="100% 100%" >
<div region="imageRegion">
<div begin="0.19305s" end="0.21581s" smpte:backgroundImage="Subtitles_EN/SPU0.png" tts:origin="0px 2px" tts:extent="4px 8px" >
<ittm:altText>[Example SMPTE-TT file]</ittm:altText>
<div begin="5.89876s" end="8.09467s" smpte:backgroundImage="Subtitles_EN/SPU1.png" tts:origin="230px 50px" tts:extent="243px 58px" >
<ittm:altText>Hello Wikipedia</ittm:altText>
<div begin="8.20106s" end="10.1922s" smpte:backgroundImage="Subtitles_EN/SPU2.png" tts:origin="202px 50px" tts:extent="302px 64px" >
<ittm:altText>This is a basic Example</ittm:altText>
<div begin="10.3032s" end="12.2943s" smpte:backgroundImage="Subtitles_EN/SPU3.png" tts:origin="180px 402px" tts:extent="341px 32px" >
<ittm:altText>of pop on style captioning with preformatted background images</ittm:altText>

Best regards,

Simon Hailes.
p.s. please reply direct if you have any comments/questions. I don't monitor the mailing lists....

Simon Hailes | Chief Technology Officer | Screen
Main Line : +44 1473 831700 | Ext : 2161 |Mobile : +44 7802 759311 | Fax : +44 1473 830078
Simon.Hailes@screensystems.tv<mailto:Simon.Hailes@screensystems.tv> | www.screensystems.tv<http://www.screensystems.tv> | https://twitter.com/screensystems

Visit us at
SMPTE Annual Technical Conference, Loews Hollywood Hotel, Stand 107, October 21-23
Languages & the Media, Hotel Radission Blu, Berlin, November 5-7

P Before printing, think about the environment

This message may contain confidential and/or privileged information. If you are not the intended recipient you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. Screen Subtitling Systems Ltd. Registered in England No. 2596832. Registered Office: The Old Rectory, Claydon Church Lane, Claydon, Ipswich, Suffolk, IP6 0EQ
An objective of IMSC 1 is to leverage as much as possible existing TTML 1 implementations, and IMSC 1 is as such based on TTML 1. Allowing tts:extent and tts:origin to have a meaning on elements other than <region> would be a significant departure from this objective. Moreover it is straightforward to create as many <region>s as there are unique combinations of origin and extent across subtitles/captions.

The intent is to include such a feature in TTML 2 (see issue 176)

We have added an informative note at Section 8.3 of https://dvcs.w3.org/hg/ttml/raw-file/tip/ttml-ww-profiles/ttml-ww-profiles.html describing the use of multiple <region> elements to achieve positioning of individual subtitle/caption.
LC-2967 <chaals@yandex-team.ru> (archived comment)

NRGA(Ii)= (width of Ii ) ? height of Ii )
- there appears to be an excess right parethensis

An example document, or several, would be a very helpful addition.

Charles McCathie Nevile - web standards - CTO Office, Yandex
chaals@yandex-team.ru - - - Find more at http://yandex.com
We have:
- removed the excess right parethensis in NRGA(Ii) at 8.1.4
- added a complete example document

These changes are in the editor's draft at https://dvcs.w3.org/hg/ttml/raw-file/tip/ttml-ww-profiles/ttml-ww-profiles.html
LC-2982 Andreas Tai <tai@irt.de> (archived comment)
Annex B Forced Content
A code example may be an illustrative help for the shown use case.
We have added Example 4 at https://dvcs.w3.org/hg/ttml/raw-file/tip/ttml-ww-profiles/ttml-ww-profiles.html yes
LC-2969 chaals <chaals@yandex-team.ru> (archived comment)

3. Conformance

The document defines clearly that it uses the terms MUST, SHOULD, MAY and so on in line with RFC2119. This is good practice, and helps many spec users recognise what is meant. But it uses (beginning about the next line) SHALL throughout, which is undefined, and an uncommon word in modern english. I suggest replacing every instance of shall with must.
RFC 2119 specifies that 'shall' and 'must' have identical meanings.

We have added the term 'shall' to the list of RFC 2119 terms in the Section 4 Conformance at https://dvcs.w3.org/hg/ttml/raw-file/tip/ttml-ww-profiles/ttml-ww-profiles.html

We note also that Respec.js was recently updated to (a) recognize 'shall' and (b) include it in the RFC 2119 boilerplate prose.
LC-2970 chaals <chaals@yandex-team.ru> (archived comment)

The definitions of each item here would be far clearer with an actual example.
It would be very helpful to choose a single formalism for syntax.

The example of an attribute which *I think* can be either

would be more helpful if it were described much as the following attribute, which says what elements it applies to, what values it can take, etc.
We have:

- added a "document convention" section to IMSC1
- added one XML snippet example for each feature introduced by IMSC 1

These are in the editor's draft at: https://dvcs.w3.org/hg/ttml/raw-file/tip/ttml-ww-profiles/ttml-ww-profiles.html
LC-2971 cyril Concolato <cyril.concolato@telecom-paristech.fr> (archived comment)
Hi Pierre,

While reading the draft I noticed that the SMPTE spec does not have a
direct link to the document, which is not really convenient for readers.
Could you add it?

We added the link https://www.smpte.org/standards to the [ST2052-1] reference at https://dvcs.w3.org/hg/ttml/raw-file/tip/ttml-ww-profiles/ttml-ww-profiles.html yes
LC-2983 Peter Cherriman <peter.cherriman@rd.bbc.co.uk> (archived comment)
Dear Sir or Madam,

As a follow-up to my earlier email, the DVB TM-SUB group (which I chair)
met this morning to collate comments on your latest working draft of IMSC1.

The IMSC1 specification has been reviewed by some of the DVB members.
The common view
was that IMSC1 is a candidate technology for our next subtitle
specification and it provides
a compatible update from EBU-TT-D which is specified in DVB's profile of

Therefore the TM-SUB group requests that W3C endeavour to maintain IMSC1
as a super-set of EBU-TT-D.

The group noted the following restrictions that needed to be applied to
EBU-TT-D to achieve IMSC1 compatibility: UTF8 encoding and a maximum of
4 simultaneous regions.

Peter Cherriman (DVB TM-SUB chairman)
Dear Peter,

W3C TTWG thanks DVB TM-SUB for its review of IMSC1 and looks forward to a continued collaboration.

Very sincerely,

Nigel Megitt [W3C TTWG co-chair]

Developed and maintained by Dominique Hazaël-Massieux (dom@w3.org).
$Id: index.html,v 1.1 2017/08/11 06:39:31 dom Exp $
Please send bug reports and request for enhancements to w3t-sys.org