W3C home > Mailing lists > Public > public-tt@w3.org > April 2009

Re: TTWG minutes 03/27/09

From: Geoff Freed <geoff_freed@wgbh.org>
Date: Thu, 09 Apr 2009 06:46:03 -0400
To: Timed Text Working Group WG <public-tt@w3.org>
Cc: Sean Hayes <Sean.Hayes@microsoft.com>
Message-id: <C6034A2B.A475%geoff_freed@wgbh.org>

here you go- let me know if problems.

g.

======

Timed-text working group minutes 03/27/2009

Present:
David Kirby (DK, co-chair)
Sean Hayes (SH, co-chair)
Geoff Freed (GF, scribe)
Glenn Adams (GA)


Regrets or absent:
Philippe le Hegaret (PH)
John Birch (JB)
Andrew Kirkpatrick (AK)
Franz de Jong

=============================
IMPORTANT NOTES:

1.  Must discuss SH's proposal by next meeting (April 3).
2.  New implementation spreadsheet will be issued April 17.


=============================



Minutes from call:

DK:  Will implementations which are currently not able to cover all features have those added by July 1?

GF:  Next version of CC for Flash will be issued soon but will probably not change the implementation chart.  New version will be mostly fixes; some improvements.

GA:  My implementation will include a subset of dynamicFlow, also expect to have some of the cell- and frame-based timing support.

DK:  Good.  Should have forwarded to Sean GA's previous implementation.

SH:  Philippe already did it, but haven't used it yet.  In my implementation, I can do cell-based positioning.  Can't do 2D charactrs yet but can do cell sizes.  Those are the major changes.

GA:  Won't have bidirectional support in my implementation.  Will have vertical text layout.

SH:  Probably won't have any bidi implementations; perhaps Philippe's?

GA:  I implemented it a few times based on current properties, but that's probably something we can assume a transformation engine can support.

SH:  Features in danger include the blur around outlined fonts; 2D character features as well.  Overall the spreadsheet is looking pretty good, however.  There's only one roll-up implementation.

DK:  AK may be instituting a roll-up implementation in the Adobe player.

GA:  And John Birch may have one.

DK:  Do we need to update the implementation chart?

SH:  We will.  One problem is that the test suite has hacks in it so the Adobe implementation can pass.  Many cases specify no regions.  We must figure out whether we're going to have two parallel suites (one for proper semantics; one not), or what?  Also, does Glenn think he can get the editing done in time according to the schedule?

GA:  Yes, can do edits quickly now.  If I have a list of things to tackle, I can do them ASAP.

DK:  Regarding regions... didn't we agree there would be a default region?

SH:  Yes, but GA's implementation doesn't do anything if there's no region specified.

DK:  There's no longer a need to have a region, is there?

SH:  True, but I've implemented a default region, so my player passes the test.  The old XFSI player won't pass, however.  Needs to be updated to have a default region.

GA:  That's on my list of updates; will be in place before July 1.

SH:  Should agree on a date to update the spreadsheet.

DK:  When will GA be done updating the implementation?

GA:  Must look at spreadsheet, then can identify what things we have to add.  Should have new version in 8 weeks.

DK:  Should we shoot for mid-April?

SH:  Sounds good.  April 17?

DK:  April 17 it is.

SH:  We have a new appendix that specifies what a minimal implementation must have.  We should probably add a full profile as well as a basic profile to go with the transformation profile.  Should be able to select from the test suite what profile you want to test.  Not easy.

DK:  The new test files tend to be basic, no?

SH:  That should make it easier.  I'm still working on this (defining features in profiles for the test suite).

DK:  Next item... catch up with GA on the revisions to the document.

GA:  Haven't processed my edit list since the last meeting (just got back a few days ago and am catching up).  Should be able to catch up in the next week or so.

SH:  There are five open actions for you in the database; review and ask questions.

DK:  SH's proposal that was e-mailed to the list is next.

SH:  Summary:  Began thinking about feature implementation and wasn't happy with the way that it was a list of namespace strings and attributes.  Came up with the idea of a profile element in the <head> which has a features element and extensions element.  Works as with <styling>-- each feature is now its own element with its own value set.  (See SH's proposal on the list.)  No semantic changes as such.  I like the idea that we could have a profile be specified by URI and wouldn't have to embed it in the document.

GA:  The current proposal is based on the mechanism used in SVG/SMIL and uses the same attribute names.  While the same semantically, introducing the element structure will require a lot of work on the spec.  Should think about the degree to which the changes are construed as normative which might trigger us returning to working-draft status.

SH:  We talked about that last week.  We are going back to WD status, in fact, on a fast-turnaround basis.  PH will revise the timescale.  Not expecting floods of comments.

GA:  Will require another last call?

SH:  Yes, minimally.  SMPTE would like to have a draft of current changes.  Would like to have a new draft this week-- GA?

GA:  Actions 33-36 are related to editing.  Can do these this week.  Can handle default <body> semantics, too.  Others?

SH:  Will check and contact you.  If you can get a working draft out this week, that would be helpful.  Changing the actual schema is a lot of work, but the prose changes would be isolated.

DK:  Do you need another week to think about this proposal?

GA:  Yes.  We have to consider the trade-off between similarity to current SVG/SMIL approach or doing something different.

SH:  This approach is more congruent with the way that we handle styles.  Don't have to decide today.  Must discuss this proposal by next meeting (April 3).

DK:  Franz wanted to discuss 3D captioning.

SH:  Came up in SMPTE.  New WG wants a captioning spec for 3D captioning.  Apparently there's research into this and we need to have some kind of depth mechanism.  My view is that this is a container issue and not something we need to specify in DFXP.  We assume you're drawing regions into a 2D plane.  If we're going to think about moving regions in a 3D space, we do have attributes for that.  We have zIndex, but that doesn't apply to depth.  Not sure what measure we could use for that.

DK:  We'd have to introduce a third dimension in the root.  zIndex isn't suitable; we need something else for third dimension.

SH:  If we have depth, then a stacking order doesn't make sense.  We'd have to replace zIndex with something like zDepth.  Depends on the viewpoint (being able to see around corners, e.g.).  Will have to consider multiple viewpoints.

GF:  Sounds fascinating, but time-consuming and complex.  Do we have time?

SH:  Probably not at this point.  We should consider for next version.  Should consider having multiple viewing planes for next issue.

DK:  We just have to have awareness of 3D captioning for the future.

SH:  I think we just agreed that GA will fix most open issues for next week.  Still need to discuss action 20.

GA:  I volunteered for those earlier, but could somebody else take that one on?

SH:  I am doing that right now, so i'll take #20.

GA:  Will make that change.

(GF leaves call; somebody else takes over the minutes.)


======


On 4/8/09 8:55 AM, "Sean Hayes" <Sean.Hayes@microsoft.com> wrote:

Geoff, not sure what format these are in. can you resend as plain text?

I took a few notes after you left:

Default style issue:
  original philosophy - force the author.
  Action Leave to Phillipe.


Action 20 - reassigned to Sean
Others - Glenn to deal with

Issues - Glenn to address as many as possible. By next week; will post anything he finds controversial

Sean to deal with issues 29, 30, 31, 38.


Sean Hayes
Media Accessibility Strategist
Accessibility Business Unit
Microsoft

Office:  +44 118 909 5867,
Mobile: +44 7875 091385
Received on Thursday, 9 April 2009 10:46:47 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 2 November 2009 22:41:42 GMT