Timed Text Working Group Teleconference -- 05 Sep 2013

<trackbot> Date: 05 September 2013

<scribe> scribeNick: nigel

<glenn> http://www.w3.org/AudioVideo/TT/tracker/agenda

http://www.w3.org/wiki/TimedText/tpac

action-190

<trackbot> action-190 -- Thierry Michel to Will create a wiki for the face-to-face meeting -- due 2013-08-15 -- OPEN

<trackbot> http://www.w3.org/AudioVideo/TT/tracker/actions/190

<glenn> close action-190

<trackbot> Closed action-190.

actino-184

action-184

<trackbot> action-184 -- Thierry Michel to Check with Angel if Monday/Friday is ok for TPAC 2013 -- due 2013-08-01 -- OPEN

<trackbot> http://www.w3.org/AudioVideo/TT/tracker/actions/184

close action-184

<trackbot> Closed action-184.

face to face at TPAC

glenn: profiles is likely to be a popular topic for discussion.

<tmichel> TTwG is registered for monday and Friday at TPAC

<tmichel> http://www.w3.org/2013/11/TPAC/#GroupSchedule

glenn: folk should add items for discussion onto that subpage of the wiki for consideration by sean on his return

mike: add IANA registration to discussion topics

action-192

<trackbot> action-192 -- Mike Dolan to Work with phillipe to deal with IANA submission -- due 2013-08-29 -- OPEN

<trackbot> http://www.w3.org/AudioVideo/TT/tracker/actions/192

plh: will seek registration today or tomorrow and proceed with this action

glenn: important to use the content of the editorial draft for resubmission.

plh: will use that.

action-88

<trackbot> action-88 -- Philippe Le Hégaret to Make sure the TTML media type is properly registered for Issue-175. -- due 2013-07-31 -- OPEN

<trackbot> http://www.w3.org/AudioVideo/TT/tracker/actions/88

glenn: can close when registration process is finished.
... also close action 192 when that happens

close action-192

<trackbot> Closed action-192.

action-194

<trackbot> action-194 -- Glenn Adams to Move "120% of" from current ed text in 8.2.12 into informative note as recommendation to presentation processor implementers -- due 2013-09-05 -- PENDINGREVIEW

<trackbot> http://www.w3.org/AudioVideo/TT/tracker/actions/194

<glenn> https://dvcs.w3.org/hg/ttml/raw-file/default/ttml1/spec/ttml1.html#style-attribute-lineHeight

glenn: informative note in TTML1 is normative in draft for TTML2
... does this meet nigel's concern?

nigel: yes, you could also add that it is intended to be normative in TTML2, but not necessary.

mike: agree no need to add the extra note.

close action-194

<trackbot> Closed action-194.

action-197

<trackbot> action-197 -- Glenn Adams to Check whether issue-173 has already been dealt with -- due 2013-09-05 -- PENDINGREVIEW

<trackbot> http://www.w3.org/AudioVideo/TT/tracker/actions/197

<glenn> iissue-173

<glenn> issue-173

<trackbot> issue-173 -- presentation semantics of control characters and other unmapped characters -- pending review

<trackbot> http://www.w3.org/AudioVideo/TT/tracker/issues/173

glenn: reviewed issue-173 and believes no action needed to edit spec now. marked as pending review.

close issue-173

<trackbot> Closed issue-173.

close action-197

<trackbot> Closed action-197.

action-195

<trackbot> action-195 -- Pierre-Anthony Lemieux to Proposing resolution to multiple choices for minimum euclidean distance -- due 2013-09-05 -- OPEN

<trackbot> http://www.w3.org/AudioVideo/TT/tracker/actions/195

nigel: do we need an absolute value reference rather than the term 'highest'?

pal: yes we can improve that sentence

glenn: i.e. round up not down?

pal: yes

glenn: this raises the issue of tracker not generating notifications on changes to actions or issues.

thierry: unfortunately there is no such feature. For new actions an email is sent, but not when the status changes. Will check re new comments.

glenn: also requested this feature on the AC list recently. In the meantime we'll have to manually review actions and issues.

thierry: I understand the issue. I hope sysreq knows about this. I will check this is on the tracker page list.

<glenn> action thierry to check if feature request for tracker notifications on action/issue new comment or status change has been added to requested feature list

<trackbot> Created ACTION-198 - Check if feature request for tracker notifications on action/issue new comment or status change has been added to requested feature list [on Thierry Michel - due 2013-09-12].

glenn: phillipe, we're close to packaging TTML1 with editorial changes since the PER so you can start the publishing process.
... guidance on that, e.g. a target date, would be useful.

plh: need to close the loop with IANA and then get director's approval for publishing the recommendation. Any changes since the end of the last review?

glenn: yes, a variety of editorial changes, documented here:

<glenn> https://dvcs.w3.org/hg/ttml/raw-file/default/ttml1/spec/ttml1-changes.html

glenn: this lists changes since the PER was published, which all basically resolve comments made on PER or in working group review.

action-196

<trackbot> action-196 -- Pierre-Anthony Lemieux to Check proposed resolution to issue-159 in relationship to issue-231 and issue-229 -- due 2013-09-05 -- OPEN

<trackbot> http://www.w3.org/AudioVideo/TT/tracker/actions/196

issue-231

<trackbot> issue-231 -- Individual character rotation -- open

<trackbot> http://www.w3.org/AudioVideo/TT/tracker/issues/231

pal: it looks like the proposed resolution to issue-159 solves issue-231 as well

glenn: was the request intended to support arbitrary angles or just 90 degrees either way?

pal: 90 degrees only.

glenn: the values in issue-159 were mixed sideways and upright where sideways could be clockwise or anti-clockwise depending on the block progression in vertical mode
... and the writing mode. There are use cases for both directions, but they are effectively controlled by the writing mode.
... CSS3 defines two additional modes: sideways-left and sideways-right which allow the direction to be set independently of the writing mode.

pal: I think this matches the SMPTE requirement, i.e. individual rotation of each character left or right by 90 degrees.

glenn: the other issue is rotation around the centre of the glyph. In general rotation is around the origin of the glyph rather than the centre.
... this depends also on whether the baseline is horizontal or vertical.

pal: 'around its centre' really means that each glyph should be rotated individually so we need not worry about that.

issue-159

<trackbot> issue-159 -- Text orientation in I18n script processing -- pending review

<trackbot> http://www.w3.org/AudioVideo/TT/tracker/issues/159

<glenn> issue-159: glenn to add sidewaysLeft and sidewaysRight values

<trackbot> Notes added to issue-159 Text orientation in I18n script processing.

<glenn> issue-159: see also issue-231

<trackbot> Notes added to issue-159 Text orientation in I18n script processing.

pal: need to wait for Sean to confirm if this resolves issue-159
... issue-229 seems different from issue-231 and issue-159. It is instead of glyph rotation concerned with changing the progression direction.

<glenn> issue-229: glenn thinks this isn't related to issue-159, so sean needs to elaborate if he thinks otherwise

<trackbot> Notes added to issue-229 Mixed vertical-horizontal progression direction.

pal: so the resolution to issue-159 will not resolve issue-229

close action-196

<trackbot> Closed action-196.

<mike> I need to drop for this week. Hear everyone next week.

issue-170

<trackbot> issue-170 -- Section 5.2 para 8 is vague regarding optionality of specifying profile in case where profile is negotiated/determined by 'document interchange process' -- pending review

<trackbot> http://www.w3.org/AudioVideo/TT/tracker/issues/170

action-170

<trackbot> action-170 -- Glenn Adams to Create issue to remove "(in pixels)" from new definition of computed cell size -- due 2013-07-04 -- CLOSED

<trackbot> http://www.w3.org/AudioVideo/TT/tracker/actions/170

close issue-170

<trackbot> Closed issue-170.

issue-173

<trackbot> issue-173 -- presentation semantics of control characters and other unmapped characters -- closed

<trackbot> http://www.w3.org/AudioVideo/TT/tracker/issues/173

issue-176

<trackbot> issue-176 -- Adding support for extent and origin attributes on block elements -- pending review

<trackbot> http://www.w3.org/AudioVideo/TT/tracker/issues/176

glenn: the problem with putting origin and extent directly on p or div could be misinterpreted as meaning the size of the allocation rectangle or the content rectangle to apply
... this is the case if for example in CSS you specify a width for a block element then it is interpreted as a declaration of how much allocation area to assign to the block and not
... a declaration of an absolutely positioned region in which to put the block.
... my proposal, subject to Sean's review, is to add an inline region, like an inline animation element, as a child of a block element.
... This is a shorthand for defining the region in the header and referring to it via IDs.
... this is one for the agenda in the f2f meeting. Want to keep as pending review for the time being.
... in the TTML2 editorial draft, under the terminology section 2.2 I have added new definitions for inline region and out of line region, also incidentally inline and out of line animation,
... I also modified the syntax for the div and p elements in 7.1.4 and 7.1.5 to add to its content models an optional layout class immediately after the animation class.
... Under the section 9.3 on layout semantics I have pencilled in a new subsection called Inline Regions 9.3.2 which needs to be filled in.
... Minor changes are likely in 9.3.3 as a consequence.
... This technique will minimise the changes to the semantics of the parent synchronic document construction and layout processing.
... The original idea came from a desire to serialise content in a way that doesn't require pre-defining all of the regions up-front and instead allow them to be defined coincident with the block element

<glenn> issue-176: nigel asks about whether region needs full specification or can be inherited

<trackbot> Notes added to issue-176 Adding support for extent and origin attributes on block elements.

glenn: we could specify on the root or layout element the styles etc to inherit in inline or out of line regions

<glenn> ACTION: glenn to create new issue about need for region elements to obtain inherited styles, possibly from layout or tt element [recorded in http://www.w3.org/2013/09/05-tt-minutes.html#action01]

<trackbot> Created ACTION-199 - Create new issue about need for region elements to obtain inherited styles, possibly from layout or tt element [on Glenn Adams - due 2013-09-12].

issue-178

<trackbot> issue-178 -- initial values and style set calculations are unclear, especially for transformable attributes -- pending review

<trackbot> http://www.w3.org/AudioVideo/TT/tracker/issues/178

issue-183

<trackbot> issue-183 -- semantics of using profile in a document -- pending review

<trackbot> http://www.w3.org/AudioVideo/TT/tracker/issues/183

issue-193

<trackbot> issue-193 -- Address SMPTE Questions for Region, Border, etc. related to character edge attributes -- pending review

<trackbot> http://www.w3.org/AudioVideo/TT/tracker/issues/193

issue-203

<trackbot> issue-203 -- Add ttp:version to allow author to indicate which version of TTML content was created for. -- pending review

<trackbot> http://www.w3.org/AudioVideo/TT/tracker/issues/203

glenn: this now implemented in TTML2 draft

pal: is the namespace going to change for TTML2?

glenn: there's no plan to change it. The namespace is defined as being extensible under control of the TTWG.

pal: so this would be a way to tell if a TTML document conforms to TTML1 or TTML2?

glenn: reads draft text.
... this is intended to be separate from profile conformance and definition. It should have no mandatory normative role in processing.

nigel: might this be used for behaviour changes in processors that don't have defined profiles?

glenn: there are two questions there: firstly profile mechanisms and secondly the definition of new profile features to cover changes in behaviour
... For the time being we can't concretely answer this - we may in the end take it out as being unnecessary or add more semantics that trigger off its value. For future discussion.
... It would be useful to add this to the discussion list for the TPAC meeting.

<glenn> ACTION: glenn to add ttp:version to items for possible F2F agenda [recorded in http://www.w3.org/2013/09/05-tt-minutes.html#action02]

<trackbot> Created ACTION-200 - Add ttp:version to items for possible f2f agenda [on Glenn Adams - due 2013-09-12].

pal: we have three mechanisms now: namespace, content profile and version. It would be good to understand the interplay between those three.

glenn: we can not redefine existing profile labels; we can only add new profiles. Similarly with features.

pal: will the TTML2 profiles unambiguously define the version used?

glenn: no - I could create a TTML2 version document that requires dfxp-full or dfxp-presentation so they're orthogonal concepts

pal: so ttp:version is completely informative because the processor only needs to know which normative provisions were used.
... unless we're really clear people will come up with crazy ways to process/reject documents using faulty logic

glenn: we don't know yet if we will not define normative semantics around the use of a version defined this way. For example we may change basic conformance processing changes
... we are also making changes about concrete syntax - in version 1 there were recommendations that will be normative in v2. Similarly with time expressions.
... I can't predict where we'll end up. In SVG it seems to be useful. Similarly in XML headers, and by analogy it could be useful here.

nigel: there's one use case here that's clear - processors will need to know the TTML version to understand the profile mechanism if we change that.

pal: we can already use the profile mechanism.

glenn: we're thinking about declaring content profile independently of what's required by a processor. You could create a TTML2 document that declares conformance with a TTML1 profile and use
... a TTML1 profile for declaring what support a processor requires.

pal: That's still unambiguous without needing version.

glenn: I don't expect to mandate that a TTML2 document declares its conformance with a particular profile
... If it's pure metadata we can consider removing it. I suggest you submit an issue for this - could be to change it to ttm:version instead of ttp:version.
... I suggest we need to think more about this.

pal: I will file an issue.
... we need to specify very clearly how we communicate semantics and version conformance.

close issue-203

<trackbot> Closed issue-203.

issue-204

<trackbot> issue-204 -- TTML.next should probably be 2.0, not 1.1 -- pending review

<trackbot> http://www.w3.org/AudioVideo/TT/tracker/issues/204

close issue-204

<trackbot> Closed issue-204.

issue-208

<trackbot> issue-208 -- Define behavior for unsupported colors. -- pending review

<trackbot> http://www.w3.org/AudioVideo/TT/tracker/issues/208

<tmichel> I am sorry I must leave to an appointement ...

<tmichel> Bye.

nigel: unsure how this is resolved by the closest color calculation
... it doesn't maintain contrast where indicated, so foreground and background colors could end up the same where contrast is required.

close issue-208

<trackbot> Closed issue-208.

issue-225

<trackbot> issue-225 -- tts:fontSize as percentage of container dimensions -- pending review

<trackbot> http://www.w3.org/AudioVideo/TT/tracker/issues/225

<glenn> https://dvcs.w3.org/hg/ttml/raw-file/tip/ttml2/spec/ttml2.html#style-value-length

pal: likes the idea of an explicit viewport size relationship mechanism
... there are now two ways to do this. Either use cell resolution or this one which is really explicit.

glenn: that's correct. If it happens that an em square matches a cell size then there's a third way.

nigel: when calculating vmin or vmax should non-square aspect ratios be taken into account?

glenn: the width and height of the root container region turns into a specific value in TTML pixels, not related to aspect ratio. The pixel aspect ratio parameter comes into play independently.

action nigel to check if pixel aspect ratio makes a difference when performing the min and max comparison

<trackbot> Created ACTION-201 - Check if pixel aspect ratio makes a difference when performing the min and max comparison [on Nigel Megitt - due 2013-09-12].

pal: what should the preferred way of achieving this be, for document authors?

<glenn> issue-225: add comment under tts:fontSize indicating that vw/vh could also be expressed using cell (c) units

<trackbot> Notes added to issue-225 tts:fontSize as percentage of container dimensions.

<glenn> action-201: is associated with issue-225

<trackbot> Notes added to action-201 Check if pixel aspect ratio makes a difference when performing the min and max comparison.

issue-227

<trackbot> issue-227 -- <p> fade-up and –down -- pending review

<trackbot> http://www.w3.org/AudioVideo/TT/tracker/issues/227

glenn: describes new animation feature that addresses both fade up and fade down and other use cases.

pal: this appears to resolve the opacity requirement. There's another issue open relating more closely to animation requirements.

glenn: animation is needed for the opacity requirement and could not be with set.

close issue-227

<trackbot> Closed issue-227.

glenn: won't be able to attend next week

nigel: won't be able to attend next week or the week after.

pal: won't be able to attend the 19th.

<glenn> regrets for nigel and glenn for Sep 12

<glenn> regrets for nigel and pal for Sep 19

<glenn> note that IBC overlaps Sep 12 so others may be absent

trackbot, end meeting

- DRAFT -

Timed Text Working Group Teleconference

05 Sep 2013

Attendees

Contents

face to face at TPAC

Summary of Action Items

Scribe.perl diagnostic output