dynamic flow issues.

This email is a general discussion of some issues I still have with the dynamic flow feature of the specification. I have this weekend been doing some trawling back over the mailing list archives to attempt to discover the original requirements for this feature, and its historical development; although the record seems somewhat incomplete.

I will file separate issues in the tracking system, but I think it is worth rounding them up into a single discussion here first. I believe what we have in the spec fails to meet the original goals in a number of respects.

Issue: Clear timing.
I can see no justification for having separate clear timing in any of the examples from John Birch's original documents (the only hard evidence I can find in the history trail of a design discussion). The notion of a separate clear timer seems to have been added between the March 14 draft and March 21 draft without discussion on the public list. What is more, the presence of a separate clear interval seems at somewhat at odds with the behavioral requirement.

If I have a two line caption region , and I wish to flow the text through it, with text entering at a word rate and leaving at a line rate. Then I don't want a clear to occur until after two lines have been added, but then I want to clear the lines after each additional line is completed; which implies clear timing can't start until the region starts to overflow, so the first clear interval needs to be extended, and after that we want the clear interval to be synchronized with the fill interval which is based on irregular length words, so a single value seems inappropriate.

In the example flow below: The first clear/reflow occurs at t14, the next at t20, then at t27 and at t33  (clear intervals of 14, 6, 7 6), then we presumably want to clear the remaining two lines to be cleared in some manner.

T01 Alice

t02 Alice was

....

t06 Alice was beginning to get very

t07 Alice was beginning to get very
       tired

....

t13 Alice was beginning to get very
       tired of sitting by her sister on

t14 tired of sitting by her sister on
       the
...
T19 tired of sitting by her sister on
        the bank and of having nothing

T20 the bank and of having nothing
        to
....

T26 the bank and of having nothing
        to do: once or twice she had

T27 to do: once or twice she had
        peeped

T33 peeped into the book her sister
        was

T34 peeped into the book her sister
        was reading

==========================================

The current semantics are not actually very clear as to what happens when fill operations are blocked (there is no explicit part to B.5.1 which matches the condition:  "the fill buffer is non-empty and contains sufficient content to compose a fill unit but insufficient space is present to accommodate it".  Presumably step 1 is skipped, and the timer is reset in step 2, so the fill remains pending, which implies that under some conditions, some content may never get flowed into the region. Again this seems to be due to the presence of an independent clear cycle.

 I suggest that if the clear is initiated only by the fill/overflow condition, then these issues could be avoided by the algorithm:

Fill timer expires ->
      While there is insufficient room to fit one fill unit into region
                Use clear operation to remove one clear unit
      Use reflow operation to adjust spacing if necessary
      Use fill operation to flow one fill unit into region

Which also helps with the condition when the clear unit is smaller than the fill unit.

==========================================

Fill units. Johns original requirement for block seems to have been be a 'region-full' at a time, rather than a timed text or an XSL:FO block. There is no current fill unit that corresponds to Johns idea of filling up the region (or clearing) as much as possible at each fill interval. I propose we remove the "block" fill unit, and replace it with something to indicate using as much as possible of the flow buffer to fill the content area of the region without overflow. If not, we need to clarify what is actually meant by a block level fill unit (<p>, <div> <body>?), especially if the content can contain nested blocks, and what happens if the block is actually too big for the region.

Similarly "inline" (fragment in Johns terms) is not well defined now either, since we have adopted nested inlines.

==========================================

Proposed 'rollup' shorthand. The 'inter' value of 0.433s needs some justification.

Also I propose that 'inter' and 'intra' are unnecessarily obtuse labels for the flowInterval. I propose we replace by, a) 'interval' if we adopt a single interval as suggested above, or b) 'fill' and 'clear' if the semantics of a separate clear timing can be resolved.

Change the specification of the flowfunction values to limit it to one or two functions, and a single flowIntervalFuntion

Values: none | rollUp | <flowFunction> (<flowFunction>)? <flowIntervalFunction>

<flowIntervalFunction> : ( "fill(" flowIntervalArguments ")" )?   ( "clear(" flowIntervalArguments ")" )?

==========================================

The inline level clear units won't work very satisfactorily with wrapOption='noWrap'. I suggest this combination be prohibited.

==========================================

Some changes to wording for clarification of flow buffer:

B.2 compute the difference between the content produced:

"in the procedure described above, the content of a flow buffer at time Tk is considered to be significantly different from the content of the same flow buffer at time Tk+1 if the set of glyph areas that would be produced by performing synchronic flow processing on intermediate  synchronic document at time Tk differs from the set of glyph areas that would be produced by performing synchronic flow processing on intermediate  synchronic document at time Tk+1 in any of the following ways:"

"then instantaneously replace" -> "replace at time T(k+1)"

B.3.1
"if the value of the fill interval is auto, then the computed fill interval from time T(k) up to but not including T(k+1) is equal to the difference between the time coordinate associated with the most temporally prior beginning point of an active duration of some content unit present in the flow buffer at time T(k+1) and the most temporally subsequent ending point of an active duration of some content unit present in the flow buffer at time T(k+1) divided by the number of fill units currently available in the flow buffer at time T(k+1)."

B.3.1 and B.3.2 (assuming clear interval is retained)
"if the value of the clear interval is auto, then the computed clear interval from time T(k) up to but not including T(k+1) is equal to the difference between the time coordinate associated with the most temporally prior beginning point of an active duration of some content unit present in the presentation region at time T(k)and the most temporally subsequent ending point of an active duration of some content unit present in the presentation region at time T(k) divided by the number of clear units currently available in the presentation region at time T(k)."



Sean Hayes
Media Accessibility Strategist
Accessibility Business Unit
Microsoft

Office:  +44 118 909 5867,
Mobile: +44 7875 091385