- From: Pierre-Anthony Lemieux <pal@sandflow.com>
- Date: Tue, 17 Jun 2014 08:41:31 -0700
- To: John Birch <John.Birch@screensystems.tv>
- Cc: Michael Dolan <mdolan@newtbt.com>, Timed Text Working Group <public-tt@w3.org>
> However, I would suggest that a ‘useful’ implementation might make the text > available to another process or output device whilst also still decoding the images. An application that wish to make text available to an output device for use by a user can provide a separate Text Profile document. I do not see a reason to introduce another means of delivering Timed Text to the user. Best, -- Pierre On Mon, Jun 16, 2014 at 8:33 AM, John Birch <John.Birch@screensystems.tv> wrote: > I find it difficult to reconcile a design decision with a requirement… > unless the original CFF(?) use case explicitly demanded a single > document…(which is not clear from below) ;-) > > > > Regardless… I understand the desire to simplify the implicit requirements on > a notional processor to only loading, decoding and rendering a single > document and therefore I do generally support the forcedDisplayMode concept. > > For me this is the inclusion of two logical streams of (connected) content > within a single document. Further, I do see this as setting a precedent. J > > > > With regards to adding text to the image profile, the proposal was only ever > to consider the text as ‘alternative content’. However, I would suggest > that a ‘useful’ implementation might make the text available to another > process or output device whilst also still decoding the images. (e.g. > support text output to a braille display simultaneously to image rendering). > I agree that the text should not be considered ‘normal TTML text’ as (under > that specification) it would need to be displayed. Instead I suggest that > the (equivalent) alternative text should be included as an attribute of the > image… and thus could not have an independent existence from an image? > > > > Ideally I would like this to be a change to the current IMSC specification. > > > > Best regards, > > John > > > > John Birch | Strategic Partnerships Manager | Screen > Main Line : +44 1473 831700 | Ext : 2208 | Direct Dial : +44 1473 834532 > Mobile : +44 7919 558380 | Fax : +44 1473 830078 > John.Birch@screensystems.tv | www.screensystems.tv | > https://twitter.com/screensystems > > Visit us at > Broadcast Asia, Marina Bay Sands, Singapore 17-20 June, Stand 5E4-01 > > P Before printing, think about the environment > > > From: Michael Dolan [mailto:mdolan@newtbt.com] > Sent: 12 June 2014 14:21 > > > To: 'Timed Text Working Group' > Subject: RE: ISSUE-309 (Image profile fails WCAG 1.2): Image profile needs > to permit text equivalent [TTML IMSC 1.0] > > > > In this case, it is less about whether we agree. I am clarifying what the > requirements are in the liaison. The design for a single document with > forcedDisplayMode was developed by a collection of movie subtitle authoring > companies, and a collection of device manufacturers. Us debating > alternative designs doesn’t change the requirements. If W3C designs > something else that requires simultaneous multiple document decoding and > merged presentations, that would fail to meet the requirements. > > > > Regarding adding text to the image profile: > > > > “…including text in image profile documents would be an acceptable solution > to you.” > > > > Yes, as long as it is not required, and it is clearly signaled as > “alternative” text in some manner. It would be incorrect to include normal > TTML text since that would have to be displayed and thus result in totally > incorrect output. > > > > Regards, > > > > Mike > > > > From: Nigel Megitt [mailto:nigel.megitt@bbc.co.uk] > Sent: Thursday, June 12, 2014 5:51 AM > To: Michael Dolan; 'Timed Text Working Group' > Subject: Re: ISSUE-309 (Image profile fails WCAG 1.2): Image profile needs > to permit text equivalent [TTML IMSC 1.0] > > > > I understand the argument but I don't agree. This may come down to a 'system > model' difference. > > > > They are both schemes in which multiple conceptually different content > streams need to be made available, and the presentation of one or or more > from the group is conditional on settings in the decoder, perhaps defined by > the user. > > > > One could equally well generate a solution in which for 'forced display' > content the content provider must provide two or more documents and ensure > that the combined content of the group never exceeds the constraints of a > single document, in complexity, overlapping regions, xml identifiers etc. > Then the decoder must select the content from the appropriate documents and > combine them client-side for display, which could be a defined > 'pre-processing' task. > > > > If necessary we could even signal within documents 'this forms part of a > group that may be combined for collective presentation' with a new 'group > identifier'. Documents with different group identifiers would offer no > guarantee that they may successfully be combined in this way. > > > > A solution like this would be extensible for live streams in which a group > of temporally consecutive documents could be assigned the same group > identifier and successfully combined for presentation – in that case they > would probably be exclusive to each other temporally rather than spatially. > > > > > > By the way, Mike, I note that you've previously indicated that including > text in image profile documents would be an acceptable solution to you. > > > > > > Kind regards, > > > > Nigel > > > > > > On 12/06/2014 12:34, "Michael Dolan" <mdolan@newtbt.com> wrote: > > > > They are not the same. > > > > forcedDisplayMode text is embedded in a single document since otherwise a > decoder would have *simultaneously* decode two documents (one with forced > content and one with non-forced content) and merge the output over the > visual object. > > > > The desire to force the image profile to contain alternate text is solved > with a text profile document. Only one or the other document is decoded and > presented since they each produce substantively the same visual results. > And, even if it is desirable to decode both simultaneously, they would not > have to be merged onto the visual object. > > > > Regards, > > > > Mike > > > > From: Nigel Megitt [mailto:nigel.megitt@bbc.co.uk] > Sent: Thursday, June 12, 2014 4:10 AM > To: 'Timed Text Working Group' > Subject: Re: ISSUE-309 (Image profile fails WCAG 1.2): Image profile needs > to permit text equivalent [TTML IMSC 1.0] > > > > I've updated this issue with the following note: > > > > The proposed resolution to this is not consistent with the approach taken > for forcedDisplay (see also Issue-312). In the latter case it is stated that > the two types of content must be provided in the same document. In this case > it is stated that the content provider may optionally provide multiple > documents. > > A simple resolution to this would be to permit text to be included in the > image profile. > > > > Nigel > > > > > This message may contain confidential and/or privileged information. If you > are not the intended recipient you must not use, copy, disclose or take any > action based on this message or any information herein. If you have received > this message in error, please advise the sender immediately by reply e-mail > and delete this message. Thank you for your cooperation. Screen Subtitling > Systems Ltd. Registered in England No. 2596832. Registered Office: The Old > Rectory, Claydon Church Lane, Claydon, Ipswich, Suffolk, IP6 0EQ >
Received on Tuesday, 17 June 2014 15:42:20 UTC