W3C home > Mailing lists > Public > public-tt@w3.org > December 2008

TTWG minutes 12/12/2008

From: Geoff Freed <geoff_freed@wgbh.org>
Date: Fri, 12 Dec 2008 12:50:49 -0500
To: "public-tt@w3.org" <public-tt@w3.org>
Message-id: <E36081A12A13F146AC32D7724B0E89120561CAA206@EXCHCCR.wgbh.org>

Timed-text working group minutes 12/12/2008

Sean Hayes (SH)
Glenn Adams (GA)
Geoff Freed (GF, scribe)
Philippe le Hegaret (PH)
John Birch (JB)
Andrew Kirkpatrick (AK)

Regrets or absent:
David Kirby (DK)

No more TTWG calls until January 9.  Will get the survey out so people can look it over in the meantime.  Can continue working on the test suite and feedback.

SH:  dynamicFlow:  nobody has actually implemented this yet.  JB has expressed that it ought to be pulled.  GF should explain why we need it.

GF:  We need roll-up representation because much captioning is done this way in the US.  Also roll-up-captioned broadcast programming is migrating to the Web; should be an easy method to carry and display roll-up captions with the program.  (explains how roll-up captions work in broadcast tv)

AK:  MTV has extended Flash support of DFXP to display roll-up captions.

GA:  Karaoke TV in Asia.

GF:  Will send a link to the reflector illustrating roll-up captions.

SH:  Why is this useful from an authoring point of view?

GF:  For short-turnaround captioning jobs; matching a specific style...

GA:  Current dynamicFlow spec might be overly general.  Written to handle lots of different use cases.  If we can identify the essential modalities and express them as a subset of dF, might not need to be extensive changes.

SH:  I think that as an attribute it might not work, but it sounds like a macro might do the trick... par and seq might be able to handle roll-up display.  Could be inadequate, however.  Might not need an attribute; something like a meta-level time container?  If we can crisply define scenarios would be best.

GA:  Author may not have knowledge of layout restrictions of the client.  If you send everything out in cells, fine, but if the client reformats linebreaks, that might be difficult to control the rate at which characters appear on the screen.  dF was invented so the author could express parameters at which units of text are made visible and invisible.

SH:  A macro could unroll text just prior to rendering.  You could have blocks of stuff piling up from the bottom and then have the macro expand the timing of it.  Sounds like what we want is everything in a par and individual text in a span.

JB:  You'd have to remove and redisplay text each time you display a new word (?)

GA:  We either need to throw this out of DFXP 1, or JB needs to volunteer his company to create a subset that illustrates functionality.  Then I can produce a significant subset that would allow roll-up captions.  All we need is two implementations, which is all we need to go to rec.

JB:  Can't volunteer services to do this.

GA:  Ask your management to show that this is implementable.

JB:  Will have to check.  Proposed to drop it due to implementation issues.  Agree with GF about reasons to have it.  Need to find a common-sense method to go forward.  Not easy to express if you knife-and-fork it.  Need to say to user agent to display roll-up.

GA:  Have you looked at a simple implementation that would involve a ...
If you could take DFXP and transform it into a representation that works for Screen Subtitling, that would help define semantics.

JB:  We already support snake mode which is similar to roll-up mode in US.  Might be able to illustrate that, but would support original characteristics that we proposed.  I have two requirements-- that we support live captions and marquee-style (text crawl).

SH:  If we can identify a subset of the general semantics for DFXP 1.0, and get a promise of two implementations, we can go forward.  If that doesn't happen soon this feature should be removed.

JB:  Perhaps we could step back from dF's defining characteristics and just go to a "this region flows" without making comments about how.  The presentation mechanisms will differ. There is a great deal of interest in moving content into multiple outlets; presentation may not matter.

AK:  A tool could decide to render something in a different way.  Roll-up is definitely important.  Just say "this region is roll-up with X number of lines; this region is not".  When text starts coming in, just fill up the region based on number of lines.  Currently DFXP is too complex for this.  Need a simplified way of doing just that.  I can make an implementation in the near future to illustrate.

SH:  Difficult to interact semantically with timeContainer.  I might want it expressed differently.  Need implementations to see behavior.

AK:  Have asked MTV for a link to see how they're doing their version of roll-up.

SH:  GA is going to take a look at providing clearer semantics, JB is going to look at SS's implementations, SH will look at semantics, GF and AK will send links of demos.  Will review where we are at the end of January.

GF:  (Makes plea for easy implementation of roll-up captions.)

SH:  If we don't have this done by the end of January, should we extend the charter?  Will discuss in January.

SH:  Next:  default timeContainer for <body>.  Currently is sequential.  Seems to be a mistake.

GA:  It's the default of par on div.  Should be the other way around.  In general, divs are going to be targeted to a single region and the text that goes into a given region is going to be sequential by default.  Content to multiple regions are going to be in parallel.  For some reason we got it backwards.

SH:  Yes.  The default should be there to minimize the amount of timing semantics to specify.  Need a body with a div with time semantics on it.  Other problem is that implicit duration is zero in sequential context, that makes <p> a problem.  Most of our examples now have explicit timing.  Not sure what the best default is, but what we have isn't right.  GA will write up his thinking on it and so will I.

GA:  Will review minutes from old meetings to see why we got it backwards.

SH:  Next:  extent.  extent is defined on the body element, but given the way that body flowed into a region works, body is not defining its own extent but that of the parent or its grandparent.  Tricky semantically and illogical to be on the body.  Should move it back to the tt element.

GA:  Did it that way as a compromise to the SMIL working group.  It was the wrong move to make at the time.

SH:  Now that I understand the region processing model I think the implementation is wrong; move it back to tt element.

GA:  SVG can specify W x H on top-level element; is useful to do it this way.  In our case you have to dive into document farther to find that information.

SH:  Since HTML WG has made noises about inlining video element, that's another argument.

SH:  ACTION:  move extent back to tt element.  GA will do this in the spec.

SH:  xml:space="preserve".  Timed text can appear in a p or span.  The way we have it at the moment, we must insert anonymous spans between divs and body elements.  We changed the rule in 9.3.2.  Still doing xml:space as per spec.

GA:  Another case of fixing semantics.

SH:  Qualify 9.3.2 (7) to map anonymous spans to fo:inline only when the parent is p or span

SH:  inherit for anonymous spans.  We have some properties which don't actually get inherited but they apply to spans.  Must explicitly say that they get inherited.  Must amend some wording about how things are inherited.

GA:  Must promote the notes to normative text.

SH:  The values for opacity.  Problems:  the values for opacity are different than those for alpha.  Sort of basing our semantics on CSS but they have retracted their old semantics.  We should do the same, but don't want to incur dependency on CSS 3 because that is moving very slowly.  We ought to make values consistent, though.

Other problem is opacity is defined as a floating value.  Would prefer smaller set of values and proposed a restricted set from XSD spec and restrict the number of decimal places a processor must have.

GA:  Do not support latter proposal because this was adopted from SVG.  Can handle by converting opacity to alpha and vice-versa as I said in earlier message.  We don't actually specify color space that must be supported by processors.  If it supports two levels, four, 256... we don't specify.  Not sure if we need to do that for alpha.  Not sure how it affects testing.

GA:  I gave an example of transformation from alpha to opacity and opacity to alpha.  Took about six steps.

SH:  Will look at GA's message and discuss at a later meeting.

SH:  Item #7:  mostly editorial and does not affect semantics.  Will continue to discuss this item with GA.

SH:  Item #8:  marking additional processing requirements with a requiredExtensions attribute.  Need attributes to indicate particular kind of processing, such as extensions.  There is no concrete proposal for what that text would say.  This would accommodate ccPlayer behavior e.g., using xml:lang to switch languages.  GA can write text to talk about extension attributes.

GA:  Three attributes have been discussed previously-- requireFeatures, requiredExtensions and requiredTypes.  Previously agreed to add those three to tt element.  rE attribute can be used to express a standardized extension or one that is industry specific, allows author to express that extension must be supported to process file correctly.  Reasonable way to express that xml:lang is being used as a switch, for example.  Must define an extensions IRI; may not need to do that now.

SH:  What we need is some candidate text and an example; something hypothetical that shows what we mean that doesn't define semantics but shows how you point to something.  Already done in SVG and SMIL; could copy or reference this.  Can GA do that quickly?

GA:  Can propose the text quickly.  Am making progress on reconstituting the current CR and new framework to enable me to start implementing changes in the draft, so will do soon.

SH:  Will need to see a new draft early next year to meet our time constraints.

GA:  It's possible.  Only now making progress and it's going quickly.  Will probably have new text to review in January.

SH:  Great.

Item #9:  tts:display not supported on region, but seems to be necessary.  Seems incomplete that regions can't have display:none so that they are rendered but invisible.

GA:  One problem is that we decided to forego formatting semantics and push it to XSL.  Defined our formatting as mapping DFXP to XSL.

SH:  Display can be inherited in CSS, but our semantics don't say that.

SH:  We map to XSL elements those that have display="visible."

GA:  We say that content maps to the region as long as value isn't "none."

GA:  Specifying a property on a region and making it inheritable is different that applying the property to region.

SH:  We only map regions that are temporally active.  display on region is important will actually get used.

GA:  Inherited is different is whether than having the property apply to region itself.  We can have inheritance on the content region.  Must distinguish between inheritance and formatting of the element itself.

SH:  Right, but why can't display be applied to region?  We have this functionality based on time, and is something people will expect to.  If put display="none", display is still visible.  Is surprising this doesn't work and see no reason why we can't implement it.

GA:  Not sure why this is.  Will investigate.

SH:  Will continue to discuss on list.  MSFT is now an official member of the group, by the way.  Next telecon is January 9, 2009.  Will get survey of outstanding issues out soon; please review and return by January 5!

GA:  Now that you're a member you can access the database, so start entering resolutions and unresolved issues.

SH:  Will do this, and will review old minutes for items.

GA:  Am impressed with the current level of activity in the group.  Happy to see this.

SH:  Reasonably confident that we can get this done on time next year.  More industry groups are getting interested in this, so we want to make sure we get this done in a timely manner.  Happy holiday and see you next year.
Received on Friday, 12 December 2008 17:53:21 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 5 October 2017 18:24:03 UTC