- From: John Birch <John.Birch@screensystems.tv>
- Date: Mon, 23 Jun 2014 05:26:49 +0000
- To: "'pal@sandflow.com'" <pal@sandflow.com>
- CC: "'mdolan@newtbt.com'" <mdolan@newtbt.com>, "'public-tt@w3.org'" <public-tt@w3.org>
I am afraid that I see us at an impasse. I am unaware of specific normative prose in IMSC that enforces the requirement that accessibility is provided as a separate text profile track. I cannot support IMSC if it fails to recommend image profile *documents* that meet WCAG guidelines. It seems a small point to support alt text equivalent strings within image based documents... And I am surprised at the resistance to this concept. Accessibility is all about in-band support. It is about *equal* access... It is decidedly not about separate optional provision at the munificence of the publisher. 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----- Original Message ----- From: Pierre-Anthony Lemieux [mailto:pal@sandflow.com] Sent: Friday, June 20, 2014 06:43 PM To: John Birch Cc: Michael Dolan <mdolan@newtbt.com>; Timed Text Working Group <public-tt@w3.org> Subject: Re: ISSUE-309 (Image profile fails WCAG 1.2): Image profile needs to permit text equivalent [TTML IMSC 1.0] Hi John, Thanks for taking another stab at the text! I like the detailed guidance is writing descriptive text to be associated with an image. I have only one blocking concern with it. >The text equivalent string is intended for use by screen readers or reproduction by braille devices etc. In IMSC 1.0, content intended for use by screen readers or reproduction by braille devices etc. is delivered using a Text Profile document, so the sentence needs to read "The text equivalent string is not intended for use by end user devices, e.g. screen readers or reproduction by braille devices etc. Such content is delivered using a Text Profile document." Note that I do not expect the text to be that specific in TTML 2.0, when we get around to implementing image support, since TTML 2.0 will probably wish to support applications that specify in-band content for use by screen readers or by braille devices. Best, -- Pierre On Fri, Jun 20, 2014 at 3:43 AM, John Birch <John.Birch@screensystems.tv> wrote: > Hi Pierre, > > Is this any better? > > > 6.4 alt attribute > > The alt attribute is defined to allow an author to provide a text equivalent string for the image. This text equivalent is intended primarily to support users of the document who cannot see images, and may additionally support indexation of the content and also facilitate quality checking of the document during authoring. The text equivalent string is intended for use by screen readers or reproduction by braille devices etc. allowing the content and function of the image to be accessible to those with visual or certain cognitive disabilities. It should be noted that *in contrast to the common use of alt attributes within html content*, the imsc1:alt attribute content is not intended to be displayed in place of the image if the image file is not (able to be) loaded. > > If a smpte:backgroundImage attribute is applied to a div element, an imsc1:alt attribute should be applied to the div element and should contain a 'text equivalent' string value that is an appropriate functional replacement for the image source referenced by the smpte:backgroundImage. In the context of IMSC, where the images are usually representing subtitle or caption text, the guidelines for authoring text equivalent strings given in the html5 specification are appropriate: see section 4.7.1.1.5 Images of text of the draft document for HTML5 - A vocabulary and associated APIs for HTML and XHTML (W3C Last Call Working Draft 17 June 2014). : http://www.w3.org/TR/html5/. > > The 'text equivalent' string conveyed by the alt attribute should be written so that it conveys all essential content and fulfils the same function as the associated image. In the context of subtitling and captioning, this essential content will be the verbatim equivalent of the image without précis or summarisation. However the author should consider including extra information to the text equivalent string in cases where styling is applied to the text image with a deliberate connotation, as a *functional* replacement for the applied style. E.g. In subtitling and captioning, italics may be used to indicate an off screen context (for example a voice from a radio). An author may choose to include this functional information in the alt attribute text equivalent; for example, by including the word "Radio: " before the image equivalent text. It should also be noted that images intended for use as *captions*, i.e. intended for a hard of hearing audience, may already include this functional information in the rendered text. > > > > To maintain a close connection between an image and the associated text equivalent I still believe it is more appropriate to place the alt attribute within the div. It would be more ideal IMHO if the alt attribute was part of smpte:backgroundImage... but of course that is outside of our scope, so placing it in the div is IMHO the next best alternative. I believe we should basically follow the WCAG20 guidelines for "Text Alternatives": http://www.w3.org/TR/UNDERSTANDING-WCAG20/conformance.html#uc-text-alternatives-head > > "In order for people with disabilities to be able to use this text - the text must be "programmatically determinable." This means that the text must be able to be read and used by the assistive technologies (and the accessibility features in browsers) that people with disabilities use. > It must also be possible for people using assistive technologies to find these text alternatives when they encounter non-text content that they cannot use. To accomplish this, we say that the text must be "programmatically associated" with the non-text content. This means that the user must be able to use their assistive technology to find the alternative text (that they can use) when they land on the non-text content (that they can't use)." > > Although the above is written with the assumption of browsers as the processing agent I believe this guidance is still valid. For me, in our context, programmatically associated with the non-text content means placing it as close as is reasonable to the image content. I also believe placing the alt attribute under metadata would encourage the undesirable possibility that the metadata might be deliberately stripped upon transmission as it was 'deemed unnecessary' or to 'save bandwidth'. > > > > On a new point...Are there cardinality restrictions with regards to smpte:backgroundImage and div in IMSC? They are not apparent in the IMSC draft? Am I correct in assuming that a div can contain only a *single* smpte:backgroundImage? And that timing is therefore applied to the div element? If a div could contain multiple images it is even more difficult to see how correct "programmatic association" between images and metadata could be ensured. > > Best regards, > > John > > > On Thu, Jun 19, 2014 at 1:24 AM, John Birch <John.Birch@screensystems.tv> wrote: >> OK... >> >> I'm not sure about the *connection* between "the "alt" content needs to be in a metadata element" and "as it does not impact rendering". >> >> While I agree with the latter statement completely, I am not sure that this justifies classing it as metadata. It is not data about data, it is an 'alternative form' of the same thing. My preference is to align with HTML alt tag conventions. >> >> I understand your concerns with my prose, as it does leave the door open to implementers deciding to use the text to re-render... whilst it will be impossible to stop that, I can and will modify the prose to indicate reasons why that is not recommended... and I will also provide additional rationale for the inclusion of this attribute... >> >> 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-----Original >> Message----- >> From: Pierre-Anthony Lemieux [mailto:pal@sandflow.com] >> Sent: 19 June 2014 07:10 >> To: John Birch >> Cc: 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] >> >> Hi John, >> >> Couple of comments. >> >> - the "alt" content needs to be in a metadata element, as it does not >> impact rendering >> >> - I am not comfortable with the statement "text equivalents should be written so that they convey all essential content and fulfil the same function as the images" as it strays from the "It can be used in QC..." use case and appears to define a parallel means of delivering subtitle/caption text content which is already covered by the Text Profile in IMSC 1.0. >> >> Best, >> >> -- Pierre >> >> On Wed, Jun 18, 2014 at 3:16 AM, John Birch <John.Birch@screensystems.tv> wrote: >>> 6.4 alt attribute >>> >>> If a smpte:backgroundImage attribute is applied to a div element, an imsc1:alt attribute should be applied to the div element and should contain a 'text equivalent' string value that is an appropriate functional replacement for the image source referenced by the smpte:backgroundImage. >>> In the context of IMSC, where the images are usually representing subtitle text, the guidelines given for html5 are appropriate: see section 4.7.1.1.5 Images of text: http://www.w3.org/TR/html5/ of the draft document HTML5 - A vocabulary and associated APIs for HTML and XHTML (W3C Last Call Working Draft 17 June 2014). Text equivalents should be written so that they convey all essential content and fulfil the same function as the images. In cases where styling is applied to the text image with a deliberate connotation, the author should consider including extra information in the alt attribute text equivalent as a *functional* replacement for the applied style. E.g. In subtitling applications italics may be used to indicate an off screen context (for example a voice from a radio). This might be indicated in the alt text equivalent by including the word "Radio:" before the image equivalent text. It should also be noted that images intended for use as *captions* may already include this functional information in the rendered text. >>> >>> I have included a definition of imsc1:alt tag attribute... I assume this would be a necessary extension? >>> >>> imsc1:alt (attribute) >>> Type: xs:string >>> Cardinality: 0..1 >>> Description: Text equivalent for Presented Images for subtitle documents conforming to the Image Profile. >>> >>> Does that work for you? >>> >>> >>> 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-----Original >>> Message----- >>> From: Pierre-Anthony Lemieux [mailto:pal@sandflow.com] >>> Sent: 17 June 2014 17:59 >>> To: John Birch >>> Cc: 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] >>> >>> Hi John, >>> >>> Ok. Please propose specific text for an optional "imsc1:Alt" metadata element. >>> >>> Thanks, >>> >>> -- Pierre >>> >>> On Tue, Jun 17, 2014 at 9:54 AM, John Birch <John.Birch@screensystems.tv> wrote: >>>> This (an alt tag or attribute) is exactly what I am asking for. >>>> But I would like it to be part of the specification, and ideally a recommendation, rather than leaving it as something that somebody knowledgeable could infer might be possible... >>>> >>>> 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-----Original >>>> Message----- >>>> From: Pierre-Anthony Lemieux [mailto:pal@sandflow.com] >>>> Sent: 17 June 2014 17:50 >>>> To: John Birch >>>> Cc: 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] >>>> >>>>> For example... It can be used in QC... a font selection error could >>>>> result in images that are incorrect for the input text... but how would you know by examining just the images? >>>>> Again, it is trivial to include this information during the >>>>> creation of a primarily image based document track. >>>> >>>> As suggested by Mike, this could be served by "alt" metadata that would allow authors to optionally associate text with any IMSC content. >>>> >>>> Would this address your concern? >>>> >>>> Thanks, >>>> >>>> -- Pierre >>>> >>>> On Tue, Jun 17, 2014 at 9:44 AM, John Birch <John.Birch@screensystems.tv> wrote: >>>>> I'm not actually asking anybody to introduce another means... >>>>> >>>>> I'm simply stating an opinion that applications that wish to enhance the lives of people who might require accessibility solutions, (e.g. braille readers) might be considered more useful (and I imagine would be the preferred application) if they choose to implement a means to supply the alternate text to those devices. >>>>> >>>>> My *personal standpoint* is that *all* standards should promote and insist upon accessibility... and *for me* that doesn't mean making it optional or leaving it as somebody else's problem or decision. >>>>> Accessibility works best when it is a hard recommendation and clear benefits to all parties can be seen. The inclusion of alternative text for images has benefits to users of image based documents far beyond accessibility. For example... It can be used in QC... a font selection error could result in images that are incorrect for the input text... but how would you know by examining just the images? Again, it is trivial to include this information during the creation of a primarily image based document track. >>>>> >>>>> Further, applications cannot spontaneously 'create' an additional separate Text Profile document track... that would have to be created (by choice) by the content provider... and that's the disconnect for the user who needs the alternative representation. >>>>> >>>>> Insisting upon only supporting use cases where this content must exist as a separate track creates new issues of asset management, and (as has been raised by you or Mike?) raises the complexity for processors that seek to be more accessible by providing alternative text... why should an accessible processor implementation be so penalised? >>>>> >>>>> It also increases dramatically the likelihood that this information will not be provided by content providers... and therefore massively increases the likelihood that users who need text alternatives are disenfranchised. >>>>> >>>>> I very much struggle to see the foundation for the objections to including this alternative text information: >>>>> Insisting upon a rigid logical separation of content by categories into separate tracks has not been religiously applied (see forcedDisplayMode)... so what other basis is there? >>>>> Existing implementations might not support it? So what... I haven't ever asked for it to be mandatory... >>>>> >>>>> 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-----Original >>>>> Message----- >>>>> From: Pierre-Anthony Lemieux [mailto:pal@sandflow.com] >>>>> Sent: 17 June 2014 16:42 >>>>> To: John Birch >>>>> Cc: 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] >>>>> >>>>>> 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 >>>>>> >>>>> >>>>> 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 >>>> >>>> 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 >>> >>> 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 >> >> 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 > 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 > > 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 Monday, 23 June 2014 05:27:31 UTC