TTWG minutes 04/09/09

Timed-text working group minutes 04/09/2009

Present:
Sean Hayes (SH, co-chair)
Geoff Freed (GF, scribe)
Andrew Kirkpatrick (AK)
Philippe le Hegaret (PH)
Glenn Adams (GA)

Regrets or absent:
John Birch (JB)
Franz de Jong
David Kirby (DK, co-chair)

======


Minutes from call:

AK:  Have not yet implemented roll-up caption capability in Adobe implementation.

GF:  NCAM just released CC for Flash with roll-up implementation, but uses non-dynamicFlow implementation.  Uses displayMethod element instead.  Will speak to Brad about exactly how it was done and will post to list.  New version of CC for Flash/ccPlayer is at http://ncam.wgbh.org/webaccess/ccforflash/index.html.

SH:  If we don't get two implementations of dynamicFlow, that element will be in danger.  Getting implementations before July 1 will be a challenge.

GF:  So if no implementations by July 1, then dynamicFlow goes away?

SH:  Yes.

AK:  I could get a developer to extend the default behavior in our player (support dynamicFlow), but would not be a public version.

SH:  A private version is fine, so long as we can show it to the W3C chairs.  Can even be done under NDA.

AK:  It's a matter of parsing correctly and setting up the animation process.

PH:  Demo doesn't have to be on the W3C Web site.

SH:  Sent out an updated version of the spreadsheet.  Have been working on my implementation (Timed Text Pad).  Most results are as they were before but had to delete incorrect tests.  Some have been updated as well.  Was minimal.  Overall we're in good shape.  In styling, reverse oblique is not supported.  Glenn probably supports this, however.

PH:  Is spreadsheet up to date according to your tests?

SH:  No, not yet.  We are supposed to be updating spreadsheet by April 17.  If we can run our implementations in the new test suite by that date we'll be okay.

PH:  Assuming that TTP is up to date?

SH:  Yes.  I have no results yet for XSFI viewer, but assuming that Glenn will parse nearly everything.  His column is all green on assumption of pass.  TTP is the only column that is actually accurate because it's my implementation.  All other columns are based on a previous version of the test suite, but will need to be brought up to date.  Wanted to send this around to make progress.  There's a lot of red in the Adobe columns but that's not necessarily a problem.  Overall balance between all players is good.

Not currently planning to put a lot of time into reverse-oblique at this time.

There's a problem with one of the tts:overflow tests.  Scrolling overflow is supposed to be for roll-up mechanism, but nobody passes that test anyway.  The test is overflow006.

Also a problem with tts:padding.  Assumption in the tests is that it works with <p> divs.  Spec says it works with regions.  We have to change the spec or the tests.

showBackground-- why did PH pass two tests but not the first one?

PH:  Will look into it. Can't remember why.

SH:  Implementing showBackground will be a fair amount of work for me.  Will plan to do it but not sure when.

Next problem is lineThrough syntax.  Not sure what we're supposed to do.  There may be ambiguity in tests.  I passed TTP based what's in the spec, not the test suite.

GF:  Glenn already made the spec conform to XSL-FO.

PH:  Latest version of the spec will have this change.

SH:  Next problem is with textOutline and blur.  Nobody else implements it.  I did have an implementation at one time and may put it back in.  Not supporting blur radius, however.  Glenn will probably implement it.  Even if he is, that's only one implementation.

PH:  We won't support it.

GF:  NCAM won't support it, either.

SH:  Does Flash typography support textOutline?

AK:  It's a possibility, but probably not likely to happen for DFXP implementation.  Will look into it.

SH:  GA said that he's not supporting unicodeBidi, so the only implementation is PH's based on HTML.  Not sure if I will implement it.  GA thinks we can make a special argument for it but I'm not sure.

PH:  The internationalization working group may want it and so may want to do an implementation.

SH:  Have tested Urdu script and that works, so not sure what is required to make unicodeBidi work.  I don't understand it, so maybe we could have the IWG help us with this.

PH:  May ask a IWG rep to join the call.

(GA joins call)

GA:  My opinion is that we don't need to do anything for unicodeBidi; just include it in the spec and leave it at that; refer to existing implementations in XSL and XHTML.  We need to ask why we're being asked to do implementations for every single feature.  Some are already being implemented elsewhere.

PH:  We can't recommend authors to use it for the presentation aspect if we can't prove that it works.

GA:  Are you saying that to be able to define a feature in DFXP that we have to make it work in one of OUR implementations?

SH:  No; if nobody supports it anywhere then we can't recommend it, though.

GA:  We're not making recommendations about what authors use, though.

PH:  We want this to be useful, as well.

GA:  I disagree.  We have to aspects:  implementation and presentation.

PH:  I'm not saying that we remove the feature but not include it as a mandatory feature of the profile.

GA:  Let's be clear about whether we're saying it's mandatory or optional.  My assumption is that we will require mandatory features and we have to demonstrate two implementations.  But we don't need two implementations of every optional feature.

SH:  But we need to demonstrate that every feature works in the spec.  If features are implemented elsewhere, fine.  But wherever possible we shoud have this stuff rendered.

GA:  Yes.

PH:  Do you have support for texOutline?

GA:  Planning to have one by beginning of July.

SH:  There are two aspects:  textOutline and blurRadius.

GA:  There is support for blurRadius in CEA-708.  I believe John Birch has an implementation.

SH:  These things are possible (using SVG to implement this feature).  But if we say that support is possible IN THEORY, that won't pass the directors.

GA:  Not sure I agree.

PH:  But what about the presentation profile?

GA:  Not arguing for textOutline as mandatory; I believe it should be optional.

SH:  Not sure this counts as an implementation.  If you can show me an XSL processor that does this, fine.

GA:  But it's the final rasterization process that is trivial.  SVG does this.

PH:  Do we know a processor that will generate a textOutline process?

GA:  I can do one in English.

PH:  So you're saying that in theory it's possible and so we should keep it in the spec.  Not buying this argument.

SH:  We need something concrete by the time we submit DFXP to the directors.

PH:  Problem is we need a DFXP engine to show these things.

GA:  This goes back to the problem of mandatory vs optional.

SH:  Two issues:  demonstrating features and the issue of mandatory profile.  We have to be able to demonstrate two implementations of each feature.  So if we can say there's a transformation engine that outputs SVG (for textOutline) as we expect it to be rendered, that's a demonstration.  But nobody has done this.  That's not a strong argument.

GA:  I disagree.  By that argument we'd need a transformation that does the same with bidi.

PH:  My implementation supports bidi.

GA:  We still have disagreement whether we require implementations for optional features.

SH:  I think we do.  We want what we say to be practically implementable.  Whether it's optional or mandatory is separate.  It's about the correctness of the spec.

GA:  Does anyone think that our implementation of texOutline is a problem?

PH:  We don't know.

GA:  I can give you an English description.

PH:  Not good enough for directors.

GA:  Good enough for me.  I don't believe that not having an implementation makes it not usable.

PH:  Good luck trying to convince the directors of this.

GA:  So we have to have an implementation of every optional feature?

PH, SH:  yes.

GA:  I argue that if a feature is well-defined semantically and someone can create a transformer to implement it correctly, then that should be enough.  There is no requirement of proving an implementation.

PH:  But the director might actually want to see the implementation.

SH:  We shouldn't get too hung up on this; there are only a few features that have this problem.

GA:  But you'll have to remove a large percentage of features.

PH:  Not true.

SH:  We're very well covered at this point.  The two we're not going to see are probably textBlur and unicodeBidi.  But I think I can buy the argument of the XSL unicodeBidi.  textBlur is the only one.

GA:  I can implement it in a day.  I can probably implement the features that are missing in the implementation spreadsheet.

SH:  We need this by July 1.

GA:  I don't see a problem with that.

SH:  AK is looking into an implementation of dynamicFlow, and we assume you are,  too.

GA:  Will implement roll-up; not sure of others.

SH:  Next item:  open issues as listed in agenda.  GA, where are we with this?

GA:  Will have update by tomorrow.  Issue 40 is still an open item for me.  Required going back and doing editorial changes to 8.4 and 8.5.  Have combined them into a new section called Style Resolution.  Has four subsections.

Issue 15:  I think there was a proposal to go back to XML 1.0.  I have no problem if that's what people want.  I need a consensus from the group.  Stay with 1.1 or go back to 1.0?

SH:  I don't remember why, but we had a problem with 1.1.

PH:  I believe our spec refers to 1.1 but all our tests use 1.0.  If I put 1.1 in the tests we'll fail the test suite.  We can use XML 1.0 (easiest solution), or we can try to be independent of the XML version and use XML infoSet, which would require more editorial work.

GA:  What aspect of 1.1 would cause tests to fail?

PH:  Most of our processors would probably reject the files.

GA:  XFSI implementation would handle both without any change.

SH:  My preference would be to go for the infoset rule which would allow for other implementations such as embedding in other container formats.

PH:  Likewise.

GA:  We do define an Annex A and an abstract DFXP doc in terms of an abstract doc that adheres to that infoset... May already have handled this without significant issues.  Will check.

(GF leaves call; SH will post remaining minutes).