- From: Geoff Freed <geoff_freed@wgbh.org>
- Date: Fri, 21 Nov 2008 08:41:54 -0500
- To: Sean Hayes <Sean.Hayes@microsoft.com>, public-tt@w3.org
> I have been out of the office for a while, and I did not see any > minutes for last weeks call. David is away for this week and > possibly next week, so I have put together a short agenda for today. > odd-- i sent them last friday. i've pasted them below. note the discussion about the test suite. g. ====== 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. On Nov 21, 2008, at 8:35 AM, Sean Hayes wrote: > > I have been out of the office for a while, and I did not see any > minutes for last weeks call. David is away for this week and > possibly next week, so I have put together a short agenda for today. > > Time will be 10am Eastern, 3pm UK, 7am pacific. > > 1) Review action items > a) Still need to get existing spec issues into tracker > > 2) Review progress and status. > a) Update by group. > > b) New spec issue? > <head> element may not take external or metadata > attributes? Is this by design, or oversight. > > 3) Testing > a) Update by group > > 4) Goal setting > > 5) AOB > SMPTE caption effort update. > Kickoff meeting is 4th Dec in NYC. > Link for signing up > http://www.smpte.org/standards/meeting_schedule/23b_inaugural/ > participation > > > Sean Hayes > Media Accessibility Strategist > Accessibility Business Unit > Microsoft > > Office: +44 118 909 5867, > Mobile: +44 7875 091385 > > > >
Received on Friday, 21 November 2008 13:42:47 UTC