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

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.
>
>************************************************************************
>
>
>
>  
>