RE: Coments - last call draft [re: timing attributes]

At 02:15 PM 3/31/2005 +0100, Johnb@screen.subtitling.com wrote:

>Charles,
>
>you wrote[31 March 2005 02:46]:
>
>[[[
>If not specified, the default length unit must be considered to be pixels.
>]]]
>
>For accessibility reasons, it seems better in a pure text format to use an
>element based on font size, such as the em unit, as a default. I realise
>this implies a small change in the practice of authors, who are probably
>generally accustomed to working in pixels. But then they are probably not
>generally accustomed to working on accessibility.
>
>In general I support your view - but I would prefer that scalar values 
>were ONLY relative rather than absolute - such that all expressions of 
>dimension were always in terms of proportions of either the target canvas, 
>or of a selected font. The use of absolute scalar values creates files 
>that are tightly bound to a specific target display (which is hardly 
>fitting for an interchange mechanism). Moving to an em unit as a default 
>could be problematic, as sizing then becomes dependent on the font not the 
>canvas (thus when canvas size is fixed - overflow/clipping may occur).
>
>frameRateMultiplier (et al)
>
>Actually it seems strange that so much of this is in the spec. I
>understand that it enables synchronisation with traditional television,
>but it seems a lot of complexity.
>
>Again I agree. I cannot see any benefit in having this complex a mechanism 
>(and I am looking at implementations that **wil**l require synchronisation 
>with traditional television!).
>
>IMO There are two timing models that might apply to TT, I'll call them, 
>intrinsic and extrinsic. In the intrinstic model, timing is self-timed and 
>internal (this only requires a single specified timebase e.g. 
>milliseconds). In the extrinsic model, timing is slaved to an external 
>timebase. The extrinsic model may require a definition of the external 
>time source e.g. clock or smpte. However, the extrinsic model does **not 
>require** a definition for the external time source representation, since 
>it can be safely assumed (and specified) that a document using extrinsic 
>time synchronisation will contain time values in the same format as the 
>external source, and **all** that is required is a match algorithm.... 
>I.e. 10:00:01:23 matches 10:00:01:23 regardless of whether these are 30DF 
>30NDF 25PAL etc. The requirement for most of these timebase attributes 
>only arises by allowing 'dur' as an attribute, since this necessitates the 
>calculation of effective end values, which in term requires an 
>understanding of framecounting in different timebases.
>
>It would be helpful if the spec said what happens when the begin/end and
>the dur attributes don't agree.

SMIL 2.0 has a necessarily-complicated algorithm for resolving
begin and end times when multiple timing attributes are in
effect:

   http://www.w3.org/TR/SMIL/smil-timing.html#q80

Luckily, TT does not have begin-time and end-time lists nor
some of the other timing attributes of SMIL 2, so the algorithm
is much less complex.  I agree it should be stated in the draft.
The basic rule in SMIL for resolving the duration when dur and
end are both expressed as resolved values is to take the minimum
of (end-begin) and (dur).


>Or if it said that you can use begin + dur, and begin + end, but not begin 
>+ end + dur!
>
>IMO - drop dur as an attribute - it can be equivalently expressed using 
>begin and end - and the above issues can then be simplified.

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

         - Erik


>Quite a lot of work went into CSS. It is also considered pretty normal to
>style XML with CSS.
>
>For accessibility purposes it is helpful to have something like the CSS2
>Cascade rules (which represented a change from CSS1 for enhanced
>accessibility). It turns out that text is about the only area where it is
>easy for user styles to make sense, so it seems a shame that there is no
>mechanism anticipated by the spec for using CSS and takng advantage of the
>cascading of rules that are important to the user, where appropriate.
>
>No argument here! - but DFXP uses the XSL-FO model as a foundation not CSS.
>
>regards
>
>John Birch
>Senior Software Engineer,
>Screen Subtitling Systems Limited,
>The Old Rectory, Claydon Church Lane,
>Claydon, Ipswich, Suffolk.
>IP6 OEQ
>
>Tel: +44 1473 831700
>Fax:+44 1473 830078
>www.screen.subtitling.com
>
>See us at NAB Las Vegas April 18-21st Stand No. SU8956
>
>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.