RE: ISSUE-98 (Clear timing.): Eliminate separate clear timing from dynamicFlow [DFXP 1.0]

Well clearly we have a different interpretation of independent, I'm talking about the behavior
So for example let's say the fill interval is 10, and the clear interval is 15.

If the clocks and their behavior are independent, I would expect to have events as follows:

10:Fill, 15:Clear, 20:Fill, 30{Fill,Clear},....

However my reading of the current language is the fill resets the clear timer and vice-versa, e.g.:

If the presentation region is non-empty and if the clear timer is not active, then reset the clear timer to the current value of the computed clear interval.

I read this as saying that the next time the clear operation will run, is (if not already determined) clear-interval after the current time.

So,

10:Fill (Clear is made active), 20:Fill(Clear is active),  35:{Clear,Fill},  45:Fill(Clear is active), 50:Clear

I don't see this behavior as independent. Regardless of whether the clocks are independent. And it means that the flow is jerky.

What I think in fact was meant by an intra interval was something more like:

for a fill interval is 10, and the clear interval  of 5 (less than fill interval)

10:Fill, 15:Clear, 20:Fill, 25:Clear, 30Fill,...

I don't think the case where the clear interval is >= the fill interval has been adequately elaborated anywhere, and the term intra implies that it occurs between two fills. so I might suggest this is in fact an error condition. It may be this is what the current WD intended to capture, but I don't believe it currently does.


As for line breaking, I read XSL1.1:

The partitioning occurs at legal line-breaks. Specifically, if A is the last area of Si and B is the first area of Si+1, then the rules of the language, script and hyphenation constraints (7.10 Common Hyphenation Properties<http://www.w3.org/TR/2006/REC-xsl11-20061205/#common-hyphenation-properties>, 7.16.1 hyphenation-keep<http://www.w3.org/TR/2006/REC-xsl11-20061205/#hyphenation-keep>, and 7.16.2 hyphenation-ladder-count<http://www.w3.org/TR/2006/REC-xsl11-20061205/#hyphenation-ladder-count>) in effect must permit a line-break between A and B, within the context of all areas in Si and Si+1.

The "rules of the language" are indeed not defined by XSL, but they are not arbitrary. I cannot now find on the public list the discussion I recall (and perhaps I'm mis-remembering) that we would not require hyphenation; and thus we would use line breaking based on the basic algorithm alluded to in  UAX14 [1] section 3,  however even if we allow hyphenation,  for English it is not common practice to allow a break anywhere in a word, but typically only after a syllable and with some regard to readability of the fragments. I'm sure I don't need to elaborate for you how different languages require different things in this regard.

I did say we could fix this by taking control of the line-breaking strategy, which is a new feature we would need to add. If we put this feature in however, I would strongly object if a longest-line, break-at-whitespace ,no hyphenation algorithm,  were to be disallowed as one of the strategies. I think I will raise a separate issue on linebreaking.

Nevertheless for this discussion, unspecified is just as bad, if authors can't rely on a hard snake mode then they won't be able to use it, and I think it unlikely, unless we specify it, that a fixed character break will be the norm for processors.

The fact that I could write code for this over the weekend was strongly influenced by the fact that I have been studying this section in some detail for a month or so, and I may still not have got it right; so I stand by my claim that it is complex. However I wouldn't seek to dismiss it just because it is complex, other parts of the spec are complex too, my problem is more that all these degrees of freedom don't appear to be that useful in practice.

[1] http://www.unicode.org/unicode/reports/tr14/tr14-17.html

Sean Hayes
Media Accessibility Strategist
Accessibility Business Unit
Microsoft

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

From: Glenn A. Adams [mailto:gadams@xfsi.com]
Sent: 19 May 2009 4:46 AM
To: Sean Hayes; Public TTWG List
Subject: Re: ISSUE-98 (Clear timing.): Eliminate separate clear timing from dynamicFlow [DFXP 1.0]


just a few preliminary remarks (inline); i will send longer response presently;

On 5/19/09 2:33 AM, "Sean Hayes" <Sean.Hayes@microsoft.com> wrote:
The first thing I have discovered is that there are indeed issues in the timing behavior described by the current WD.
[GA] agreed, and i think you are heading in the correct direction on resolving the clear timer semantics,  however i have some slightly different conclusions which I will elaborate in a forthcoming, longer response;
The next problem is that the two timers are not independent, and we have the clear operation effectively performing a fill and resetting the fill timer, therefore the rate of flow through the region  doesn't stay  constant throughout. What I think was intended seems to have been a queue process which is trying to feed content in at one end, and take it out of the other, maintaining as much as possible a full pipeline and constant speed.

[GA] but they [the two timers] are indeed independent, and are governed by different periodicity rules; having the trigger action off one timer reset or trigger the other upon various conditions does not make them dependent, it just makes the semantics of their trigger actions inter-dependent;

Now we have cleanly separated the two timers. If we adopt this fix (which I think we need to otherwise the model is pretty unusable), it probably makes sense to define that the clear interval is always the same as the fill interval, and that both are controlled by the inter parameter.

[GA] i believe they are already "cleanly separated"; they have independent timer states and different trigger actions; john's examples already show scenarios for having different periodicities, so they should not be required to be the same;

I still think it would be better to combine the fill and clear operations into a singled timed operation which would simplify the exposition considerably, Also there seems to be nothing in the current draft which actually corresponds to the original meaning of the inter-fill timing; which was a pause between determining a clear is required and actually performing the clear.
[GA] but that is precisely the intended definition of the currently specified clear timer; if it was specified badly and doesn't achieve this result, then we need to fix it;

Having possibly dealt with the timing issue and played around with the various modes, I'm now concerned we are going to a lot of trouble to specify a complex processing model, despite the fact that only a few combinations of in and out unit actually make practical sense.

[GA] i don't view it as a "complex processing model" at all; the fact that you could implement a simulator over the weekend would seem to argue that it is simple, not complex; the reason for the model is to be precise about semantics and the intended result; all too often in specifications these details are left at the mercy of the implementer, and different implementations end up with very different behaviors, or one implementation begins to serve as a de-facto golden standard; i want to avoid that here by being as precise as possible: meaning that behavior is standardized, reproducible, and testable; i agree that it makes the specification process more complex, nevertheless, both implementers and authors benefit from more precisely defined behavior;

The main problem is that XSL:FO line breaking rules don't admit a break at an arbitrary point; (and I believe we at one point decided not to require complex hyphenation processing although I haven't traced that decision down yet). Whereas I believe John was basing his design on a teletext like model which places individual characters, and breaks words at arbitrary points.

[GA] this is not true; XSL-FO does not specify line breaking rules, therefore it is completely arbitrary, or at least non-standardized; DFXP 9.4 and XSL 1.1 4.7.2 (3) apply. Notice the definitions of the script and language properties of XSL 1.1, where you will find the following:
Specifies the {language,script} to be used by the formatter in language-/locale-coupled services, such as line-justification strategy, line-breaking, and hyphenation.

Note:

This may affect line composition in a system-dependent way.

Thus in timed text when applying wrapping, line breaks basically occur at whitespace boundaries, as in HTML.
[GA] at present, what constitutes a legal line break in DFXP remains non-standardized (as in XSL), so it is arbitrary; therefore, there is no problem implementing snake mode at the character or glyph level of flow units;