COMMENT: Flow Text

Hi all,

    These are concrete problems/suggestions on the flowText elements as
currently specified (or underspecified).

4.2 The flowRegion element

	"The children of a flowRegion element are inserted into the
	 rendering tree before the text is drawn and have the same
	 rendering behavior as if they were children of a g element."

    This is new and I don't think it's a particularly good idea. If
people want the flowRegions to be rendered then there is the 'use'
element.  Given the above how are filters handled?

	"A flowRegion element has basic shapes and path elements as
	children"

    I'm not a real Schema expert but it appears that it allows
just about anything as a child (g, use, text, shapes).  This is
without comment on how these are combined to form the flow regions.
Given that the desire here is almost identical to the clipPath element
(namely construct a set of geometry) I would strongly urge the WG
to adopt the wording and methods used in clipPath (which restricts
it's children pretty heavily).

    Given that the WG is likely not to take my advice ;)  You need to
at least specify what having a 'g' means.  Is all the geometry
concatenated as one flow region? Are implementors expected to 'union'
the fill regions of the children of the 'g'?  Use if it is allowed
to reference arbitrary content (which it isn't for clipPath) has
similar issues.

    Also with text is all the text considered a single very complex
flow region or is each individual letter a flow region?  What about 
letters with multiple 'disjoint' pieces ('i',';','%')?

    All these comments apply equally to the flowRegionExclude section.

4.5 The flowPara element

    It needs to be clearly defined if 'block' here means CSS block.
Also there are references to margin's elsewhere do they apply here?

    flowPara doesn't appear to allow flowLine as a child (in fact
no one seems to allow flow line as a child).

4.7 flowRegionBreak element

    It should be specified what the behavior is in the case that a
flowRegionBreak element is empty or there are multiple together (as
it is for flowLine).  Also flowSpan doesn't allow flowRegionBreak
element's as children, but flowLine and flowDiv do, is this
intentional?

    Is flowRegionBreak more a flowPara or a flowSpan or something
else (just a 'marker'?).

4.13 Determining Strip Location

    How is line-height determined?

    What is the strip that is intersected with the geometry?

    If it is the line-height it is worth noting that this may be
smaller than the content height meaning that text content may
run into the flow geometry.  If the content height (or line box)
is used then this doubles the number of intersections needed to
handle strip calculations (there are also other inefficiencies this
introduces).

4.14.2 The progression-align property

     Doesn't it make a _lot_ more sense to have this property
apply to the flow regions?  What does it mean to have a center
aligned flowPara bracketed by two un-aligned flowPara elements?

     Also I think a description of how this is applied to content
is in order.  I can think of several "reasonable" interpretations
which given 'odd' flow geometry could result in widely variable
results.

4.14.3 Overflow

     What is the processing model for this?
     Is this event generated before/after DOM mutation events?
     _Must_ it be issued for every mutation event that changes
the state or may an implementation 'compress' overflow events
as long as no rendering occurs between them?

     I would really like to lobby for allowing compression, otherwise
the layout must be performed on essentially _every_ modification of
the content tree.  I think UA's should be allowed to defer layout
until just prior to rendering at which point if a flow has change
overflow state events must be issued (which may change the flow and
hence the overflow state, which may lead to new overflow events before
the rendering takes place, repeat as needed).

     This avoids the need to layout the text 12 times because 12
properties were changed in the flowText tree (even when none of
the 12 actually causes an overflow event).

     For async renderers (that don't normally hold up rendering until
'script' completes) they would only be required to dispatch the event
before 'unsuspendRedraw/All' and 'forceRedraw' complete.

4.15 Example

     Aside from the already noted 'well formedness' problem ("</flow>"
instead of "</flowRoot>").  The namespace declaration is wrong
(you want "xmlns=" not "xmlns:svg=").  Also in the first example
the flowRegion appears to be a parallelogram instead of the
desired trapezoid (I think the last L should be L200,50 - although
even that goes 'outside' the stroked trapezoid on the bottom).
You might be better off using margins here and referencing the
stroked trapezoid.

Other Properties:

     There should really be a consideration of other properties
implementations need to be mindful of from CSS.  A few that
come to mind: 'margin', 'margin-*', 'text-indent'?, 'white-space'?,
'line-height'.  Without this it is unclear what an implementation
is expected to support.

Received on Monday, 8 November 2004 15:46:47 UTC