Re: SVG 1.2 Comment: 4 Flowing text and graphics

I do not see this thread as all that productive, so I answer only several 
selected points.

At 08:00 PM 11/1/2004 +0000, Ian Hickson wrote:
> > > > Line breaking is the _only_ substantial addition to SVG 1.1 here in
> > > > terms of text layout!
> > >
> > > Line breaking is a big thing. I am told that in the whole of the
> > > Safari rendering engine, for example, the most complex function is the
> > > one that determines line breaking opportunities. I have myself written
> > > dozens of test cases for line breaking issues in Web browsers.
> >
> > Hmm, have you seen Unicode Standard Annex No. 14 (that SVG 1.2
> > references)? It is actually quite simple and easy to implement. Most of
> > the hard work (classifying cases) was done in compiling the character
> > classes and break table.
>
>UAX 14 is woefully inadequate for describing required line breaking
>behaviour. Requiring UAX 14 compliance dramantically restricts the ability
>for user agents to achieve optimum line breaking (as, in fact, UAX 14
>itself points out in the introduction), for example it prevents handling
>of hyphentation. CSS2.1 intentionally leaves much of the line breaking
>algorithm to the user agent, since interoperability on the exact line
>breaking algorithm is not required for optimum user experience. However,
>key parts are defined (e.g. in 16.6.1).

For SVG we want reproducible layout and definitely we want basic line 
breaking rules to be in the spec. This is graphics, after all. Hyphenation 
definitely is lower priority and is not allowed unless soft hyphen is 
explicitly used. This goal is different from CSS.

>[snip]
>
>It is IMHO inappropriate for SVG to be now introducing features that
>overlap with CSS without even trying to find a CSS-based solution first.

We certainly considered CSS layout (in fact I was the one who made a 
proposal on it!) and it was rejected as not achieving SVG 1.2 stated 
requirement.


>[snip]
> > > > How many real-life documents do you have which use gradients? Most
> > > > that I have seen are more drawings than documents.
> > >
> > > There are gradients on:
> > >
> > >    http://www.adobe.com/
> > >    http://www.macromedia.com/
> > >    http://www.gamespot.com/
> > >    http://www.disney.com/
> > >
> > > ...to name but 4. Most of these are done using bitmap graphics right
> > > now.
> >
> > In ideal world all of them would have made a heavy use of SVG. They are
> > just as much drawings as documents. Name anything that uses just
> > gradients. My assertion is that there are not many.
>
>I don't understand that argument. There are no real life documents that
>use only gradients, and therefore it makes no sense for CSS to support
>gradients?

No. The point is that real life documents that use gradients are likely to 
use many more SVG features (shapes, patterns, even filters). So doing just 
gradients is not all that useful - you'll still have a lot of artwork as 
bitmap images in such a document.

>CSS does, as you yourself pointed out, much more than just
>gradients. The equivalent argument would be that there are no drawings
>that do only multiline text and therefore SVG shouldn't have multiline
>text, which I'm sure you agree is a specious argument.

There is a big share of drawings that only need line breaking for text and 
do not need other features from CSS (such as box model, selectors, cascade, 
etc.).

There is not a big share of documents that only need gradients but do not 
need other features from SVG (shapes, stroking, filters, clipping, etc.)



> > > > How many real-life drawings have you seen than use multiline text?
> > > > Pretty much all of drawings that use text at all.
> > >
> > > Most of the drawings I've seen that use flowed multiline text are
> > > really documents that happen to be styled with fancy backgrounds and
> > > borders, and are not what I would call drawings.
> >
> > You did not answer my question. How about drawings? Maps, schematics,
> > diagrams - pure drawings - use multiline text more often than not.
>
>I can't off hand think of any drawing that used multiline text with
>automatic word-wrapping where that text would not be better marked up
>using a semantic markup language.

It is always better to use semantic mark-up language if there is any 
semantical structure in the text. This is true for any text and line 
breaking is totally irrelevant there. However, there are cases where text 
is really a part of the artwork and does not have any semantic structure, 
at least not any more than all other parts of the drawing.

>Maps rarely use multiline text in my experience (mostly text on a path), 
>schematics typically have just labels,
>and when the labels expand into multiline text that text would need rich 
>semantic markup such as HTML <var> elements.

I think "multilineness" is a red herring here! The fact that text is or is 
not multiline by itself does not have anything to do with need for semantic 
mark-up. It can be a label on a diagram that is just longer than the next 
one, so it has to be split in two lines; it might have no internal 
structure whatsoever. On the other hand it can be a single line with a 
couple of words that need to be bracketed inside semantic mark-up (say, 
because it is a Latin quotation). You are just trying to somehow connect 
line breaking with semantic mark-up, I think this is a faulty connection.

Peter

[snip]

Received on Monday, 1 November 2004 21:39:00 UTC