Timed Text Working Group Teleconference -- 11 Nov 2013

<trackbot> Date: 11 November 2013

TTML profiles

<glenn> https://dvcs.w3.org/hg/ttml/raw-file/default/ttml2/design/TPAC2013-TTMLProfiles.pdf

<nigel> scribeNick: nigel

glenn: describes TTML1 Profiles
... using slides from link above
... Nobody has actually used the "used" value to my knowledge.
... Instead people just used "required"
... to mean both supported and enabled.

pal: do we know in practice how many documents include profile definitions inline?

glenn: no we don't know.

pal: sdp-us, cff-tt and ebu-tt don't.

nigel: can Profiles be combined when defined internally, externally or any combination?

glenn: any combination

nigel: Are external references required to be resolved?

glenn: they 'should' be resolvable but it's not a mandatory requirement

On the 'what's missing' slide

Profile Designator Proposal

Checking which issue or action is related to this problem

pal: creating an action for this

glenn: this designator is just a label, doesn't imply anything about schemas etc

hello plh

pal: this binds the profile with this URI, unambiguously

nigel: it's clear for linking profiles with labels but it's another different problem to define which profiles any particular document conforms to.

glenn: all this designator attribute does is allows the profile definition document to create a machine-readable label.

issue-297

<trackbot> issue-297 -- Include Profile Designator in Profile Definition Document -- raised

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

glenn: proposes that we complete these issues if there are no objections by December 1st

<glenn> PROPOSED RESOLUTION: to adopt @designator attribute on ttp:profile as described in presentation, to be finalized by DEC5

issue-266

<trackbot> issue-266 -- add ability for instance documents to declare what profile(s) it conforms to -- open

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

On slide Content Profile Proposal (2) tt:root -> tt:tt

<glenn> s/tt:root/tt:tt/ in the presentation

glenn: scope of ttp:validation is global for the whole document, and all referenced profiles.

pal: can you type an example of what it would look like to specify that a document conforms to multiple content profiles simultaneously?

nigel: have added reference to this proposal on issue-266

pal: that satisfies the requirement for specifying multiple conformant document content profiles.

glenn: there's another way too, a variant on it.

glenn: this allows nested definitions of a content profile.

pal: Based on the use cases I've heard of this goes well beyond the requirement.
... Can we document the reason behind the extra complexity?

glenn: this is the current mechanism. It can only take one URI not a list.

glenn: If we added a content profile that does something similar then we couldn't have a list.
... By using the more advanced mechanism this could reference multiple content profiles.

pal: have you considered extending the current mechanism to be a list, which would be backward compatibility

glenn: it sounds like a reasonable extension.
... One argument is that it facilitates adding in the profile features to the document.
... we often end up with multiple forms as shorthands, and this does have associated cost

pal: what about the idea of 'if you use content profile or profile attribute' you can't use the other.

glenn: we already have that in TTML1 in 5.2

group reviews current specification

glenn: it is currently well defined. The ttv verifier tool will warn if both are present, or neither.
... I view the attribute as a shorthand for the element.
... 2 proposals. First is to allow profiles and profile attributes to allow multiple designator.
... Second is to ensure that it's possible for a content profile definition to proscribe use of the profile element while requiring use of the profile attribute.

nigel: there's another issue in that people define profiles by behaviour within text in a specification document not just as ttml profile designators

pal: also interested in that.

glenn: are there any immediate objections?

nigel: this does appear to meet the needs of issue-266

glenn: this goes beyond as it adds validation semantics

nigel: we should be careful to avoid confusion in readers between optional/required feature designators and the validation action

<glenn> ACTION: glenn to consider also defining @validation on ttp:profile, in addition to (override) tt:tt [recorded in http://www.w3.org/2013/11/11-tt-minutes.html#action01]

<trackbot> Created ACTION-232 - Consider also defining @validation on ttp:profile, in addition to (override) tt:tt [on Glenn Adams - due 2013-11-18].

nigel: also we need to consider the validation scope - all profiles or per profile?

glenn: may need a validation 'none' on per profile validation to override

pal: what is the use case for requiring the processor to abort or not upon failing validation of a document?

glenn: we have two categories: transformation and presentation. Transformation processing is more likely to occur in a pipeline.
... a validation node may be required, to cause TTML to be removed from the pipeline on failure.
... Let's say a document is edited, e.g. features are added or subtracted, perhaps invalidating it. If I'm an author and am paranoid about ensuring profile compliance I may want to specify validation abort

nigel: from a bbc perspective this is the sort of thing we'd like to do.

glenn: from a verifier tool it's very useful for the content to specify behaviour.

pal: the delta between the proposal in the powerpoint as Content Profile Proposal (1) (2) and (3) is:

<glenn> PROPOSED RESOLUTION: to adopt Content Profile Proposal (1-3) plus: (1) extend ttp:{profile,contentProfile} to take list of designators; (2) allow use of @verification* on ttp:profile; pending decision by DEC5

<glenn> no objections

group breaks for coffee

Plan to recommence at 11:15 china time, i.e. 7 minutes...

invite zakim

trackbot, this is ttml

<trackbot> Sorry, nigel, I don't understand 'trackbot, this is ttml'. Please refer to <http://www.w3.org/2005/06/tracker/irc> for help.

we've hung up the phone, will redial soon

<glenn> trackbot, start meeting

<trackbot> Meeting: Timed Text Working Group Teleconference

<trackbot> Date: 11 November 2013

profiles (continued)

issue-206

<trackbot> issue-206 -- Add ttp:profileCombination parameter -- open

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

http://www.w3.org/TR/ttml1/#parameter-vocabulary-profile

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

pal: what is the use case for profile combination?

nigel: not sure of any specific use case, but useful in the TTML -> IMSC -> xyz scenario

glenn: this allows collisions between profiles to be resolved more clearly
... as an implementor this allows parameterisation of the behaviour better
... it's possible that we may introduce this now and find that nobody uses it so we then remove it.

pal: argument against adding it now is the profile section of the specification is already confusing for DECE and EBU.
... By adding features we may make it more complex and introduce errors.

glenn: much of the confusion re profiles comes from preconceptions.

nigel: suggests we have the possibility of restructuring the documentation to add clarity

glenn: tech specs are not user guides. The spec should say the minimum that makes it semantically clear.

pal: agrees with that perspective

glenn: in favour of editorial changes to help readers. The driving factor is whether to use hidden parameters or make them explicit.
... the combination methods right now are hidden parameters encoded in prose.
... When we go through the TTML2 spec process, if there are no implementations we may end up labelling features as at risk and then removing them.
... It's easier to take things out than put things in. Like to err on the side of putting in, if logically sound.

mark: customer feedback from target of the spec is 'confused' so would be cautious about saying 'wrong assumptions' but to address this in a customer-oriented way.

pal: open to see the output of the editing, which may be clearer after refactoring than TTML1. Would hate it to get worse.

glenn: agree with the principle of not adding complexity for its own sake
... should we draft a proposal as per previously discussed process?

nigel: yes

<glenn> PROPOSED RESOLUTION: to adopt Content Profile combination proposals, subject to the DEC5 review period

glenn: Feature relation proposal
... example is #markerMode, #markerMode-continuous, #markerMode-discontinuous
... could use the @restricts attribute to relate the smaller features to the larger features.
... @extends allows extension features to extend existing ones.
... It would be useful to think about this when reviewing e.g. IMSC to identify candidate features.

pal: have done this and have not found any.
... profiles can not define new features, only extensions. Can profiles express a restriction on TTML?

glenn: if a profile defines an extension and says it restricts an existing feature it can be expressed. Is that the right mechanism?

pal: so when you capture that you'd put it both in the spec and the profile definition?

glenn: yes.

pal: where would you specify it in the profile specification (the content profile)?

glenn: to reuse the feature definitions in the context of content profiles is to add text describing their meaning in a content profile.

pal: assume we do that.

glenn: if you're in a content profile definition document, this allows enumeration of features that must/may/may not be present in the document.

pal: so you get to the feature that's restricted - how do you declare that?

<pal> <feature value="required" constrainedBy="http://www.w3.org/ns/ttml/ww-profiles/feature#extent-region">#extent-region</extension>

glenn: you'd need to define a feature that is the complement of the portion that is the restriction and then say use of the complement is prohibited.

pal: intention is to say that the extent is restricted, but a processor that supports unrestricted extent can still go ahead, even if it doesn't know about the extension feature designation
... idea is to express still within the feature element.

glenn: we're talking about this in the context of a content profile.

<pal> <feature value="allowed" constrainedBy="http://www.w3.org/ns/ttml/ww-profiles/feature#extent-region">#extent-region</extension>

glenn: so required means it must be present. What you're really trying to say is that something is permitted.

<pal> <feature value="optional" constrainedBy="http://www.w3.org/ns/ttml/ww-profiles/feature#extent-region">#extent-region</extension>

glenn: this is therefore a no-op for any verifier.
... what you're trying to do is to prohibit a document from expressing a value that goes out of the document.
... from the validation perspective optional doesn't help. Suggest we take this offline and see if we can resolve it.

pal: can't see the value of this for IMSC

nigel: @restricts and @extends have almost opposite meanings dependent on whether they're processor or content profile features
... can we come up with different labels that don't have the same connotations?

glenn: we can try to come up with better terms.

pal: was just trying to understand the intent.

glenn: raises the issue of what do content profiles mean? Is it just for validation tools, or something that will be used.
... when you get to the presentation processor its too late in most cases to do anything about it.
... happy to think further about this last proposal and table it subject to further discussion.

<glenn> sense of the room: table feature relation proposal subject to further offline discussion

will break for lunch now, return at 1:30

trackbot, start meeting

<trackbot> Meeting: Timed Text Working Group Teleconference

<trackbot> Date: 11 November 2013

<pal> @plh zakim seems to have no records of ttml meeting

<plh> we could create an ad-hoc call instead

<plh> that would do the trick for now

<plh> ok?

<glenn> yes

<plh> if I was correct, the room should be connected now

yes it is

<plh> the others should use this password

<scribe> chair: nigel

<scribe> scribeNick: pal

<scribe> agenda: ISSUE-285

nigel: mulitrowAlign is intended to allow the author to specify alignement relative to the longest lign of a without a priori knowledge of line length
... would CSS flex box work

glenn: suggest creating an example based on CSS
... unless there is a mapping to CSS, a feature will likely be ignored by OWP
... mapping to svg is a potential, but higher cost

<scribe> ACTION: glenn to reach out to CSS WG to understand potential mappinp of multiRowAlign to CSS [recorded in http://www.w3.org/2013/11/11-tt-minutes.html#action02]

<trackbot> Created ACTION-233 - Reach out to css wg to understand potential mappinp of multirowalign to css [on Glenn Adams - due 2013-11-18].

ISSUE-286

<trackbot> ISSUE-286 -- Extend the background area behind rendered text to improve readability -- open

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

nigel: adding padding at end of row improves legibility

glenn: CSS folks mentioned box-decoration-break as a possibiliy

ACTIOM: glenn to explore box-decoration-break in response to ISSUE-286

<scribe> ACTION: glenn to explore box-decoration-break in response to ISSUE-286 [recorded in http://www.w3.org/2013/11/11-tt-minutes.html#action03]

<trackbot> Created ACTION-234 - Explore box-decoration-break in response to issue-286 [on Glenn Adams - due 2013-11-18].

glenn: and white space as an alternative

nigel: undesirable since it mixes semantics and presentation

ISSUE-286: CSS folks mentioned box-decoration-break as a possibiliy

<trackbot> Notes added to ISSUE-286 Extend the background area behind rendered text to improve readability.

ISSUE-294

<trackbot> ISSUE-294 -- Style attribute to prevent overflow by shrinking text to fit on a line -- raised

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

nigel: "shrink-text-to-fit" is optimal option to ensure that all text shows up
... "shrink-text-to-fit" is dormant issue in CSS

pal: all 3 options: dl fonts, "shrink-text-to-fit" and reference fonts are not mutually exclusive

nigel: should TTML 2 support downloadable fonts

glenn: font height > font width usually so worse case line width can be estimated
... it would be good to explore downloadable fonts
... CSS alows a URL to be associated with combination of font family and style
... TTML 1 did not allow document to reference external resources

<glenn> @font-face { font-family: FooBar; src: url('http://fonts.org/foobar.woff'); }

<glenn> foo bar baz

PROPOSAL: add support for downloadable fonts in TTML 2

<nigel> issue-273

<trackbot> issue-273 -- Map fontFamily to external font file resources -- open

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

ISSUE-273: TPAC 2013 PROPOSAL: add support for downloadable fonts in TTML 2

<trackbot> Notes added to ISSUE-273 Map fontFamily to external font file resources.

pal: not implementations will support downloadable fonts
... so downloadable fonts is not magic bullet therefore

nigel: add margins and reference fonts to delivery specs
... specify end-of-line allowance and reference fonts to delivery specs

<nigel> nigel: (not in TTML2 - adding safety allowances is a specification issue for clients commissioning subtitle documents)

pal: different implementations will render the same font file differently
... authors should use

ISSUE-283: TPAC 2013 PROPOSAL: add informative text (e.g. to Section 9.4) on controlling line breaks (see also issue-273 on downloadable fonts)

<trackbot> Notes added to ISSUE-283 Deterministic text wrapping and presentation.

<nigel> Breaking for 30 mins

ISSUE-288

<trackbot> ISSUE-288 -- Rules for splitting and accumulating documents -- open

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

nigel: presented EBU input document.

<scribe> ACTION: nigel to post EBU input document re: ISSUE-288 [recorded in http://www.w3.org/2013/11/11-tt-minutes.html#action04]

<trackbot> Created ACTION-235 - Post ebu input document re: issue-288 [on Nigel Megitt - due 2013-11-18].

glenn: splitting and accumulating document should probably be in a separate document

ISSUE-270

<trackbot> ISSUE-270 -- Appendix N assumption that root temporal extent corresponds with the beginning of a related media object -- open

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

<scribe> ACTION: glenn to review consistent use of "Root Temporal Extent" in both TTML 2 and TTML 1 SE [recorded in http://www.w3.org/2013/11/11-tt-minutes.html#action05]

<trackbot> Created ACTION-236 - Review consistent use of "root temporal extent" in both ttml 2 and ttml 1 se [on Glenn Adams - due 2013-11-18].

ACTION-236: See ISSUE-270

<trackbot> Notes added to ACTION-236 Review consistent use of "root temporal extent" in both ttml 2 and ttml 1 se.

<nigel> chair: pal

<nigel> scribeNick: nigel

IMSC

issue-296

<trackbot> issue-296 -- Remove xml:lang placement restrictions from IMSC -- raised

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

plh, is richard ishida likely to be able to attend?

<plh> I thought we said Friday

issue-296: pal proposes removing the xml:lang constraint

<trackbot> Notes added to issue-296 Remove xml:lang placement restrictions from IMSC.

plh, I didn't think we had. If he were around soon that'd be handy as we're discussing IMSC

<plh> at what time would you ike Richard to be in the room?

<plh> ok, let me ask him

<plh> I can't locate him at the moment :(

glenn: opentype defines different rendering rules dependent on language, script and feature.
... language is obtained from xml:lang
... many fonts have different rendering rules dependent on language, e.g. arabic is used to express pashto, arabic and other languages.

<scribe> ACTION: pal to review with CFF folk [recorded in http://www.w3.org/2013/11/11-tt-minutes.html#action06]

<trackbot> Created ACTION-237 - Review with cff folk [on Pierre-Anthony Lemieux - due 2013-11-18].

issue-296: pal removes proposal to restrict xml:lang in IMSC though may re-instate it depending on CFF response

<trackbot> Notes added to issue-296 Remove xml:lang placement restrictions from IMSC.

glenn: line breaking algorithms also depend on xml:lang

issue-295

<trackbot> issue-295 -- Remove code point restrictions from IMSC -- raised

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

pal: looks like 3 separate issues.
... 1) Inference that IMSC limits character sets in implementations
... This is a document suggestion not an implementation restriction

glenn: this is defined in Unicode and is not in scope of TTML
... some languages require not just specific fonts but also rendering rules that are not necessarily embedded in an Opentype font, e.g. Indic.
... W3C i18n may have a view here.

<glenn> http://www.w3.org/TR/its20/

glenn: internationalisation work has been considered in separate forums both within W3C and Unicode.

pal: this application is specific to subtitles and captions and may therefore be slightly different.

issue-295: action on glenn and pierre to consult richard ishida - is there a baseline to reference, or an external source?

<trackbot> Notes added to issue-295 Remove code point restrictions from IMSC.

<scribe> ACTION: pal to follow up on issue-295 [recorded in http://www.w3.org/2013/11/11-tt-minutes.html#action07]

<trackbot> Created ACTION-238 - Follow up on issue-295 [on Pierre-Anthony Lemieux - due 2013-11-18].

action-238

<trackbot> action-238 -- Pierre-Anthony Lemieux to Follow up on issue-295 -- due 2013-11-18 -- OPEN

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

issue-238

<trackbot> issue-238 -- smpte:backgroundImage -- open

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

nigel: this is a significant divergence from the spatially scalable nature of TTML independent of rendering plane

glenn: if we implement this we'll have to add specific profile feature designators relating to particular image types e.g. JPEG etc.
... and we'll need to add wording relating to usage, similar to UAX14 line breaking wording - i.e. if needed do it like this.
... we should use a CSS-like syntax.

issue-238: proposal is to add functionality equivalent to smpte backgroundImage and define profile feature designators for baseline feature and image format types. Also describe usage expectations.

<trackbot> Notes added to issue-238 smpte:backgroundImage.

issue-179

<trackbot> issue-179 -- Interpreting the pixel measure -- open

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

nigel: it's problematic to relate pixels to related media objects as there may be none or multiple with different resolutions.

glenn: there's an even bigger problem in that the existing definition of pixels doesn't relate to media objects at all.
... it's defined via TTML 1 8.3.9 as per XSL 1.1 5.9.13 which uses the same language as CSS
... there's been some work in CSS on units and measures

<glenn> http://dev.w3.org/csswg/css-values/#absolute-lengths

glenn: we could state that pixels define a logical coordinate space with a mapping into device coordinates
... we could define a mechanism for defining that transformation
... In SVG there's a viewbox attribute that defines the coordinates

nigel: MPEG states that the track header box in BMFF should have the same resolution as the root extent

glenn: wants time to craft a proposed response. Thinking about using the SVG model of logical coordinate space.
... When we define an extent on the root now that effectively defines a viewbox already so the change may be simple.
... There's extra on SVG in terms of mapping to aspect ratio etc
... we can say if you use pixels and define extent then it means X and if you use pixels without defining extent then it means Y.
... and make a strong recommendation.

- DRAFT -

Timed Text Working Group Teleconference

11 Nov 2013

Attendees

Contents

TTML profiles

profiles (continued)

IMSC

Summary of Action Items

Scribe.perl diagnostic output