TTWG minutes 11/14/08

TTWG minutes 11/14/2008.  Note several action items below.

Attending:
David Kirby (DK, chair)
Geoff Freed (GF; scribe)
Franz de Jong (FJ)
Philippe Le Hegaret (PH)

Regrets:
Sean Hayes (SH; chair)
Glenn Adams (GA)
Mike Dolan (MD)
Andrew Kirkpatrick (AK)

======

DK:  Status of JW Player implementations?

PH:  What's the status of the implementation spreadsheet?

DK:  Latest is not yet on the server; awaiting more info from AK  
regarding JW Player.  Concerned that current implementations are  
merely variations of the Adobe player.

PH:  Would the Adobe implementation become a baseline to which  
everyone must follow?

DK:  Concerned about xml:id; Adobe just uses id.

PH:  Maybe Adobe could make the player support xml:id.

GF: NCAM players also just use id.

PH:  Would be willing to change to xml:id?

GF:  Will ask to see what's involved and report back to list.

ACTION:  GF will investigate the possibility of xmml:id support in  
NCAM implementations.

PH:  Otherwise we should change DFXP to support id rather than xml:id.

DK:  Franz, can you work fully in the group, and perhaps revive the  
EBU conversion software available for implementation?

FJ:  Resources may be a problem for this work.  Maybe not in current  
timeframe.

DK:  Will stick with what we have for now.  Or could cover what is  
necessary for European subtitling in our profile.

FJ:  Full implementation would take a lot of work.

PH:  Send latest version of spreadsheet to list and server.

DK:  Will send latest spreadsheet, PH will upload.

DK:  Microsoft's current public implementation is rather thin; lab  
version sounds more complete, however.

DK:  Looking at Subtitle Workshop again; had difficulties generating  
DFXP with it.  Seems that others are having problems as well.   
Current DFXP support may be broken and may be left off the list as a  
result.

DK:  Test suite:  no word from Glenn yet.

PH:  We should consider revising the current tests.  They're too  
complex for current implementations.  Should probably stick to  
something that caters to current implementations.  Timeframe is  
limited.  Perhaps use profiles?  In one year, we can always revise it  
to be more complete if this is necessary.

GF:  Agreed-- tests are very complex and can't be used by NCAM.  Is  
it necessary to exercise every single feature?  For example, in a  
test for tts:color, can we specify just one color?

PH:  Since we specify three methods of naming colors, just be sure  
there are tests which show each method.

GF:  What about timing?  Should we require it in the test-suite  
files?  After all, it's timed text: no time, no text (with credit to  
Dave Singer).

DK:  Must we create all new files, or can we use Glenn's as template?

PH:  Will take time to revise either way.

DK:  For generating the PNGs, can we use Glenn's DFXP viewer?

PH:  We could.  We could ask Glenn to create the PNGs from his viewer  
using the new test files.

DK:  And this would be a check to make sure his agent has done the  
right thing.

DK:  Should divide this task to speed the process of creating simpler  
test files.

PH:  Yes, but should identify sections that are worth separating.  We  
don't need to test all the features.  Profiles?

GF:  Will send a few NCAM test files to the list.  Check the files  
and see if they are useful.

ACTION:  GF to send simplified test-suite files to list for review.

DK:  Will we retain Glenn's test suite in the end?

PH:  We should save them in the archive.  Can use later for  
implementations that support more complex presentations.

DK:  Will decide later how to divide the work to create new tests.

PH:  Still have the <region> problem.

DK:  Thought that we do define a root container region, but that  
there was an infinitely large canvas on which we can write before  
naming regions.

PH:  Current implementations (e.g., NCAM and Adobe) are targeting a  
defined region at the bottom of the video.

GF:  Adobe and NCAM implement this slightly differently.

DK:  If the file itself doesn't define a display region, then the  
player should have a default display region.

PH:  This is not in the spec; we can't specify because we have no  
knowledge of the display device.

DK:  Do we need to define default behaviors?  If no region is  
defined, the text should be displayed but we should not (or cannot)  
say *where*.

DK:  Up to the implementor to display the information.  Could be a  
user setting somewhere.

DK:  Styling:  All style attributes are currently defaulting so that  
text is displayed (e.g., white text, proper line height, etc.).  So  
if we don't specify region or styling, then do we get sensible  
behavior?  We probably do.  Should verify.  Ask Glenn to be sure.

PH:  Initial behavior of @color is transparent, though.

DK:  True.

PH:  <p> doesn't say anything about color.  Seems that if you don't  
specify text color you get transparent text.  But then, color value  
is inherited.  Do we define on the <body> a default color?

DK:  Would only inherit color if you set that attribute to inherit.

PH:  tts:color has an initial value = transparent, but you can also  
inherit initial value.

DK:  Only if you set tts:color="inherit".

DK:  Actually, if you don't specify tts:color, you *do* inherit from  
parent.  So if <p> has tts:color of white, that is inherited.

GF:  So current default color of transparent should be changed to  
something visible?

PH:  Yes, should change to some other value.  CSS says that color  
default depends on user agent.

DK:  Our goal should be able to generate a very simple DFXP file (one  
that includes just timecodes and unstyled text, for example) that  
will display via sensible defaults.

ACTION:  PH will look at current DFXP default values and make sure  
they display correctly (or sensibly).

DK:  Have we then avoided the <region> problem?  If no region is  
defined, then it's up to the user agent?

PH:  We do want to say that the text must be displayed, but we don't  
want to define default region.

PH:  If we create a profile that doesn't allow <region>, that is  
close to what SmilText is.  If that is true, it may be easier to  
stream this simpler profile.

DK:  We aren't obliged to actually have regions in DFXP (9.1.1 says  
author can specify zero or more regions).

PH:  But 9.3 may create a stipulation that there be at least one region.

GF:  Could users construe this to be a default region?

PH:  They could, if we rewrite 9.3.  9.1.1 would not have to change.

GF:  When we go to last call, must the test suite be complete?

PH:  It should be solid by the time we go to last call.  If we divide  
the work, this is possible.  Updating the spec to reflect things that  
we want may be more complex, however.

DK:  What about test reporting?

GF:  Found that SMIL and SVG test suites were quite simple in  
structure, which made them easy to read and understand.

DK:  If we adopt a simpler approach with our revised suite, we could  
follow their testing procedure?

PH:  True.

GF:  Could supply a simple checklist or spreadsheet for users to  
download or use online.

PH:  Yes.  Verification and reporting would be a manual process.

DK:  At the EBU meeting this week, there was approval for Franz to  
join the group as an invited expert.  And there will be an EBU group  
of interested parties looking at DFXP and caters to the needs of the  
EB subtitling.

PH:  They may need to come up with their own profile that suits their  
needs.

DK:  Will discuss to see if a profile will be required or not.  If  
we're lucky the profile we discussed earlier will be one that  
everyone can use.

FJ:  That would be ideal.

PH:  It may be worth spending time determining how to stream files  
based on that profile.

FJ:  Important to be able to able to carry this data in MXF files.

PH: Should we look into this?

DK:  No.  This is a standard format from SMPTE.


Meeting adjourns.

Received on Friday, 14 November 2008 16:39:03 UTC