- From: Dewa, Yoshiharu (OSAKI) <Yoshiharu.Dewa@jp.sony.com>
- Date: Tue, 28 Oct 2014 01:02:59 +0000
- To: Nigel Megitt <nigel.megitt@bbc.co.uk>, TTWG <public-tt@w3.org>
- Message-ID: <2C07C67E48B3A546810F4CE8BE8554D904D707CF@JPYOKXMS123.jp.sony.com>
Hi TTWG folks,
I'm new in this group, but I have one question about TTML2 full profile. I'm happy if someone have an answer.
When I saw F.1 TTML2 Full Profile, there are following definition.
<feature value="required">#textOutline-blurred</feature>
<feature value="required">#textOutline-unblurred</feature>
There two features are contradictory. One is "is capable of transforming values of the tts:textOutline attribute that includes a blur radius specification." and the other is "is capable of transforming values of the tts:textOutline attribute that does not include a blur radius specification."
What is the situation that these both features are "required" at same time?
I found these lines fully derived from TTML1 so perhaps I'm missing something.
Rgs,
-- Yoshiharu
From: Nigel Megitt [mailto:nigel.megitt@bbc.co.uk]
Sent: Tuesday, October 28, 2014 9:47 AM
To: TTWG
Subject: {minutes} TTWG Meeting 27/10/2014
Thanks all for attending today's face to face meeting. Minutes in HTML format can be found at http://www.w3.org/2014/10/27-tt-minutes.html
We made the following resolutions:
RESOLUTION: We will document the syntax for the external processorProfiles parameter in TTML2.
RESOLUTION: We will host the registry on the wiki (subject to edits as discussed today)
RESOLUTION: We will publish the staged version of WebVTT as a FPWD when the edits to change the occurrences of "Living Standard" to "Draft Community Group Report" have been applied.
The review period for these resolutions ends on 10th November according to our Decision Process.
In text format:
[1]W3C
[1] http://www.w3.org/
Timed Text Working Group Teleconference
27 Oct 2014
See also: [2]IRC log
[2] http://www.w3.org/2014/10/27-tt-irc
Attendees
Present
Cyril, mike, pal, glenn, nigel, courtney, Erik,
Carlsson, plh, jdsmith, Erik_Carlson
Regrets
dsinger, andreas, frans
Chair
nigel
Scribe
nigel
Contents
* [3]Topics
1. [4]Introductions
2. [5]TTML Codecs Registry
3. [6]MPEG liaison re track header box width and height
4. [7]WebVTT publication
5. [8]TTML <--> WebVTT
6. [9]IMSC 1 WD Review comments
7. [10]Plan for advancing IMSC 1 to CR
8. [11]WebVTT FPWD publication
9. [12]MIME type for TTML2
10. [13]IMSC 1 WD Review Comments
* [14]Summary of Action Items
__________________________________________________________
<trackbot> Date: 27 October 2014
<scribe> scribeNick: nigel
Introductions
All members introduce themselves. Observers: Jangmuk Cho, LG
electronics, interested in TTML and WebVTT
nigel: Summarises agenda, offers opportunity for other business
mike: There's an incoming liaison expected from MPEG
nigel: adds it to agenda
TTML Codecs Registry
[15]https://www.w3.org/wiki/TTML/CodecsRegistry
[15] https://www.w3.org/wiki/TTML/CodecsRegistry
nigel: We've agreed to host a registry and define a parameter
... We need to work out where to define the syntax normatively
... And where to note the media registration once we've updated
it with IANA.
Cyril: I had two comments on the registry:
... 1. The discussion that talks about the first order
detection of capabilities.
... 2. The editorial nature of stpp vs application/ttml+xml
Mike: We proposed to MPEG that they have their part and W3C has
its part.
glenn: That's true - we need to remove the prefix requirement
on the registry page.
Cyril: I'd rather delete the sentence "When an entry of this
registry is used in a codecs parameter..."
... Actually the whole paragraph - it's up to MPEG to define
any codecs parameter, and we can define the
... suffix.
group discusses whether any reference to RFC6381 is needed at
all
glenn: I got rid of the RFC6381 references and put the
combinatorial operators in.
pal: The AND and OR operators are normative, so it needs to be
clearly defined.
cyril: +1
glenn: First we have to define where we're going to specify the
normative definition of this new parameter - it shouldn't end
up in the registry.
cyril: +1
glenn: When we have it somewhere else we can refer to then we
can shorten the registry page.
Cyril: Can we also discuss the 1st order aspect, where it says
that the processor profile is guidance only and may not always
be correct.
... We should be strict here.
glenn: My position is that what's in the TTML document is
what's authoritative, because it stays with the content.
cyril: Both have to be the same.
glenn: Even if you say they have to be the same, it's possible
for them to diverge. Elsewhere, type identifiers are always
documented as hints
... and the actual data is where you determine the concrete
type.
Cyril: I agree, but we need to state it more strongly: it is an
error in general to have a mismatch.
glenn: It wouldn't be an error in the document.
Cyril: I agree - if the two differ then that's an error and the
value in the document has precedence.
nigel: There's a lifecycle issue there - a new processor may
come along that can process older documents.
glenn: So the outer parameter may reference a new superset
profile?
nigel: exactly.
glenn: So the rule should be about consistency not identity.
nigel: The options for where to put it seem to be:
... 1. An erratum to TTML1
2. TTML2
3. A WG Note
4. A new Recommendation.
group seems to think TTML2 may be the best place
glenn: I'm willing to add it to TTML2 but do not wish to repeat
the whole registration section.
[16]https://dvcs.w3.org/hg/ttml/raw-file/default/ttml2/spec/ttm
l2.html
[16] https://dvcs.w3.org/hg/ttml/raw-file/default/ttml2/spec/ttml2.html
Glenn: We need to tweak section 3.1 in TTML2 "Content
Conformance"
Cyril: I would rather add an annex in TTML2 called Media Types
Registration referencing TTML1 plus diffs.
glenn: That works for me.
... I think we can avoid updating the IANA registration
... since there's no wording to prohibit adding new parameters.
Mike: I'm not so sure about that.
nigel: I don't think we can do that either can we?
glenn: The TTML2 we should define the new parameter and syntax
and then reference it in 3.1.
Cyril: We should put it in a Media Type Registration annex so
that it's clear. This then uses a reference to TTML1 with
... the diffs.
glenn: I'd like to call the annex something like 'Additional
parameters for use with TTML media type'.
Mike: let's check with plh too.
all agree to point back to TTML1 media registration.
nigel: It's an open question if we genuinely need to update the
IANA registration.
Cyril: In the SVG WG we've made a comment on the charter about
how documents and versions of documents in TR/
... should be handled. We have the same problem here: TTML1
doesn't talk about TTML2. It points only to the latest
... stable version of TTML1.
pal: They're two different specs - there's no absolute
guarantee for backward compatibility.
Cyril: And you're using the same MIME type? SVG 2 is backward
compatible with SVG 1
glenn: TTML2 is backward compatible in the sense that a TTML1
processor would process a TTML2 document, practically speaking.
... I defined a new #version feature in TTML2 - if you want to
author a document for TTML2 and prevent it from being
... processed by a TTML1 processor then you could do that by
using the profile mechanism. If you don't do that then
... there's no reason that a TTML1 processor could not process
it by ignoring things it doesn't understand.
... We explicitly stated that the XML namespace for TTML is
mutable.
Cyril: THe issue is that the group is giving the signal that
TTML1SE is the latest version whereas actually everyone is
... working on TTML2. If a TTML1 document can be considered a
TTML2 document...
pal: Setting aside the media registration, TTML1 and TTML2 are
different specs, albeit with a common pedigree.
Cyril: If I search for TTML now, I'll find many documents and
if I hit the TTML1 document it will look like the latest
version
... but that's probably not what I want.
pal: But that's right - the latest stable version now is TTML1.
Even when TTML2 is a Rec TTML1 will be valid.
glenn: Think about XML - XML 1 and XML 1.1 are not entirely
compatible but are still being updated.
... In TTML1 we may publish a Third Edition incorporating the
errata.
pal: IMSC 1 is based on TTML1 for example.
glenn: In the latest version we actually include "ttml1" in the
URL - TTML2 will be a different URL.
<glenn> ACTION: glenn to update point (1) of section 3.1 in
ttml2 to refer to a new annex that defines new
processorProfiles MIME type parameter [recorded in
[17]http://www.w3.org/2014/10/27-tt-minutes.html#action01]
<trackbot> Created ACTION-343 - Update point (1) of section 3.1
in ttml2 to refer to a new annex that defines new
processorprofiles mime type parameter [on Glenn Adams - due
2014-11-03].
mike: There are a number of W3C specs that have this problem.
Cyril: And that's a problem.
pal: It's even worse if we don't make it clear that there are
two different specs.
Cyril: This is going to stay a problem for anyone searching for
TTML
<pal> [18]http://www.w3.org/XML/Core/
[18] http://www.w3.org/XML/Core/
<glenn> [19]http://www.w3.org/TR/CSS/
[19] http://www.w3.org/TR/CSS/
pal: The XML WG is explicit about its different publications.
glenn: The CSS WG explains this with "Levels" and we could do
that too, with a top level TTML uber-document
... as a WG Note to explain the relationship.
Cyril: I'll volunteer to write a similar note.
<scribe> ACTION: cyril Draft a WG note explaining the
differences and relationships between the various versions of
TTML [recorded in
[20]http://www.w3.org/2014/10/27-tt-minutes.html#action02]
<trackbot> Created ACTION-344 - Draft a wg note explaining the
differences and relationships between the various versions of
ttml [on Cyril Concolato - due 2014-11-03].
nigel: That's helpful. Now what do we do about MIME types which
may be the same for TTML1 and TTML2 documents?
glenn: That's a good question. In the TTML2 spec I defined a
new set of baseline profiles, and a new ttp:version attribute.
... In §5.2.3.1 of TTML2 we list the 3 profiles from TTML1,
plus SDP-US, plus 3 new profiles specific to TTML2 including
newly defined features.
... One way to do it is to use different short names in the
registry for each of these profiles.
... The ttp:version attribute is a little orthogonal. It states
which version of TTML was used in authoring a document
instance.
... It's required if the document requires support for a
feature not present in TTML1.
... And the Note mentions that the computed value of the
attribute is used by the construct default processor profile
procedure.
... Omitting the attribute causes the default to be one of the
TTML1 profiles.
Cyril: This makes the processorProfiles parameter in the MIME
type even more important.
glenn: It's important for any kind of external filtering.
Cyril: So there's the version attribute, the profile designator
and externally there's processorProfiles that would use
... different short names for TTML2 than for TTML1.
glenn: Yes. In the new annex we should mention that designating
externally that something is a profile could result
... in a false negative, or a false positive. A false negative
in the sense that the context may think it can't process, but
... within the document it could say 'start with a profile and
make a feature optional' at a very fine grained level. This
could
... add or remove feature requirements. So if the external
parameter indicates that the processor can not process, but
... the internal parameter says it can, then it would be a
false negative. The reverse is true. that the document may
require
... an extension feature.
nigel: But you could just locally define a new profile short
name for an extension, and put that in the external
processorProfiles parameter with the AND operator.
glenn: There's also the question of, in the absence of the
external parameter, what should the semantics be?
Cyril: it should be less restrictive.
glenn: It should certainly be no more restrictive than what's
in the document. The problem is there may be some cases
... where there's no way to express the complexity in the
external parameter.
... One of my observations is that people want to simplify the
profiles mechanism in the external parameter. Is that what
people are thinking?
pal: Unless we put something in then people will just define
their own way of doing it.
courtney: From a parser-writing perspective there's no
efficient way to look at the supported profile requirements.
You have to parse the whole thing.
<pal> pal: doing it == "signal that a document conforms to one
or more specifications"
glenn: It's not that bad - you can just parse the head.
courtney: You still have to parse the whole head.
glenn: It's much better than SVG 1.1 which mandates full
parsing to determine if it is a well formed XML document, even
down to the last closing tag.
courtney: So there's no goal to efficiently reject files?
glenn: We just used a similar mechanism to SVG. We assumed that
the head would be parsed before the body.
courtney: It defeats the purpose of profiles to allow people to
pick and choose features.
pal: If this group doesn't do it then others will.
nigel: But they probably wouldn't include the feature addition
and subtraction semantics.
glenn: But the short registry doesn't define what a document
conforms to.
group discusses the topic further (scribe misses details)
cyril: What does EBU-TT-D say?
nigel: It permits extensions by default, but wouldn't do
anything with them. It doesn't use profiles.
... Andreas raised the query about how complex it is to
register a short name - the email discussion seems to indicate
... that there's no requirement to create a full profile
definition document; a short name can be registered with the
... details from the spec document in the absence of a full
profile document.
... By the way, as I think Dave mentioned a while back, you can
also just define a new short name if you don't want to hit
... the complexity of the internal profile mechanism.
pal: So we're okay to keep the same application/ttml+xml mime
type and use the processorProfiles parameter to
... distinguish between TTML1 and TTML2, and the processors
within them.
RESOLUTION: We will document the syntax for the external
processorProfiles parameter in TTML2.
... We will reuse the same media type in TTML2 as in TTML1 but
recommend using the processorProfiles external parameter to
differentiate processor requirements.
Cyril: what about the registry? Where should it go? The Media
Source Extensions registry is published not on a wiki but as a
document.
glenn: the usual practice in W3C is to use a wiki page.
<Cyril>
[21]https://dvcs.w3.org/hg/html-media/raw-file/default/media-so
urce/byte-stream-format-registry.html
[21] https://dvcs.w3.org/hg/html-media/raw-file/default/media-source/byte-stream-format-registry.html
Cyril: For MPEG the registry needs to have a stable URL.
nigel and glenn: We can keep a stable URL with a wiki.
RESOLUTION: We will host the registry on the wiki (subject to
edits as discussed today)
nigel: Opens up MPEG response for those in the room to see.
Cyril: MPEG accepts the registry proposal from W3C.
... MPEG has no comments on IMSC at this time.
... There was also discussion of track header width and height
in the ISO BMFF. In many cases it's intentionally unknown what
the TTML extent is.
... So MPEG drafted corrigenda to 14496-12 and 14496-30.
... in the MPEG discussion also, from an MPEG perspective you
can usually extract the codecs value from the bitstream. For
TTML that isn't exactly the case, because
... you have to produce the short name from a profile
designator in the document, so you need extra knowledge to
convert the long name into the short name.
... So MPEG is considering adding a new box just to contain the
MIME type to remove the need for the extra knowledge. You'd be
able to put the MIME type of a TTML document in a TTML track.
... So MPEG fixed this (or it's in the pipeline to fix) that
the MIME type can be in the MP4 file.
glenn: Is there a suggestion that there should be an additional
piece of metadata that includes the short names directly?
Cyril: I thought that would be redundant with the long profiles
designator.
glenn: It is if you happen to know the details of the registry,
but otherwise not.
... Adding such an attribute would make it more necessary to
define the syntax in TTML2.
Cyril: That would be fine, but we've solved it separately in
MPEG too.
nigel: I'd be concerned about putting the short codes in the
TTML because that would encourage folk to extract the value
from the TTML and put it into the (proposed) MP4 MIME
attribute.
... That could limit the ability for distribution mechanisms
creating MP4 files from old TTML files from generating an up to
date external processorProfiles parameter.
glenn: I understand that concern. Early binding could be worse
than late binding, for document wrapping.
group discusses the possibilities, concludes that we will not
propose to put the short codes into TTML documents.
Additional observer: Tatsuya Hayashi - interested in time
synchronisation with audio
MPEG liaison re track header box width and height
nigel: shows on screen the early draft liaison. Describes an
issue with signalling track header width and height fields.
glenn: I think I have an action for when no extent is specified
and there is a related media object.
Cyril: In MP4 we had the problem that in adaptive streaming
there may be an MP4 file with no video, just the text track.
mike: In the external context there's always a related media
object somewhere, either in the file or in the MPD manifest in
DASH.
glenn: We don't limit the scope of how the related media object
is provided.
Cyril: We added a bit that says that the width and height can
be the aspect ratio instead of the actual width and height, and
can be zero if you don't know.
... From an MPEG perspective a video can have encoded pixel
dimensions, or output pixel dimensions. In the end there's a
presentation size expressed in pixels.
... Each video track can have a different presentation size,
related to each other using transformation matrices.
pal: On the same dimensions?
Cyril: Yes, on the presentation coordinate system.
... We had two problems. Firstly, a document may be authored
independent of resolution, second the aspect ratio may not be
known, and be important.
... The two corrigendums deal with this.
... The -12 spec was too prescriptive about visual tracks - it
turns out that it is track type dependent.
... There is a new definition of a reserved 0 0 size value.
Concerns have been raised.
mike: Introduces the liaison and supporting documents. They
will be available to the group in the next few weeks.
Cyril: This is equally applicable to WebVTT, SVG tracks, HTML
tracks, any graphical vector graphics based tracks [as well as
TTML]
... Takes us through the proposed changes to 14496-30.
group discusses track selection behaviour based on aspect
ratio.
WebVTT publication
nigel: We have a proposal still to publish WebVTT as a FPWD.
The edits requested to the staged version were made.
[22]http://dev.w3.org/html5/webvtt/webvtt-staged-snapshot.html
[22] http://dev.w3.org/html5/webvtt/webvtt-staged-snapshot.html
group discusses the use of the term Living Standard and how
forks are managed, bringing in CG changes into the WG document,
and FSA requirements for doing so.
and that it's the editors' responsibility to maintain any
differences between CG and WG versions, and update the WG
version each time a new version is to be published by WG.
Cyril: Anyone wanting to work with WebVTT will always look at
the editor's draft.
glenn: I don't mind the process, but I'm not happy with the
term Living Standard.
... It looks like it will set a precedent.
mike: Use of the term Living Standard needs to be something
that the W3C expresses a view on.
Cyril: What if Living Standard were changed to Draft Community
Group Report?
glenn: I could live with that. Editor's Draft may be even
better, to make it clear that this is within the normal WG
process for a Rec track document.
... Objects to the use of the term Living Standard. Acceptable
proposals to resolve this are "Editor's Draft" or "Draft
Community Group Report".
pal: How will reviewers of future WG versions of the document
be able to trace back why any particular change was made?
(noting that this is only possible on the CG version now)
<scribe> ACTION: nigel Make request to Philip and Silvia to
change Living Standard to Editor's Draft. [recorded in
[23]http://www.w3.org/2014/10/27-tt-minutes.html#action03]
<trackbot> Created ACTION-345 - Make request to philip and
silvia to change living standard to editor's draft. [on Nigel
Megitt - due 2014-11-03].
nigel: Going from WD to CR for WebVTT?
... Dave planned to send notes out essentially to the same set
of recipients as we sent to for IMSC 1, as well as socializing
at TPAC.
TTML <--> WebVTT
nigel: Current status is that we have a git repo with some but
not all of the tests we worked on in Geneva.
courtney: And I don't have a draft document ready.
... I've prioritised working on the document ahead of the code.
pal: What's the timescale for this? It would be a great
addition to the IMSC 1 test suite, if that software could be
part of it.
courtney: My goal is to have a version of the document ready by
the beginning of December, as a fairly complete 1st draft for
comments.
... I don't know exactly when I will have the software ready.
nigel: We don't seem to have all the tests from Geneva - is
there a reason why they can't all be submitted?
group: no reason
nigel: Okay, the action to submit them to me remains.
... It would make sense to transfer the git repo to courtney at
some point - no pressure on time.
courtney: Okay, I can do that.
nigel: We have no more substantive points to discuss on this so
let's adjourn for lunch.
... We'll reconvene at 1345
IMSC 1 WD Review comments
pal: LC-2968
[24]https://www.w3.org/2006/02/lc-comments-tracker/34314/WD-ttm
l-imsc1-20140930/2968?cid=2968
... This is a version of implied inline regions, which isn't
supported in TTML1. There's an alternative solution available,
so I propose to do nothing.
... Describes notes and resolution.
... LC-2971.
... LC-2969.
... LC-2970.
... LC-2967.
[24] https://www.w3.org/2006/02/lc-comments-tracker/34314/WD-ttml-imsc1-20140930/2968?cid=2968
Plan for advancing IMSC 1 to CR
nigel: We have to think about what exit criteria to write into
the CR; if we have enough evidence of wide review; what the
license expectations are for test material.
pal: What are the licensing expectations for test material?
plh: The goal here is, if the group is using a test suite to
demonstrate suitability for advancement, the Director will want
to make that test suite available to all.
... For that what we've done so far is to provide tests under
dual license: 1. If you're going to use those tests for
conformance claims, you may not modify them.
... 2. For any other purpose we don't really care.
... The second one is the BSD license.
... What's the issue?
mike: The question is what W3C is asking for - which you just
answered.
plh: W3C needs the rights to modify the files and make them
available to the public under the W3C license.
group looks at the DECE license requirements
plh: It doesn't permit modification.
mike: I'll explore this with DECE to check that they can
provide test documents that will be usable by W3C for this
purpose.
... It would be useful if nigel or plh could respond to DECE's
email asking if the example files can be issued under the
standard W3C license (with the text of that license).
<plh> http/www.w3.org/2002/09/wbs/1/testgrants2-200409/
plh: The 'this is closed since 01 October 2013' is a bug -
ignore it.
... The text you're looking for is in section 2 on this page.
nigel and philippe send DECE a note via Mike.
nigel: Next up - do we have enough evidence of wide review?
pal: The member submission itself was based on the work of 80
members, from both the CE and the content publishing space.
... This is a specification that was used in the implementation
of playback devices. So it already received a significant
amount of scrutiny.
... Since being brought to W3C it has received comments from
SMPTE, EBU and DECE.
plh: On Sep 24 SMPTE said they have no outstanding comments on
IMSC 1.
pal: Earlier today DVB stated that they have reviewed and have
no comments.
... Plus we can point to the members of this group and their
representation, and that it was reviewed by the a11y group of
the HTML group.
... And we requested comments from a significant number of
groups.
plh: Another group that would be important if the PFWG.
... At the end of the day it's a profile not a whole new spec.
glenn: I think this has wider review than TTML1 did, at least
bringing in DVB, EBU and DECE.
plh: My feeling is that you've done enough.
nigel: Great, then the next point is CR exit criteria.
nigel takes group through slide pack on CR exit criteria,
triggering much debate.
<scribe> ACTION: nigel Scribe notes on CR exit criteria for
IMSC 1 based on meeting debate [recorded in
[25]http://www.w3.org/2014/10/27-tt-minutes.html#action04]
<trackbot> Created ACTION-346 - Scribe notes on cr exit
criteria for imsc 1 based on meeting debate [on Nigel Megitt -
due 2014-11-03].
<plh> [26]http://www.w3.org/TR/2014/CR-html5-20140731/
[26] http://www.w3.org/TR/2014/CR-html5-20140731/
WebVTT FPWD publication
plh: Calling it Living Standard will cause a problem. "Draft
Community Group Report" would be acceptable.
RESOLUTION: We will publish the staged version of WebVTT as a
FPWD when the edits to change the occurrences of "Living
Standard" to "Draft Community Group Report" have been applied.
MIME type for TTML2
Cyril: summarises morning resolutions
plh: My understanding is that IANA needs a complete new
registration to overwrite the previous one.
glenn: It seems confusing to have two different registrations
for the same MIME type.
Cyril: We can link back from the TTML2 section on media
registration to the TTML1 definition.
nigel: Mike volunteered to do the re-registration - is that
okay for it not to be a member of W3C staff?
plh: Yes, it's fine for me to be out of the loop and not a
bottleneck - I just have to tell the IESG that it's okay
IMSC 1 WD Review Comments
pal: the other comments are from Andreas Tai
nigel: Let's go through them. Actually it's too hard to put
them all in the issue tracker - we did 5.2 but let's just talk
through the others.
pal: 3. Conformance - subtitle document not being defined. I
can just take that on - it should probably say 'document
instance' like TTML does.
... 4.1 - I'm happy to add the proposal.
... 5.7.3 - I agree it would be useful to show all the
combinations of the parameter and the attribute for
forcedDisplay.
... 5.7.4 - I should be able to implement the proposal and the
typo.
... 5.10 - this is a good suggestion a priori
... 6.3 - This is a good point - I should link to 9.3.1 in
TTML1
... 8.2 - Andreas is suggesting that we use the terms
presentation processor and transformation processor now that we
have them.
... I have to think hard about this. I think the intent of the
text is the same as the note on overflow, where we talk about
authoring of the documents.
... Section 8.2 doesn't necessarily say that the presentation
processor shall lay out text in this way. I'm pretty sure it
refers to how its authored.
glenn: If that were the intent I would have written it
differently, e.g. "for the purpose of avoiding overflow, the
author shall or should..." etc
nigel: Since this is in section 8 does it only apply to layout
for the purpose of calculating the HRM values?
pal: 8.1 is Performance, 8.2 is Reference Fonts. Since the HRM
section is referenced as 'documents shall conform to these
constraints' I think it's about authoring not presentation.
... If this is the case then there isn't a strict constraint on
processors at all. I'll study this and come up with a proposal
for us to consider in addressing Andreas's comments.
... Annex B Forced Content - we're going to put some code
snippets in there.
... 5.10 #length-cell - I have to think about this. What's the
reason for needing cell metrics in documents for linePadding?
nigel: It makes it easier to make the padding distance a
fraction of the font size, which is a typical use case.
pal: 5.2 The current text was direct input from EBU so we
shouldn't modify it lightly. Perhaps if EBU comes back and says
something different this would be easier to resolve.
nigel: We've completed our agenda for today, so adjourning.
Thanks all. We restart tomorrow at 0830.
Summary of Action Items
[NEW] ACTION: cyril Draft a WG note explaining the differences
and relationships between the various versions of TTML
[recorded in
[27]http://www.w3.org/2014/10/27-tt-minutes.html#action02]
[NEW] ACTION: glenn to update point (1) of section 3.1 in ttml2
to refer to a new annex that defines new processorProfiles MIME
type parameter [recorded in
[28]http://www.w3.org/2014/10/27-tt-minutes.html#action01]
[NEW] ACTION: nigel Make request to Philip and Silvia to change
Living Standard to Editor's Draft. [recorded in
[29]http://www.w3.org/2014/10/27-tt-minutes.html#action03]
[NEW] ACTION: nigel Scribe notes on CR exit criteria for IMSC 1
based on meeting debate [recorded in
[30]http://www.w3.org/2014/10/27-tt-minutes.html#action04]
[End of minutes]
__________________________________________________________
Minutes formatted by David Booth's [31]scribe.perl version
1.138 ([32]CVS log)
$Date: 2014-10-28 00:41:29 $
[31] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
[32] http://dev.w3.org/cvsweb/2002/scribe/
Received on Tuesday, 28 October 2014 01:15:22 UTC