- From: Ian Hickson <ian@hixie.ch>
- Date: Mon, 1 Nov 2004 20:00:17 +0000 (UTC)
- To: www-svg@w3.org
On Mon, 1 Nov 2004, Peter Sorotokin wrote:
> > >
> > > People _do_ multiline text today in SVG, but it is done with x and y
> > > attributes. We just want this line breaks to happen automatically,
> > > nothing more. No document-level (box) layout, no document structure
> > > structure, no semantics, but reliable positioning and integrating
> > > with SVG rendering pipeline.
> >
> > You say this as if it was a good thing, whereas it would seem to be a
> > strong violation of both WCAG (checkpoint 3.1 in particular, but also
> > 3.6 and 3.7) and AWWW (4.3, 5.1).
>
> No, it is a bad thing and that is exactly what we are trying to fix.
By "it" I meant the SVG 1.2 solution, not the SVG 1.1 problem.
> (BTW, it would help if you provided links to the documents that you
> reference).
http://www.w3.org/TR/WAI-WEBCONTENT/#tech-use-markup
http://www.w3.org/TR/webarch/#pci
> > My point was just that while it makes sense for SVG to define how to
> > handle a single line of text (especially when this integrates tightly
> > with SVG's other features, for example with text on a path, with exact
> > length-mapping, glyph orientation, stroking and filling effects, and
> > so forth), it does not make sense for SVG to then expand this all the
> > way to fully-flowed aligned text, since that is something that has
> > been the bread-and-button of an existing W3C specification (in this
> > case CSS) for some 8 years now.
>
> CSS is way bigger than that. Even CSS box model is way bigger than that.
Just like SVG is way bigger than gradients.
> > > 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).
> SVG defines all of the above.
How can it be compatible with the CSS engine then?
> > Just use the 'background-image' property and link to an SVG file that
> > consists of a gradient: [...]
>
> Ah, OK, that is more like of "accidental integration". The reason I
> asked is that I have never heard of CSS WG defining anything that would
> specifically integrate or leverage SVG in any way and I thought maybe
> that is changing. Too bad it is not.
Why on earth would the CSS working group go out of its way to tie itself
to a particular graphics format when any would do? That would be quite bad
design! The point is that so far the CSS working group has avoided
introducing features that overlap with SVG because they can be achieved if
the user agent supports SVG.
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.
> > > > > 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).
> > > >
> > > > I don't really see how. The CSS inline box model and the SVG 1.2
> > > > text flow model are _radically_ different.
> > >
> > > You realize that you telling this to someone who has actually
> > > implemented both of them, right?
> >
> > You realise that you are telling this to someone who has actually
> > tested both of them, right?
>
> Nice stunt! Ian, do you think that by testing them (even assuming you
> did a lot of SVG 1.2 text layout testing) you gain a lot of knowledge
> about if it can or cannot it be implemented by the same engine?
Yes.
> > Does your CSS version pass all these tests?
> >
> > http://www.hixie.ch/tests/adhoc/css/box/inline/
> > http://www.hixie.ch/tests/evil/mixed/lineheight1.html
> > http://www.hixie.ch/tests/evil/mixed/lineheight2.html
> > http://www.hixie.ch/tests/evil/mixed/lineheight3.html
> > http://www.hixie.ch/tests/evil/mixed/lineheight4.html
> > http://www.hixie.ch/tests/evil/mixed/lineheight5.html
> > http://www.hixie.ch/tests/evil/mixed/lineheight6.html
> > http://www.hixie.ch/tests/evil/mixed/lineheight7.html
>
> No, since these are not XHTML and I am not doing HTML.
Many of them (available at the first URI) are XHTML tests. These tests are
all pretty basic tests for the CSS inline box model. Unless you pass most
of them, you really can't claim to have implemented the CSS inline box
model in any useful way that could give useful implementation feedback.
> I looked into several of them and I do not see anything in these tests
> that would collide with SVG 1.2 features, can you be more specific?
I included an example in one of my earlier e-mails, and have quoted it
again below.
> > (Is there a product I can download somewhere to test this?)
>
> You can look at ASV6 preview, but that code is fairly prototypish and
> certainly it is missing a lot of features.
There is no stand-alone (non plug-in) product that can be tested?
> Ability to do clipping, masking
Clipping and masking should be possible in the same way you can clip
anything else already.
> stroking, gradient and pattern filling/stroking
> filter effects on per-span and per-region basis.
These would not be available for multiline text with my proposal as is,
but it seems that these features would be useful for any multiline
content, not just for multiline content in the context of drawings, and
thus should really be achieved using extensions to CSS and not SVG.
> > > 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? 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.
> > > 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. 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 can assure you that not only SVG WG is always keeping in mind
> > > integration with other document formats and W3C technologies, but
> > > have a proven record of doing so (SMIL, FO, CSS/XHTML, XForms,
> > > XMLEvents come to mind immediately).
> >
> > So why does SVG 1.2 not do so in this instance?
>
> Because doing it would mean CSS producing something radically different
> than it has now.
It would be a small addition to the 'overflow' property. That's hardly
"radically different". In any case that is not an argument for not going
with CSS -- CSS is doing multicolumn text layout which is just as
different. Are you suggesting we shouldn't do that but should use SVG
instead? That makes no sense.
> There is nothing that we can reuse as of today.
Except for the entire line layout model and the semantic richness of using
HTML as the markup language (not to mention the ability to then mix in
MathML and instantly allow math expressions in SVG text as well).
> > > It is even OK for pure Unicode (with no mark-up at all) to spec out
> > > how to break lines in text.
> >
> > I'm not sure what you're suggesting here. Unicode is at a conceptual
> > different level than CSS and SVG.
>
> It is, but Unicode defines how to break lines. You are saying CSS has to
> do that.
I really wish you would stop attacking arguments that I haven't made.
I didn't say CSS had to define how to break lines. I said that W3C specs
should re-use other W3C specs when defining features that were common to
both, instead of reinventing every feature in each new spec.
> > Would you not suggest that the CSS working group was at fault if we
> > introduced ways of creating vector graphic shapes using CSS?
>
> General shapes are central to SVG and very peripheral for CSS, whereas
> line breaking is something that happens just as often in drawings as in
> documents.
Statistically I find that rather hard to believe.
> Can you name a case where your proposal would produce different result
> from SVG 1.2, if no features which are not in SVG 1.2 are used? Having
> analyzed the algorithm I do not see the difference you are talking
> about.
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.)
On Mon, 1 Nov 2004, Thomas DeWeese wrote:
> > >
> > > ...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?
It comes from the CSS inline box model line height calculations and
baseline vertical alignment, one of the parts that the CSS and SVG models
differ on.
> > > 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).
As far as I can tell from the SVG specifications, the line-height property
is always assumed to equal the font-size property.
> > > 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.
> 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.
CSS2.1 will remain in CR until there are two interoperable implementations
of every feature. If SVG 1.1 had had the same exit criteria as CSS 2.1
has, it would probably still be in CR as well, and the test suite would be
significantly bigger (as, for instance, the Selectors test suite is). If
it had exit CR it would had likely done so by dropping the features that
are not very interoperably implemented.
> > > 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.
> There is no way to control rendering order separately from the logical
> flow.
Right, you would use the CSS model to do this. Maybe 'fill' and 'stroke'
should apply to CSS-styled content?
> 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.
> 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. Does this mean high-quality implementations are not
allowed to use adaptive balancing justification algorithms? That
hyphenations is not permitted for any UA?
--
Ian Hickson U+1047E )\._.,--....,'``. fL
http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Received on Monday, 1 November 2004 20:00:23 UTC