Re: SVG 1.2 Comment: 4 Flowing text and graphics

> At 07:25 AM 11/1/2004 +0000, Ian Hickson wrote:

>> [..] if you are saying that requiring full HTML support in an SVG 
>> processor is inappropriate, then you seem to have missed the fact 
>> that the SVG working group charter indicates that support of 
>> orthogonal W3C specs in one UA is the expected use scenario for SVG. 

    There is a very large gulf between 'support' and 'require'.  So I
agree that it is important for it to be possible for one text layout
engine to support both SVG and CSS text (I've jumped from HTML to CSS
because we are talking about layout), it is also just as important
that that a CSS layout engine not be required to support all of
SVG, and that SVG clients not be required to support all of CSS
layout.

>> The fact that many SVG working group
>> members are now taking part in the CDF work would suggest that this is 
>> not a contentious issue.

Peter Sorotokin wrote:

> Everyone I know agrees that there should be only a single text layout 
> engine in a well-designed UA and that exact syntax is not very relevant.

    To get on with this point, I actually don't care that much about
using xhtml:div, or xhtml:span, or foo:banter, to contain the
content.  What I do care about is what UA's are expected to do with
that content.  What the display of that content entails.

     As far as I can see the alg described in the SVG spec is
compatible with the CSS inline element description.  In particular 
implementations should do line-height, they shouldn't do
vertical-align, because flow in SVG is simply a word-breaking of the
SVG 1.0/1.1 text layout (see 'alignment-baseline').

>> I'm sorry, but the current model is not compatible. 

   It is not identical I think it is compatible, however _huge_
sections of CSS layout are missing from the SVG layout model.
Much as CSS ignored huge portions of the SVG filter model
to enable 'shadow', that doesn't mean that you can't easily
support 'shadow' in an SVG renderer using filters.

>> Implementations that claim to implement both with a 
>> single engine are almost certainly incorrectly implementing 
>> the CSS inline box model.

    No you are missing the point, when processing SVG large
chunks of the CSS layout are simply not used.

>> For example, the following:
>> 
>>    <div><span>this is a test</span></div>
>> 
>> ...and the following:
>> 
>>    <flowDiv><flowSpan>this is a test</flowSpan></flowDiv>
>> 
>> ...with the following styles:
>> 
>>    div, flowDiv { font: 20px/20px serif; }

    Since SVG flows do not have CSS block level elements this statement
has no meaning except in the context of property inheritance for SVG.

>>    span, flowSpan { font: 5px/10px sans-serif; }
>> 
>> ...would look different. Assuming a sans-serif font with a baseline 20% 
>> above the bottom of the em quad, the first would be 21px high 

    Not that it matters, but I would have said 20px high, where does
the extra 'px' come from?  Just assuming the font extents exceed 20?

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

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

>> and that's just a very simple example. (These cases would even be 
>> different if the line-height equaled the font-size throughout, 
>> so I guess I could make it _even_ simpler and still have differences.)

    Of course you can make documents that render differently.  This
doesn't mean that they aren't compatible, it simply means that they
aren't identical (which I don't think anyone has said).  There are
tons of layout features from CSS 2 that aren't included in SVG, use
any one of them and it will look different.

    The question of compatibility is a _much_ deeper one.  For example
does the fact that SVG uses "alignment-baseline" for much the same
purpose of CSS2's "vertical-align" on inline elements make them
incompatible?  As an implementor I would say no, since they can both
feed into the same piece of code that deals with inline
box adjustment, you could potentially argue otherwise.

>>> Translating it to more practical language you proposing to DROP line 
>>> breaking features in SVG 1.2 and wait several more years before these 
>>> integration issues are resolved
>> 
>> 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?
I see references to CSS 3 dating back to Feb 2000 and it still isn't
done, CSS 2.1 went to last call in Aug of 2002 and it also still isn't
a full rec.

    Given this past record, how can you possibly suggest that something
as significant as adding layout into arbitrary regions could be
added to CSS in less than several years?

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

    There is no way to pair SVG paints, filters, opacity, etc with the
text.  There is no way to control rendering order separately from the
logical flow.  There is no way to get geometry information on the
text.  It's not even clear the SVG document could get events from
portions of the flowed text.  These would all be pretty important.

    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.  Is the CSS WG going to
suddenly start specifying exactly how line break opportunities are
identified, and exactly how the extent of words are calculated for the
purposes of fitting text to a line?  Are all the existing implementors
of HTML renderers going to agree to these new rules quickly? ;)

Received on Monday, 1 November 2004 15:19:16 UTC