See also: IRC log
<scribe> scribe: nigel
group: [discusses topics on meeting page https://www.w3.org/wiki/TimedText/tpac2016#Schedule
<glenn> +Present Glenn
nigel: Seems like the topics list is pretty close to the order we want to cover stuff in.
nigel: We are meeting the Web
& TV IG at 11, so need to provide an update etc.
... Discusses proposal for Web & TV IG consisting of update
on our work in TTML,
... audio description requirements, issue of relationship
between encoded video, media player
... and timed text presentation; live contribution and BBC
subtitle guidelines. (last two points from Nigel with a
different hat on!)
andreas: I have some slides to
discuss on TextTrackCue interface support for different formats
in HTML5.
... I would also point to the unconference session on this on
Wednesday. They may also
... want to log this as work that needs doing by a Web & TV
IG task force.
nigel: Good idea, let's do that ahead of my stuff on AD, live contribution etc.
andreas: [Previews slides] including missing MIME type on track element in HTML5
nigel: Thanks, let's do that after the TTWG update and if there's time to hand back to me for the other parts then let's do that.
david: Number one priority is to
find a new Chair to cover this topic - I've indicated already
to
... plh etc that I don't have the time to devote to this.
glenn: What's the status of implementation work?
david: At Apple it's bug fixing, keeping up with customers.
glenn: On the Chrome and webkit
list I don't see much activity. I am not following mozilla or
Edge.
... What's the status in other groups e.g. MPEG referencing
WebVTT?
david: The Chair does need to
make progress on moving it to Rec so it can be normatively
referenced.
... There is implementation work excluding region support in
many implementations.
andreas: I think there have been
updates to the specification that have not been reflected
in
... implementations so this is a problem.
nigel: I've noticed that too -
Simon made some really good changes around 10-11 months
ago,
... which i suspect have not been implemented. I'm not sure
about the status of editing to
... address the readability review feedback.
david: Apple's implementations predate those changes.
andreas: It's hard to know if those changes will ever make it into implementations.
nigel: From a BBC perspective
there are features that are essential for accessibility that
look
... like they would have to be put at risk for CR due to lack
of implementation, so that would
... be a "red flag" for me.
... For example the BBC's editorial guidelines at http://bbc.github.io/subtitle-guidelines/
... cannot I believe be met by most implementations of WebVTT
right now.
action-475?
<trackbot> action-475 -- Nigel Megitt to Contact the chair of the web & tv ig to ask about schedule and joint meeting time. -- due 2016-07-28 -- OPEN
<trackbot> http://www.w3.org/AudioVideo/TT/tracker/actions/475
nigel: oops I meant:
action-473?
<trackbot> action-473 -- Thierry Michel to Contact co-chairs and essential parties on how to move forward on vtt; need an action plan -- due 2016-06-30 -- OPEN
<trackbot> http://www.w3.org/AudioVideo/TT/tracker/actions/473
nigel: Thierry did this, but I don't believe we have an action plan.
david: We need a suitable volunteer to go through the review comments and respond.
thierry: The Community Group has
looked into the review feedback - about 30 comments
... have been discussed: that's the current status. Now those
comments need to be approved
... by the TTWG (and discussed) and then we should send those
responses to the commenters.
... At some point we need to coordinate between the CG and the
WG to progress those.
... This has not changed for more than a year, probably because
some people involved have
... left and Simon does not participate actively in the WG. We
are experiencing joint work with
... a CG and a WG and we need to invent a process to deal with
this.
nigel: This works both ways - the WG also has not scheduled any effort to work on this.
andreas: I'm not really convinced that the CG exists as a traditionally defined group.
nigel: Shall we close the action? The "contact the chairs" part is done, we're missing an action plan.
david: Leave it open.
action-473: Discussed in TTWG F2F 2016-09-19 - need a volunteer to progress this, possibly a new Chair.
<trackbot> Notes added to action-473 Contact co-chairs and essential parties on how to move forward on vtt; need an action plan.
action-396?
<trackbot> action-396 -- David Singer to Produce evidence of request for wide review for webvtt, for the archive -- due 2015-04-17 -- OPEN
<trackbot> http://www.w3.org/AudioVideo/TT/tracker/actions/396
david: I have not yet done this.
action-396: TTWG F2F meeting 2016-09-19: David has not been able to do this yet.
<trackbot> Notes added to action-396 Produce evidence of request for wide review for webvtt, for the archive.
nigel: TO be
controversial/challenging, WebVTT has been on our Charter since
2013 and we
... have made very little progress. Should we drop it?
david: If we don't complete it in
this Charter period [end March 2018] then we should not
... recharter it - I propose that as a resolution.
PROPOSAL: If we do not make progress on moving WebVTT to Recommendation in this Charter period we do not intend to include it on any rechartering.
thierry: That's a final step - I think we should be aiming to move to CR well before that.
david: I agree.
glenn: We could publish it as a WG Note, to make it easier for external people to reference.
nigel: This is a lot easier.
thierry: That would probably be a final step to that work.
nigel: In fact publishing a Note is a process requirement if we stop working on it.
thierry: We would do that if we removed it from the Charter.
glenn: It would be helpful to have a document that does not have the word "Draft" in it.
thierry: I'm happy to help with
the wide review; that's one thing. The second thing is the
CR.
... We could stay in CR for a couple of years and monitor
implementation work, or we could
... remove non-implemented features. Right now there are a lot
of features that are not
... implemented. That's something we could do in parallel.
Maybe it is not useful to have
... comments on features that we are likely to drop.
nigel: I want to signal that if
we have to drop features that are essential for accessibility
then
... I will have to object to it progressing.
thierry: There's also a lack of
specification text on integrating CSS. We could maybe save
time
... by not addressing issues that we know are unlikely to be
implemented in the next two years.
group: discussion about who is interested in contributing to implementation work etc and therefore progressing responses to comments.
RESOLUTION: If we do not move WebVTT to CR in this Charter period then we will not include it in any new Charter.
andreas: We could mention the
TTML to WebVTT mapping document in the Web & TV IG
meeting.
... We published it last year and are awaiting implementation
comments. We are waiting for a
... stable reference for WebVTT in order to proceed.
thierry: You would expect to see at least a CR document?
andreas: CR would clearly indicate a stable set of features you can map against.
david: DASH and the MP4 file
format have a way to tag the kind of role of a track, using a
URI
... to identify the vocabulary used, and then a term from that
vocabulary. I need a URI to
... refer to the @kind vocabulary in the HTML5 specification,
and there isn't one.
pierre: There is one but it is not complete, specified in DASH.
david: It is not specified in the HTML document itself.
pierre: That's correct. As long as we can reference the one in DASH that can be used.
david: Agreed there is a DASH vocabulary.
pierre: So the request to add one to HTML is not required for MPEG CMAF because the DASH one can be used.
david: I got agreement from
WHATWG and the Web Platform WG for about:html-kind as the
URI
... that refers to the @kind vocabulary in the HTML
specification.
... And I have registered that with IANA.
... I'm waiting for that URI to appear in a revision of the Web
Platform docs. When it is then
... I will update the IANA form.
nigel: It's good to have that but I would note that in my view the kind vocabulary is terrible.
glenn: There are some semantics associated, such as prevention of display of metadata tracks by the UA.
david: I would agree that the HTML vocabulary is both under- and over-specified simultaneously! (in different ways)
nigel: In my view it is insufficiently rich to describe the purpose and intent of the track data.
pierre: It would be great if as making the HTML vocabulary more official we could also fix it.
david: I support that.
... CMAF does prefer DASH at the moment - it says to use the
DASH term if it supports what you want to do.
nigel: I also note that we have
not addressed how to extract something equivalent to kind
... within a timed text document so that it can be extracted
and used to embed into a host HTML page.
... We did address language recently, but not kind.
david: Some people want to manage
external manifest files, but I'm in favour of self describing
documents.
... I'm also aware of ongoing discussions about tags for easy
to read captions (mandated by FCC) and karaoke.
pierre: There is a very specific definition of those two terms in karaoke.
glenn: In TTML2 we have a named
metadata item for easy reader. There's nothing on karaoke per
se.
... nothing that uses that term in TTML2.
nigel: [adjourns for a break] - let's meet in Auditorium IV at 1100 for our update to Web & TV IG.
<nigel_> nigel: Joint meeting - see #webtv
nigel: Are there any other errata other than for backgrounds on spans and lines?
pierre: The only thing I'd
mention is that the computed style resolution for % is very
well defined
... but the computed style for em is not so clear when you say
e.g. tts:fontSize="2em" but
... that is with respect to the current font size but that is
not well defined in TTML1. I assume
... it is relative to the parent element's font size but it
does not say that clearly.
glenn: I would consult TTML1 and
then go back and reference XSL-FO which would take me
... to CSS2. Without having done a recent review of that I
don't know off the top of my head
... but I'm pretty sure you're right - it would have to make
use of the computed font size of
... the parent element.
pierre: Notice that we already
have issue #206 on the ttml1 repo which is a bug about
... specifying em units for fontSize on region.
nigel: That sounds very similar.
glenn: Right now there are 23
open issues on TTML1 so I would expect that there are
some
... errata to be written for those and they probably also need
to be fixed in TTML 2 also.
pierre: I can go ahead and create an issue for this.
glenn: Go ahead - also refer to
#206 - it may be related but more general.
... I think I propose that it should be in relation to 1c.
pierre: That was my first thought, but looking at XSL-FO I think it is probably more like %.
nigel: Okay, so the one on the agenda is: https://github.com/w3c/ttml1/issues/209
andreas: I think there has not
been much progress since we last discussed it. We said we
need
... more investigation to find a good solution. I want to point
to something related.
... This problem about gaps between lines has been addressed by
the HbbTV 2.0.1 spec
... which a lot of televisions will implement. At the moment
that is not really interoperable
... and compatible with IMSC 1 so we should pay attention to
it.
... References spec text from HbbTV 2.0.1 that, specific to
EBU-TT-D 1.0 defines that
... where the lineHeight is "normal" or <125% the background
of each generated inline area
... shall be rendered such that there are no gaps between the
rendered backgrounds of
... adjacent lines.
glenn: We have a quasi default of
doing what CSS does, which is different from what this
suggests.
... This mandates behaviour that is at variance with the XSL-FO
and CSS behaviour.
andreas: Yes.
glenn: By the way issue #209 on
the TTML spec has a length discussion on this.
... The bottom line in my reading is that the height of an
inline area in CSS is implementation defined.
... Different implementations have fine tuned themselves to be
consistent with each other, outside of any spec.
nigel: You can see an editorial requirement example of this at http://bbc.github.io/subtitle-guidelines/#Background-size
glenn: I agree that we need to nail this down - also see issue #212 in TTML1.
nigel: https://github.com/w3c/ttml1/issues/212
... https://github.com/w3c/ttml1/issues/209
pierre: A browser based CSS implementation would display a gap?
glenn: Correct
andreas: There are scripting techniques for getting around this.
pierre: If we feel this is a common requirement for accessibility then it needs to be addressed in the CSS WG
glenn: I've had a detailed
offline discussion with Bert Bos about this and he pointed out
that
... one of the advanced level 4 modules might at some point be
able to deal with this.
... There are a whole bunch of assumptions in CSS on inline
non-replaceable areas, for example
... you cannot specify the content height manually. The height
property explicitly does not
... apply. That was the first problem we ran into, because we
wanted the height of the content
... box to extend to the line area. Somewhere I proposed a mode
for the style engine to use
... different semantics for the height of content areas. The
question is can you have a profile
... that defaults the parameter to a particular value.
nigel: The pressing need here is to issue some statement on this for TTML1.
piere: I recall that some people use a style where they do actually want the gap.
andreas: yes, for example if you have the lineheight at 200% you don't want such a big background area.
pierre: In CSS can you always add padding to every line?
glenn: You can but the problem is
you cannot determine at authoring time what value to add.
... At first order we should document more carefully what the
current situation is in TTML1.
... That may allow people to come up with no-gap semantics. We
could define the default
... semantics to be the no-gap scenario but if we do that we
need to allow the author to define
... the other behaviour. If we change the default now what
would that break?
nigel: I understand that the content rectangle is not well defined?
glenn: It is not, but all the browser implementations do it roughly the same way.
nigel: Could we add an
informative note via an erratum to say that the content
rectangle is
... not well defined but is commonly implemented so that it
does not go to the line height?
pierre: That's not what I'm hearing. I think CSS needs to address this.
glenn: I'm worried that we cannot
easily go back and retroactively define the content
height
... to never show a gap.
pierre: It would be easier to do that if it were not that some folk like the gap.
glenn: In TTML2 we can add a new mode that drives that, but in TTML1 what can we do?
andreas: This requirement for no
gaps came from accessibility guidelines to get proper
presentation.
... The minimum we could say is that some specifications could
define this.
pierre: If someone is overriding that rendering it needs to be flagged.
andreas: That will not change, I
think this is more of an interoperability problem.
... There is an initial step e.g. for an IMSC 1.1, and then a
long term TTML2 solution.
... For now we should say something about this in TTML1.
pierre: +1
andreas: I would also hope for a liaison to respond to this.
glenn: We can note that the
algorithm for content height is not concretely defined and
that
... browsers do behave the same with current CSS
implementations and will introduce a gap.
... If we do want a new TTML1 feature we could write a short
specification introducing a
... ttsx namespace style that is interpreted in a particular
way.
andreas: Ideally if there is a proper parameter to control this it should be defined in this group.
nigel: +1
glenn: That would be an official
extension to TTML1, which we could say maps to a
particular
... syntax and semantic in TTML2.
... That might be an approach.
pierre: If there is an urgent need to address real problems we should address it in IMSC 1.1.
glenn: I've heard 3 things: 1.
Clarify TTML1 with an errata - we can do that
non-controversially.
... 2. We can define new mechanisms in TTML2 - we can do that
no problem.
... 3. More controversially, define a new extension style for
TTML1. That creates another fork
... in the implementation space.
andreas: The target when this was
discussed was an IMSC 1.1 version. If that is possible we
... should do that.
pierre: Absolutely. The question
is if there is an urgent need to resolve an industry problem
now.
... The worst thing would be to make a change that does not
solve the problem.
andreas: HbbTV has solved this
for now - it would be interesting to know if this breaks
... current implementations.
pierre: it would be good to have
a formal communication with HbbTV about this issue.
... It is essential that HbbTV is encouraged to communicate
their requirements to this group and we should be welcoming of
this, even if we make the initial communication.
andreas: We should also be clear that it is needed for interoperability to establish this communication channel.
nigel: Notes that independent of
HbbTV the BBC raised this issue on TTML2 and andreas opened the
equivalent on TTML1.
... I want to come back to what we can do here.
andreas: There's the formal comms
with HbbTV, an errata for TTML1, and a discussion about
... how to fix for TTML2. If there is no formal requirement for
this then it will not happen in IMSC 1.
pierre: BBC has raised this for
TTML2, but the timescale for that is very different than for
TTML1.
... To make a change on TTML1 requires a higher threshold, so
if there is a group such as
... HbbTV that needs this in the short term then we should do
it.
<scribe> ACTION: nigel Draft a liaison to HbbTV requesting further information and proposing an option e.g. to extend IMSC 1 to allow signalling of background height on span, and request timelines etc. [recorded in http://www.w3.org/2016/09/19-tt-minutes.html#action01]
<trackbot> Created ACTION-478 - Draft a liaison to hbbtv requesting further information and proposing an option e.g. to extend imsc 1 to allow signalling of background height on span, and request timelines etc. [on Nigel Megitt - due 2016-09-26].
nigel: Okay, that works; I would
also still like to see the erratum on TTML1 to provide the
context
... for any update to IMSC 1 to allow signalling this
behaviour.
glenn: I have added a comment on the issue at https://github.com/w3c/ttml1/issues/209#issuecomment-247973673
nigel: Thank you!
glenn: Of course that doesn't
explain what to do about it, but that's for https://github.com/w3c/ttml2/issues/150
... We have consensus in TTLM2 to solve this?
nigel: Yes please!
glenn: I have a bpd content proposal where I define 7 possible values.
nigel: That may be more than we
need - let's review.
... Thanks for the good discussion everyone, let's adjourn for
lunch and return at 1400.
nigel: First up, https://github.com/w3c/ttml2/pull/177 Add tts:background{Clip,Extent,Origin}
glenn: This is for image
rendering support - I missed a couple of items from CSS: there
is
... an editorial note to add them.
... I ended up using backgroundExtent rather than
backgroundSize for consistency.
nigel: Just a note on reviewing
the PRs - they don't include the built HTML so it's hard
to
... review or diff. I'd like a CI tool to build the HTML
automatically so we can review it.
glenn: I could do the build and
check in the built HTML but then on pulling I would have
to
... remove it and build it again for gh-pages.
... I'll go ahead and make a change to make these easier to
review.
<glenn> https://www.w3.org/TR/css3-background/#the-background-origin
nigel: So now we have backgroundOrigin as well as backgroundPosition?
glenn: We may want to rename these!
nigel: (notes that this looks analogous to origin and position but is not)
glenn: backgroundOrigin defines
where the background is drawn relative to the content.
... This is as defined in CSS3 backgrounds and borders - it's
the same semantic.
... I took off the -box suffix that's on CSS3.
nigel: I sense that there are
some changes needed here to clear up the names and make
them
... less potentially confusing. Also I'd encourage review of
this in the context of IMSC 2
... if we want to support image placement in more detail.
pierre: This does not express how you would use SMPTE background image in IMSC 1.
glenn: That's actually mapped to the image element.
pierre: yes.
glenn: However we did define
background image also in TTML2 and these attributes
... I believe fully define the semantics for background
images.
... In the case of a foreground image these don't come up
because they define the content
... rectangle. There's never a box in which to position it -
that only applies when the image
... is used for the background. Also bear in mind that
background images may be repeated
... in x and y directions, which can never happen with
foreground images.
... For foreground image size you would use bpd and ipd rather
than backgroundExtent.
... I need to think if it would ever be applicable to have the
same semantic as backgroundExtent
... on a foreground image. I want to see if CSS allows that
property on the image element
... in HTML and what does it mean.
nigel: Just considering the use
cases for this - one that comes to mind is the use of a
... graduated fill background image that is animated to move
along behind foreground text
... for karaoke usage. Do these semantics support that?
glenn: Yes I think you could animate the x and y positions, either discretely or continuous.
nigel: The conclusions for the
time being are 1) that more thinking is needed for the
names
... and 2) whether backgroundExtent can apply to foreground
images.
... For the hard of thinking, some example images etc would
really help, since the terminology
... has a lot of repetition that makes it hard to understand
the differences.
... I've added some notes to the issue.
... Moving on to Add support for rounded borders by introducing
<border-radii> compone…
... https://github.com/w3c/ttml2/pull/179
nigel_and_glenn: [discussion of single value processor semantics for border radii without consensus emerging]
glenn: The more interesting case is the one raised in the issue https://github.com/w3c/ttml2/issues/176
nigel: explains images in issue
glenn: I would suggest an
optional token for this and a default behaviour in case nothing
is specified.
... We also have to set up some context for when it might apply
- it would not apply when
... all the line areas are the same length - you are proposing
a process for merging the
... background areas.
nigel: Yes
glenn: Would you allow me to merge this PR and address your issue as a later iteration?
nigel: Yes, that allows progress.
glenn: I agree with the issue - I
might consult others in CSS land for their opinions too.
... It may even be in background and borders 4, I need to
check
... How to specify merged background areas with radii when
there is no corner is harder
... to specify - I'm sure it's possible but it requires a bit
of thought.
nigel: Agreed!
... Okay, next one is Add missing two component expression to
<position> value syntax. https://github.com/w3c/ttml2/pull/180
... I added a comment about the ambiguity here.
glenn: The ambiguity is resolved
by the two value to four value mapping tables.
... The last entry is ambiguous I agree since it does not
distinguish the lengths
nigel: Even if this is normative
and clear I would prefer at least note to point people at
the
... order preference.
glenn: I'll see what I can do while I'm also dealing with the last line in the table.
nigel: Let's take a break - back
here at 1545
... Next is Remove cea{608,708} prefix from named items.
https://github.com/w3c/ttml2/pull/182
glenn: I had the same question in
my mind as Nigel, whether or not any of the deprefixed
... names had any similarity to the non-prefixed name. The
programName and programType
... seem to be likely, the others not.
... The ones that had cea prefixes need to be syntactically
compatible with SMPTE-TT.
... I can not simply remove the reference to 608 or 708 from
the definition of them without
... sacrificing syntactic specificity.
nigel: And there's an editorial task to add the source definitions?
glenn: That's right.
... I'm pretty sure that programName is just a string and no
more restricted. The originalProgrammeTitle
... is probably the same semantic.
... We also need to check with Mike Dolan since he was involved
in defining these in
... SMPTE-TT. I think we should be able to merge programName
and originalProgramTitle
... probably. We have to choose which token to end up with - I
don't have a strong preference.
... My preference is to add a prefix back, but just make it cea
or cta (remove the 608 or 708)
... and we could add it for EBU also.
nigel: An observation here is
that building the named items into the TTML2 spec gives us
a
... potential problem in that it makes it harder to update the
list later. A common pattern
... is to reference an external list or classification scheme
which can be updated independently.
... Since none of these named items normatively affects
processing this should be okay.
... This is a bit like the role registry approach in TTML1.
glenn: In TTML1 we had a
requirement to prefer Dublin Core, and after much debate we
took
... a minimalist approach and hardly defined anything. Then
SMPTE-TT came along and defined
... a whole bunch of metadata items for 608 and 708 that were
thought to be important.
... Since one of the nominal driving factors for TTML2 is to
support all the extensions in
... SMPTE-TT we ended up adding these in.
andreas: I think the most
practical solution is to reference a document that we maintain
that
... defines our unqualified namespace items and informatively
links to other sources of
... namespace qualified items in other organisations'
namespaces.
glenn: That sounds like a plan.
nigel: Same here.
glenn: I think we should leave in usesForced and alternativeText
nigel: Even those we do not need to be in the specification
glenn: I think we want to refer
to them elsewhere in the spec so I'd like to keep those
two
... unqualified names in the spec.
andreas: Ok, if they depend on these.
glenn: Others that we have not
defined yet we can bind to a namespace and offer a
template
... for the future to define new named items.
... That would simplify this work quite a bit.
... I'll add a note to the issue with that plan.
... I didn't abbreviate alt text so I had it as alternateText -
what's the view?
pierre: Keep it as close as possible to IMSC 1.
nigel: yes, happy with altText.
glenn: ok
nigel: We have essentially covered Add alternateText named metadata item (#107). https://github.com/w3c/ttml2/pull/183
pierre: We are beginning to get industry feedback from IMSC 1 implementation.
nigel: There seem to be some
preconceptions in the wild about what IMSC 2 will be. I'd
like
... us to collate requirements.
pierre: I would happily collate requirements for IMSC 2.
glenn: I think there will be a
continuing requirement for images to deal with
internationalisation
... cases that not all clients will be able to
support.
<scribe> ACTION: pal Refactor the IMSC repository in preparation for future versions of IMSC. [recorded in http://www.w3.org/2016/09/19-tt-minutes.html#action02]
<trackbot> Created ACTION-479 - Refactor the imsc repository in preparation for future versions of imsc. [on Pierre-Anthony Lemieux - due 2016-09-26].
glenn: Having them in one
repository helps with issue tracking but you should use labels
of
... some kind to distinguish between the different
versions.
pal: At the root will be a
roadmap document for all the versions of IMSC.
... As soon as I get requirements for IMSC 2 I will start a
requirements document too.
nigel: It's not from BBC but Ruby seems obvious.
pierre: Yes I hear that a lot, also HDR and tate chu yuko. Disparity is another one.
nigel: Also Wide Color Gamut?
pierre: Yes. Also background area between lines.
nigel: I would add the safe crop area stuff too.
andreas: As well as asking for
requirements it would be good to ask for the use case and
the
... problem that needs to be solved, in some detail.
pierre: So yes, HDR, all east asian layout.
rohit: Any mention of the condition attribute?
pierre: No not yet. I've heard people wanting to do responsive design, but I'm not sure we're there yet.
nigel: What about continuous animation?
pierre: Not yet.
nigel: Seems strange to me based on historical BBC research to have disparity but not continuous animation.
andreas: We should check what east asian organisations need to do.
dae: I'd like to know if there are any parts of TTML2 that folk think might need to change. Ruby for example?
pierre: I'd like to be really specific about all the Ruby features in a pedantic way.
glenn: All the TTML2 layout
features were driven from existing content in lambda cap. it
is
... easy to say what was not driven from lambda cap.
... It is easy to enumerate all the different Ruby features -
look at TTML2 from
... §10.2.30 tts:ruby to §10.2.37 tts:rubyPreserve also
§10.2.40 tts:textCombine
... §10.2.41 tts:textEmphasis and §10.2.43
tts:textOrientation.
... All those were directly driven by lambda cap. There are a
couple that were not:
... rubyOverflow, rubyOverhand and rubyOverhangClass.
rohit: Also rubyReserve?
glenn: Yes. Overflow and overhang
came out of the Japanese requirements as well as how
... to handle some cases that were not obvious.
pierre: Thanks!
nigel: Do we have feature designators for these yet?
glenn: There's an editorial note in E.1 for adding those.
group: [discussion of structure of specification, areas of TTML2 that may be relatively more 'risky', how to make progress etc.]
dae: Can we revisit the initial construct in TTML2 tomorrow?
group: plans ahead for tomorrow, updates agenda.
glenn: Skynav's TTT set of tools
could be viewed as 1-3 implementations. It's a layered
... system - the validation layer at the bottom could be
considered a transformation implementation.
... TTX above that has one module that translates into an ISD
sequence. For example it can
... take IMSC1 or SMPTE-TT documents and turn them into TTML2
ISDs. Then the next
... layer is TTPE that implements formatting semantics.
rohit: At Netflix we are building
a TTML2 oriented pipeline. The idea is to take TTML2
source
... documents, convert them into a canonical form (probably
TTML2 ISD) and then use them
... to generate output formats including WebVTT and rendered
subtitles.
... Depending on the test vector set for TTML2 Netflix may be
able to meet 40-50% of the
... tests for implementation.
glenn: I'd also like to add: in
terms of presentation semantics implementation in TTPE
for
... TTML2 features, the only new features it does not yet
support are the use of referenced
... external fonts, audio and disparity. Everything else that's
new in TTML2 it supports already
... from a presentation semantic. There might be some fine
points to some of the features
... that we are still tweaking. We have test content for all of
those features that we are using
... to generate presentable output in either images or SVG. So
we are way ahead on implementation
... of presentation and we have test content for most all of
it. Our schedule for finishing
... implementation work on TTML2 is scheduled to be finished
early March 2017.
thierry: The horizontal review groups request review opportunity as soon as possible.
nigel: In fact I should trigger
that process straight away.
... Wide review is even wider than that.
thierry: We should start to initiate that to make sure there is enough time.
glenn: I'd like to have a version ready for a new WD by early October.
thierry: Remember that we can
limit the scope of review only to the additional features
in
... TTML2 that are new relative to TTML1.
pierre: Remember also for wide
review you have to factor in time to respond to comments.
... For the east Asian text layout there's an action to contact
ARIB specifically.
nigel: We will also need horizontal review. As a minimum I should contact the horizontal review groups and request time on their schedule for a new document early November.
<scribe> ACTION: nigel Request schedule time for horizontal review of TTML2 [recorded in http://www.w3.org/2016/09/19-tt-minutes.html#action03]
<trackbot> Created ACTION-480 - Request schedule time for horizontal review of ttml2 [on Nigel Megitt - due 2016-09-26].
glenn: Why don't I give you a list of new features to start reviewing?
nigel: Good idea.
<scribe> ACTION: gadams Provide nigel with a list of new features in TTML2 to begin reviewing [recorded in http://www.w3.org/2016/09/19-tt-minutes.html#action04]
<trackbot> Created ACTION-481 - Provide nigel with a list of new features in ttml2 to begin reviewing [on Glenn Adams - due 2016-09-26].
glenn: How would it be if we have a solid working draft for wide review by Nov 1?
nigel: Sounds good to me.
glenn: And how about moving to CR by the end of the year?
nigel: It's ambitious but we can
try.
... Looking at the picture on https://www.w3.org/wiki/TimedText/Publications
it shows
... a FPWD of IMSC 2 back in June, but I think from today we
have decided to collate
... industry requirements and then maybe base it on the TTML2
CR perhaps?
pierre: We should aim to make
IMSC 2 based solely on industry requirements but we can
... certainly set a new date - I'm comfortable with that,
partly as a challenge to folk who
... want IMSC 2 - we need to get going on it.
nigel: Agreed. Shall we say IMSC 2 FPWD by Dec 1?
pierre: Sounds great to me, maybe even earlier.
nigel: Ok let's leave it at that for now and if we can make it earlier, great.
dae: Can an implementation satisfy both TTML2 and IMSC 2?
nigel: Yes.
... Ok we're out of time for today, thanks all. Time to adjourn
for tomorrow.
andreas: Can we make sure we cover IMSC 1 implementation work tomorrow?
nigel: yes let's do that.
... [adjourns meeting]