Re: SVG 1.2 Comment: 4 Flowing text and graphics

Ian Hickson wrote:

> On Mon, 1 Nov 2004, Thomas DeWeese wrote:
> 
>>Did you read Determining Strip Location, it references "line-height" 
>>which I take to be the CSS property with the same name and hyphenation.
> 
> This is not entirely clear, 

    Agreed.

> [...] is very different from the CSS model 

    I would disagree but given the softness of the description I
don't think arguing over it is worth while.  It is probably better
to simply note that the SVG WG needs to specify this better.

>>>>There is no way to control rendering order separately from the 
>>>>logical flow.
>>
>>You didn't address this issue, which is actually quite important.
> 
> If by "rendering order" one means the painting order, then in CSS this is 
> achieved with the 'z-index' property. Any inline element can be made to 
> take part in explicit z-index ordering in CSS.

    Actually you can do a lot more than this with flowRef (because
the referenced flowRegion is drawn in the current coordinate system
which may be rotated/scaled/translated).

    You also have the issue that SVG does not use 'z-index' so you
currently couldn't interleave the SVG and text.  This is also not
a simple issue to resolve as there is a fundamental incompatibility
between filters and 'z-index'.  You can break one or the other to
keep things working (which is essentially what the new layers feature
does).

>>Also the question on accessing geometry information.  Are we going to 
>>extend the XHTML DOM as well?  Or will the geometry stuff go into the 
>>CSS DOM?
> 
> What's the use case for obtaining geometry information for inline 
> elements?

    Because this is a graphics language, you may need to point at
text content, add highlight geometry, do rectangular selection.
Everything in SVG can tell you it's BBox, it would be a very bad thing
if this stopped working for text.

>>>>It's not even clear the SVG document could get events from portions 
>>>>of the flowed text.
>>>
>>>I don't see what is unclear about this. DOM3 Events is well defined in 
>>>the face of multiple namespaces.
>>
>>But it isn't clear in the face of multiple user agents, and this is what 
>>foreignObject implies.

 > <foreignObject> doesn't imply multiple user agents.

    To quote the SVG Specification:

	The 'foreignObject' element allows for inclusion of a foreign
	namespace which has its graphical content drawn by a different
	user agent. The included foreign graphical content is subject
	to SVG transformations and compositing.

> In any case, DOM3 Events fully defines event flow through 
> <foreignObject>, even when code from multiple vendors _is_ involved.

    This may be true 'in theory' however in the real world I don't
know that anyone (except perhaps IE) that would actually allow this
to happen.  This isn't really a worthwhile discussion because what
you are really discussing is a unified HTML+CSS+SVG user agent where
this could/would work.

>>>It seems bad to me to be requiring a lowest-common-denominator 
>>>algorithm for line breaking.
>>
>>This is because you don't care about graphical interoperability between 
>>user-agents.  This is exactly why it's appropriate for the SVG WG (where 
>>this is extremely important) to define this.
> 
> I do not understand why it is important for SVG rendering agents to all 
> have the same line breaking. The whole point of user-agent controlled line 
> wrapping is that the line wraps where it needs to wrap, and not in a 
> necessarily precise location. If the precise location was important, the 
> author would use manual line breaking.

    As has been stated many times in response to this, SVG is a
Graphics format so it is important.  The wrapped text may well
be aligning with other graphics elements.  Also it is worth noting
that unlike most HTML in SVG the text is given a fixed box to fit
into, if the text wraps differently there is a high likelihood that
text will flow 'out the bottom' of the available area and hence
become hidden.

> This is the Web we're talking about, after all. SVG is primarily a Web 
> language (that's why the World Wide Web Consortium is the forum in which 
> it is being designed). On the Web, pixel-perfect accuracy is not as 
> important as in the print world.

    Batik gets complaints because the way we anti-alias content is
different from Adobe!  SVG is a graphics format, in a graphics
format there is a very high premium put on accuracy across renderers.

Received on Thursday, 4 November 2004 11:33:24 UTC