----- Forwarded message from Jon Ferraiolo <jon.ferraiolo@...720...> ----- Date: Fri, 18 Feb 2005 09:51:22 -0800 From: Jon Ferraiolo <jon.ferraiolo@...720...> Reply-To: Jon Ferraiolo <jon.ferraiolo@...720...> Subject: Re: COMMENT: Flow Text To: Thomas DeWeese <Thomas.DeWeese@...721...>, www-svg@...157...

Thomas,

Thanks for the great comments!

The SVG Working Group has given me the assignment of responding to one of our comments below. You said:

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.

The SVG WG believes the SVG 1.2 LC specification incorrectly defined a 'progression-align' property when instead it is better to reuse the 'display-align' property from XSL-FO (defined within http://www.w3.org/TR/xsl/slice7.html#area-alignment) , which delivers exactly what is needed. The next public draft of SVG will include the 'display-align' property instead.

We agree that the 'display-align' property should apply to regions and not to flow content elements. The next public draft of SVG will say that 'display-align' applies to the text container object and not to elements that are part of the text flow such as <flowPara>.

In terms of the last paragraph about odd flow geometries and widely variable results, I believe this issue only applies to non-rectangular regions. At the moment, the SVG WG is first addressing SVG Tiny 1.2 requirements (which only supports rectangular text regions) and is adopting the general policy proposed by others that flowing text layout must allow UA-specific layout algorithms to be deployed so that UA's are not prevented from delivering the best possible results. Although we haven't resolved your last paragraph completely yet, there is a possibility that we will allow layout variability in the general case (per the feedback of others), which might lead us to conclude that it is sufficient to simply provide layout guidelines for flowing text in arbitrary shapes (preserving the great technical work by the incredibly bright people who documented the existing algorithms - do you remember who contributed to that work?) but not *mandate* every possible detail for how layout is performed.

Jon

At 07:45 AM 11/8/2004, Thomas DeWeese wrote:

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.

----- End forwarded message -----