RE: Balanced lines

[my comments at the end]

At 04:50 AM 2003-08-14, Johnb@screen.subtitling.com wrote:
>Glenn
>[GA>]  and I would not expect any AF to DF (distribution format) 
>transcoder to implement such a feature simply on the basis of cost to 
>benefit ratio.
>
>[JB>]
>Yet the present set of CSS properties [JB> ] effectively  preclude the use 
>of 'river control' even if an AF to DF transcoder implements it as a 
>matter of customer requirement. I notice that the line-break property in 
>CSS3 Candidate Release is commented as follows:
>
>"This property selects the set of line breaking rules to be used for text. 
>The values described below are especially useful to CJK authors, but the 
>property itself is open to other, not yet specified settings for non-CJK 
>authors as well. (This is an area for future expansion.)"
>
>bold is my emphasis.
>
>I wonder if there isn't a window of opportunity to suggest that a 'auto' 
>value be included for this property - such that the UA can make it's own 
>choice of line-break strategy? The 'normal' value has no specified 
>behaviour for non CJK text - but I personally feel that a UA which 
>implemented river-control for non CJK text for line-break="normal" would 
>be contrary to most users expectations.
>
>regards
>John Birch
>
>The views and opinions expressed are the author's own and do not necessarily
>reflect the views and opinions of Screen Subtitling Systems Limited.

Timed Text clearly has an interest in realizing a 'river-control' or
"maximize mean time to read per word while minimizing dispersion in time to
read per word" policy for allocating text to lines under a synchronization
constraint.  This interest is a quantum leap beyond anything CSS has dealt
with before.

CSS would like experts in novel delivery contexts to define properties or
pseudo-properties like these appropriate to their delivery context and bring
them to CSS for integration and publication.

I see no reason why if one TT-AF transcoder implements such a function it
won't be a required cost of entry to the competitive range soon thereafter.
It's not a big deal to do it.  This is a relatively small and
straightforward optimization problem.  The cost comes in the other,
diction-sensitive rules, that enter in to the autoflow processing.

The reason a small TT presentation window is radically different from anything
CSS has dealt with before is because time, not screen real estate, is the
scarcest resource in this delivery context.  So it is more important to
river-control the line length for usability of the resultant presentation than
for the author to hand-control the allocation of layout-rectangle sizes and
packing.

In classical web page design the main cost pressure is all the other stuff
you can't put in view when you commit a rectangle of layout.  In captions
and subtitles, the main cost pressure is that there is not enought time for
the user to catch the text while it is available.  If there is insufficient
time, the user either misses what the caption/subtitle said entirely, or
they have to concentrate so hard to follow the text presentation that they
can't enjoy the video that is around it.  It is more important for the text
display transactions to fill the time available than for the lines to fill
the rectangle available.

Even if I exaggerate and the penalty for mis-utilization of available time
is not the long pole in the tent, but only the same order of magnitude as
the penalty for mis-utilization of layout rectangle area, it is a 'phase
change,' a qualitative mode shift from the performance pressures under which
other CSS renderings operate.

Al

Received on Thursday, 14 August 2003 09:32:11 UTC