Re: SVG 1.2 Comment: 4 Flowing text and graphics

On Mon, 1 Nov 2004, Peter Sorotokin wrote:
>> 
>> If the SVG working group instead encouraged use of semanic HTML markup, 
>> authors could use the strong semantics of elements such as <cite>, 
>> <em>, <blockquote> and the like.
> 
> I agree that this would be beneficial, but it has to be done in the 
> Compound document activity not in SVG WG.

The compound document activity's charter is to specify profiles of 
existing specifications, not to create new features of this nature.

It would be the responsibility of the SVG or CSS working groups to define 
features for flowing semantic content into arbitrary shapes.


> So far I am not sure how exactly your proposal would differ in terms of 
> glyph positioning. It appears that your proposal effectively rephrases 
> SVG 1.2 algorithm.

My proposal is merely an extension to the CSS model. It is quite different 
from the proposed SVG model, which is itself quite different from the CSS 
model (for example, the SVG model does not support 'line-height' or 
'vertical-align', and doesn't support the CSS box model on inlines).


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

In that case, why does SVG 1.2 introduce a new text layout algorithm that 
is radically different from the CSS model, using an entirely new syntax?

If it really is true that the SVG working group wants there to only be one 
text layout algorithm, then it would make the most sense to simply 
reference the existing algorithm normatively. If it really is true that 
the exact syntax is not very relevant, then it would make the most sense 
to simply reference the existing syntax normatively.


> 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. There _are_ no integration issues (at least, 
nobody has yet named any).


> even though there is a strong implementation feedback that there is 
> nothing in the current SVG 1.2 proposal that would negatively impact 
> integration in future.

Please consider my feedback to be implementation feedback from Opera to 
the effect that the current SVG 1.2 proposal would negatively impact 
integration in future (in fact, it would negatively impact any effort to 
have a single text layout algorithm right now, if we started implementing 
SVG today.) I have also heard similar complaints from Apple and Mozilla 
engineers. Indeed, Apple sent implementation feedback on this very matter 
to the SVG working group list only a few days ago:

   http://lists.w3.org/Archives/Member/w3c-svg-wg/2004OctDec/0701.html

...so it is patently untrue that "there is a strong implementation 
feedback that there is nothing in the current SVG 1.2 proposal that would 
negatively impact tegration in future".


> Moreover, SVG WG specifically defined line breaking in such a way that 
> it is compatible with CSS and a single engine can be used to do line 
> breaking for both specs (which is much more important than exact syntax) 
> and the success of this design goal has been validated in 
> implementations.

I'm sorry, but the current model is not compatible. Implementations that 
claim to implement both with a single engine are almost certainly 
incorrectly implementing the CSS inline box model.

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; }
   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 with the 
baseline 5px above the bottom (16px below the top), whereas the second 
would be 5px high with no leading whatsoever. 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.)

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Monday, 1 November 2004 09:25:02 UTC