Re: SVG 1.2 Comment: 4 Flowing text and graphics

Ian Hickson wrote:

>>>>with the baseline 5px above the bottom (16px below the top), whereas 
>>>>the second would be 5px high with no leading whatsoever.

> On Mon, 1 Nov 2004, Thomas DeWeese wrote:

>>I would expect the strip for the text to be 10 userspace units high with 
>>2.5 userspace units leading.  You seem to think that line-height isn't 
>>used at all, but I would think that it was, it's just that only the 
>>inline-level aspect that applies to SVG. Of course I'm not in the WG so 
>>perhaps I'm wrong (see 4.13 Determining Strip Location).
> 
> As far as I can tell from the SVG specifications, the line-height property 
> is always assumed to equal the font-size property.

    Did you read Determining Strip Location, it references
"line-height" which I take to be the CSS property with the same name
and hyphenation.

    But let us just set all of this aside and assume that, in the case
of SVG, line-height is ignored and is always equal to the font-size
(which you are probably taking from the SVG 1.1 specification).
How does that make the SVG line break alg incompatible with CSS?
It simply means that it's a subset, which I think was the goal.

>>>>Again, you are attacking a straw man. There is no reason why my 
>>>>simple proposal should take years.
>>
>>Who's attacking a straw man?  I can't imagine the adoption of your 
>>proposal taking less than several years.  Especially since it is very 
>>unlike to be divorced from a new version of CSS, version 4 perhaps?
> 
> CSS3 is a modular specification. The CSS and SVG working groups are 
> working together on other specifications that will be published in 
> significantly shorter cycles than the rest of CSS3 (including XBL, the 
> @namespace syntax, and Web fonts); I see no reason why this should 
> suddenly take much longer.

    It would better to say "Hope to be published in significantly
shorter cycles".  XBL is way to soon in the process to have any idea
about (although it's worth noting that there were proposals in this
area within the SVG WG dating back at least to the first SVG Open, in
2002), searching the W3C site I see Web fonts dates to 1996, and CSS
namespace draft came out June 1999.  These are clearly rushing through
the standards process at light speed.

    However, I do agree with you that I see no reason why this would
take much longer, we might have something in late 2008. ;)

>>>>There _are_ no integration issues (at least, nobody has yet named 
>>>>any).
>>
>>Well, since your proposal doesn't do any real integration this isn't 
>>surprising.  It essentially says embed a full (X)HTML/CSS renderer and 
>>allow it to reference some SVG geometry for flowing (in some cases), 
>>otherwise it lives in a totally separate world, which is made clear by 
>>your use of 'foreignObject'.
> 
> Indeed.
> 
>>There is no way to pair SVG paints, filters, opacity, etc with the text.  
> 
> Right, you would use the CSS model to do this. Maybe 'fill' and 'stroke' 
> should apply to CSS-styled content?

    Sure, why not make it impossible for anyone to actually fully
implement anything.  You forgot filters which are lots more fun
to implement, and incompatible at a pretty fundamental level with
popular features like 'z-order'.  Also how exactly does fill and
foreground interact?

>>There is no way to control rendering order separately from the logical 
>>flow.

    You didn't address this issue, which is actually quite important.
    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?

>>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.  If you had simply included the html
inline then it would be clearer that you needed to have a single UA
that implemented SVG+XHTML+CSS and hence event propagation would
likely take place as defined by DOM3 Events.


>>Also this would still not meet one of the primary design criteria of 
>>text flows in SVG which is a fixed line breaking alg so you can get 
>>reproducible results across implementations.
> 
> 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.

> Does this mean high-quality implementations are not 
> allowed to use adaptive balancing justification algorithms? That 
> hyphenations is not permitted for any UA?

    There was talk at some point of a CSS property that would
explicitly allow implementations to use more advanced algorithms.
However every implementation must include the 'baseline' conformance
algorithm for interoperability.

Received on Monday, 1 November 2004 23:02:35 UTC