W3C home > Mailing lists > Public > www-svg@w3.org > November 2004

Re: SVG 1.2 Comment: 4 Flowing text and graphics

From: Ian Hickson <ian@hixie.ch>
Date: Wed, 3 Nov 2004 23:53:39 +0000 (UTC)
To: Thomas DeWeese <Thomas.DeWeese@Kodak.com>
Cc: www-svg@w3.org
Message-ID: <Pine.LNX.4.61.0411032344250.26363@dhalsim.dreamhost.com>

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, but either way, the spec's description:

| The line-box is calculated using the initial position as the top/right 
| edge of the line-box, and the line-height of the first word.

...is very different from the CSS model (where the line box height is 
initially the block-level line-height, with the block's metrics deciding 
the initial baseline position, and then each subsequent inline box 
affecting the line box height using 'vertical-align' and 'line-height').

> > > 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.

> 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 

What's the use case for obtaining geometry information for inline 

> > > 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. In any case, DOM3 
Events fully defines event flow through <foreignObject>, even when code 
from multiple vendors _is_ involved.

> > 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.

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.

Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
Received on Wednesday, 3 November 2004 23:53:42 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 8 March 2017 09:47:01 UTC