Re: SVG 1.2 Comment: 4 Flowing text and graphics

At 08:45 AM 10/31/2004 +0000, Ian Hickson wrote:
> > 4 Flowing text and graphics
>
>This section seems to reinvent large parts of HTML and CSS (albeit in
>a semantically poorer manner) in order to achieve a single effect.

I am puzzled. What exactly does it reinvent in HTML or CSS? Line breaks? 
SVG 1.1 already has text layout within a line and text on the path. SVG 1.2 
does not add any semantic ("XHTML") features to SVG 1.1, it merely 
introduces additional text layout mechanism, mostly built on top of SVG 
1.1. Why is it somehow OK to have single line text flow with all complex 
internationalization features (baselines, bidi, vertical text, glyph 
orientation) and text-on-the-path and somehow not OK to have (much simpler 
to implement!) text in the shape? We were blasted for this omission in SVG 1.1.

Note that SVG text features are designed in such a way that single text 
engine can easily be designed to handle both CSS and SVG text layout (this 
is what Adobe SVG Viewer 6 preview does). Also, our implementation feedback 
is that you need to add about 10-20% of the code (was 10% in our code) in 
the text layout module to get line breaking working even for arbitrary 
shapes. All complexity in text layout comes from internationalization, and 
incrementability, not line breaking.

As for your proposal, given our experience on text layout feature design, 
it is unlikely that we have enough time to review it before PR. It would 
have been much more helpful if it came earlier in the process (text 
features were fairly stable in the draft for very long time). These are 
problems I see immediately:

- you proposing that we do exactly the thing (extending overflow property) 
that you say is wrong in other places (extending cursor property)
- you propose different algorithm than is in the current draft (which is 
based on SVG 1.1) - what is your justification for that?
- it does not integrate with SVG drawing model (clipping, masking, 
gradients, patterns, filter effects)
- it does not allow one to change order (and other properties, say, 
opacity) in which regions are drawn
- it effectively forces SVG 1.2 implementor to implement full CSS box model 
which is unwarranted

Your proposal might be a good basis for integration between XHTML and SVG, 
though.

Peter

Received on Monday, 1 November 2004 00:26:18 UTC