Re: DFXP LC Comments - Issues 3, 4, 8 Responses; John Birch

Thierry,

Apologies for creating any confusion.... Yes I approve all the TTWG
responses.

thanks

John Birch.


----- Original Message -----
From: "Thierry MICHEL" <tmichel@w3.org>
To: "John Birch" <Johnb@screen.subtitling.com>
Cc: <public-tt@w3.org>
Sent: Wednesday, August 17, 2005 1:48 PM
Subject: Re: DFXP LC Comments - Issues 3, 4, 8 Responses; John Birch



John,

Just for clarification;

Do you approuve TTWG responses to your comments 3, 4 and 8 ?
http://www.w3.org/2005/03/21/DFXPLastCallResponses.html
(as you mentionned comments 3 and 5 in your previous mail).
Thanks

Thierry.



John Birch a écrit :

> Thierry, WG et al,
>
> I am happy with the comments made by the working group and am
> satisfied by the response.
>
> I make the following observations.
>
> Comment #3.
>
> The suggested resolution to comment 1 results in a DFXP file that must
> be totally explicit in defining the appearence of the text. The user
> agent is not involved in any computation to determine the extent of
> background. The active line/stripe will require a separate region to
> be defined for each text line, and for text content to be assigned to
> a line. This will preclude taking advantage of any line breaking
> mechanism in the UA.
>
> I do not see this functionality as I see it a new requirement... since
> all the modes outlined are in use by current subtitling systems (an
> identified target application of DFXP)... I see this requirement as
> derived. It seems that implementing a trivial means of including these
> effects in DFXP is viewed as 'stretching' the original requirements :-).
>
> The difference between stripe and box mode is as follows. In stripe
> mode the background extends to the horizontal limits of the display
> surface. However, text is aligned to right and left margins that would
> be in identical position to those that might be used for non-stripe
> modes. I cannot see how stripe effect might be easily since the text
> must be assigned to a region that bounds at the margins, whereas the
> background has a larger (at least horizontally) extent. The stripe
> background could be produced as the result of a separate 'wider'
> region, but would need to be activated - presumably by including
> whitespace? (it is unclear whether an empty region [but with a
> background] should display?)
>
> Comment #5.
>
> I await the new section 10.4 with interest.
>
> Finally - you may be interested in a demo taking place at IBC this
> year - where DFXP is to be used as an interchange format within MXF
> media files. This demo is taking place throughout the exhibition on
> the EBU stand.
>
> with best regards
>
> John Birch
> Senior Software Engineer,
> Screen Subtitling Systems
> The Old Rectory, Church Lane
> Claydon, Ipswich, Suffolk
> IP6 OEQ
>
> Tel: +44 1473 831700
> Fax: +44 1473 830078
> www.screen.subtitling.com
>
> See us at IBC Amsterdam  9th-13th September Stand No. 1.441
>
> This message is intended only for the use of the person(s) ("the
> Intended Recipient") to whom it is addressed. It may contain
> information which is privileged and confidential within the meaning of
> the applicable law. Accordingly any dissemination, distribution,
> copying or other use of this message or any of its content by any
> person other than the Intended Recipient may constitute a breach of
> civil or criminal law and is strictly prohibited. If you are not the
> Intended Recipient please destroy this email and contact the sender as
> soon as possible.
>
> In messages of non-business nature, the views and opinions expressed
> are the author's own and do not necessarily reflect the views and
> opinions of the Screen Subtitling Systems Limited.
>
> Whilst all efforts are made to safeguard Inbound and Outbound emails,
> we cannot guarantee that attachments are Virus-free or compatible with
> your systems and do not accept any liability in respect of viruses or
> computer problems experienced.
>
>
> -----Original Message-----
> From: public-tt-request@w3.org [mailto:public-tt-request@w3.org]On
> Behalf Of Thierry MICHEL
> Sent: 12 August 2005 23:32
> To: Glenn A. Adams
> Cc: John Birch; W3C Public TTWG
> Subject: Re: DFXP LC Comments - Issues 3, 4, 8 Responses; John Birch
>
>
>
> Dear John,
> If you require any further follow-up please do so, and if you are
> satisfied with the TTWG response, please acknowledge it by replying to
> this mail and copying the TTWG public mailing list:
> public-tt@w3.org
> Regards,
> Thierry Michel
>
> Glenn A. Adams a écrit :
>
> >Dear John,
> >
> >Thank you for your comments, [1] through [3], on the DFXP Last Call
> Working Draft. The TT WG has concluded its review of your comments and
> has agreed upon the following responses.
>
> >
> >If you require any further follow-up, then please do so no later than
> September 1, and please forward your follow-up to <public-tt@w3.org>.
>
> >
> >Regards,
> >Glenn Adams
> >Chair, Timed Text Working Group
> >
> >************************************************************************
> >
> >Citations:
> >
> >[1] http://lists.w3.org/Archives/Public/public-tt/2005Mar/0004.html
> >[2] http://lists.w3.org/Archives/Public/public-tt/2005Apr/0015.html
> >[3] http://lists.w3.org/Archives/Public/public-tt/2005Apr/0012.html
> >
> >************************************************************************
> >
> >Comment - Issue #3 [1]; 16 Mar 2005 17:50:49 +0100
> >
> >I have some problems with the current support for background colour in
> >DXFP.  The attached files indicate three common modes of using
> >background colours.
> >
> >Given the current attributes tts:displayAlign and tts:showBackground I
> >cannot see a way to trivially implement these effects in DXFP without
> >creating a large number of regions.
> >
> >Can consideration be given to enhancing the tts:showBackground
> >attribute to support the following attribute values?
> >
> >content - The background attributes are only applied to the part of
> >the region that has content. I.e. there is only a background behind
> >characters of displayed text but not behind white-space characters
> >(e.g. line 21 boxed captions with transparent space).
> >
> >content-space - The background attributes are only applied to the part
> >of the region that has content and also to white-space within the
> >content. I.e.  there is background behind characters of displayed text
> >and behind white-space characters. If no white-space character exists
> >at the end of each line, the background is extended to cover the area
> >of a single space character at the end of each line. (UK boxed style)
> >
> >active-line - The background attributes are applied to the lines of
> >the region that have content. The background extends the full width of
> >the **region** for any line that has content within the region.
> >
> >active-stripe - The background attributes are applied to the lines of
> >the region that have content. The background extends the full width of
> >the display.
> >
> >active-bounds - The background attributes are applied to the bounding
> >box of all content within the region, providing the region has some
> >content.
> >
> >active-region - The background attributes are applied to the entire
> >region providing the region has some content.
> >
> >stripe - The background attributes are applied to the entire region
> >regardless of if the region has some content.. The background extends
> >the full display width.
> >
> >region - The background attributes are applied to the entire region
> >regardless of if the region has some content. (E.g. this might be used
> >for censorship).
> >
> >Response:
> >
> >A combination of use of explicit <span>s around whitespace as
> >well as the use of non-standard style property attributes in a non-TT
> >namespace are sufficient to satisfy this proposal.
> >
> >Further consideration may be given to developing these concepts as a
> >TT Style Extension property, possibly defined in an additional REC
> >track document or a Working Group Note.
> >
> >Note that the functionality described in the comment is probably a new
> >requirement.
> >
> >Note also that some of the proposed uses appear to be covered by
> >existing DFXP mechanisms, e.g., the examples in Doctor_Box_Mode.doc
> >appear to be supportable by means of using <span
> >tts:backgroundColor="black"/> with a transparent background on region,
> >body, div, and p.
> >
> >We also note that Doctor_Strip_Mode.doc appears to be identical to
> >Doctor_Box_Mode.doc (we don't see any difference).
> >
> >************************************************************************
> >
> >Comment - Issue #4 [2]; 4 Apr 2005 12:34:54 +0100
> >
> >OK, I'll try and frame what I see as the style problem....
> >
> >The DFXP style model is quite suitable for the carriage of styled
> >text, BUT, in the contexts of accessibilty and transcoding, the DFXP
> >style mechanism IMO lacks an essential ingredient, that being the
> >reason for (or context of) the applied style.
> >
> >As an example - an author may choose yellow text on a red background
> >for a warning message.
> >
> >The carriage of that text as simply text characters and colour codes
> >loses one piece of information - the fact that it was intended as a
> >warning.
> >
> >This missing information becomes important when interchanging content
> >between formats that have different support for style (for example
> >between a colour and monochromatic presentation), or in transcoding /
> >translating content between cultural groups.
> >
> >Another example - Green is 'lucky' in Ireland, but Red is 'lucky' in
> >China.  Go n'éirí an t-ádh leat could translate to ??? (Note: Internet
> >machine translation!).  You have stated that it is possible (likely)
> >that this style tagging (context) will be a feature of AFXP and that
> >DFXP is a format intended as "a solution that addressed the more
> >pressing and less complex need of interchange among a small number of
> >legacy distribbution formats,specifically SAMI, QuickText, RealText,
> >3GPP TT, CEA-608/708, and WST."
> >
> >It should be noted that CEA-608/708, and WST (and in fact TV
> >subtitling formats in general) are typically not stored in these wire
> >formats by broadcasters, rather these wire distribution formats are
> >created in real-time by insertion equipment working from proprietary
> >file formats. A single common file format already exists as a ratified
> >interchange standard, EBU 3264. DFXP could replace the use of EBU 3264
> >- it offers a few of advantages, a) it is Unicode, b) it is XML and c)
> >it has a more comprehensive language tagging mechanism. However, DFXP
> >does not offer any significant new features over EBU 3264, and indeed
> >there are features in EBU3264 that are not present in DFXP (e.g.
> >cumulative mode and boxing).  A combination of extension elements and
> >attributes and constrained document structuring (via a sub-profile)
> >can probably be used with DFXP to fully represent EBU 3264 document
> >contents - and other general TV broadcast related subtitling issues.
> >Indeed, it is anticipated that the use of DFXP as an interchange
> >mechanism for TV broadcast subtitling will require the development of
> >guidelines for the interpretation of DFXP documents by transcoders. In
> >addition it will probably require the development of a profile to add
> >elements and attributes to DFXP to carry information and features
> >currently supported by existing formats, (e.g. conditional content,
> >cumulative modes, background styles, embedded glyphs, subtitles as
> >images (DVD, DVB, Imitext)).
> >
> >The pressing need is not IMO for another interchange format per se,
> >rather it is for a format that preserves more of the authorial intent
> >(inc.  understanding / meaning) such that implementing transcoding,
> >translation and accessibility are made easier tasks than they are
> >currently. My main concerns are that using DFXP will encourage the
> >continuation of the existing practice of 'cooked text content' - that
> >is text that has lost contextual meaning - and that AFXP will be too
> >complex and too late for most implementations.
> >
> >Is there a middle path for DFXP that would encourage a more context
> >sensitive (and accessible) role for text style? DFXP already includes
> >a referenced style mechanism - could that mechanism be strengthened to
> >provide greater support for contextual styling of text?
> >
> >Response:
> >
> >An author may use a combination of ttm:role, ttm:agent, as well as
> >user-defined metadata attributes or elements, e.g., placing them in a
> >child of the content, in order to express "the reason for (or context
> >of) the applied style."
> >
> >For example, see example in
> >http://lists.w3.org/Archives/Public/public-tt/2005Apr/0021.html.
> >
> >************************************************************************
> >
> >Comment - Issue #8 [3]; 3 Apr 2005 11:36:56 +0100
> >
> >If we allow for extrinsic timing where such a time may not
> >be resolved yet, then there are use cases where it is
> >necessary to express both dur and end.  For instance:
> >"Display this text for 20 seconds unless the extrinsic-
> >event-based end time resolves before that time, in which
> >case end when it resolves".
> >
> >Is this mix of extrinsic and intrinsic timing actually supported
> >within DFXP. I thought that the discontinuous attribute applied to the
> >entire document (I see discontinuous as synonymous with media marker
> >modality)?
> >
> >Further, I find it a strange balance of features in that DFXP allows
> >such a sophisticated timing model when it only supports a relatively
> >simplistic styling model.
> >
> >Note: I do not have any real issue with the inclusion of the ttp
> >parameters for timing model, except that they increase the complexity
> >of a **fully conformant** (non SMIL based) user agent fairly
> >dramatically. I am currently assuming that since DFXP deliberately
> >avoids talking about UAs, that an implementation must clarify what
> >aspects of DFXP timing model it supports. I feel this puts DFXP in an
> >awkward position as a universal distribution format - since
> >originators of content may use features of the timing model that are
> >not supported by transcoders or UAs. So my position is that a simpler
> >timimng model would be more likely to be universally adopted, further
> >sophistication of the type in your example could IMO be handled by any
> >'container' format e.g. SMIL, and is unneccesary within a 'media
> >track' format (which is how I view DFXP).
> >
> >Response:
> >
> >The TT WG is considering the possibility of rewriting 10.4 to directly
> >specify semantics of time interval computation, which would include
> >definitions of use of begin, dur, and end, including semantics for
> >usage in the context of discontinuous marker mode with smpte time
> >base. We expect to permit dur attribute to be expressed as a nominal
> >media time while interpreting begin and end as marker (event) based
> >times.
> >
> >************************************************************************
> >
> >
> >
> >
> >
>

Received on Wednesday, 17 August 2005 20:30:50 UTC