Re: Wrapping Text in SVG

Hi, Dr. Olaf-

On 6/4/13 5:22 AM, Dr. Olaf Hoffmann wrote:
>
> to fit text into a rectangular area, the approach of
> SVG tiny 1.2 textArea is already not bad - why not
> to continue with this?

<svg:textArea> has several logistical problems:

1) Its name conflicts with the HTML <textarea> element, and it compounds 
this by having different functionality than <textarea>; this will make 
it confusing for authors, and makes parsing SVG in HTML (a very common 
case today, with script libraries like D3.js and Raphael) much harder (I 
suspect browser vendors would not implement this, because of the parsing 
conflict);

2) It doesn't provide a fallback, and does not degrade gracefully in 
older user agents; if an SVG UA (browser) doesn't know the 
<svg:textArea> element, it will simply not render the text, which is the 
worst option. In my proposal to extend the functionality of <svg:text>, 
if the browser doesn't know how to apply the 'width' property to 
<svg:text>, it will still render the text as a straight line; this is 
not a great fallback, but it's much better than not rendering anything 
at all (at least in most cases); you could use <switch> for this, but 
that's a clumsy construct most people don't know and won't bother with;

3) SVG Tiny 1.2 defines a specific text layout algorithm [1], which on 
the face of it seems smart and responsible, but in this instance, it may 
cause conflicts with the existing engine-based text-layout mechanisms in 
browsers today; for all I know, the SVGT algorithm is largely compatible 
with existing browsers, since CSS does not actually define text layout, 
but in the past, this has been a source of some contention with browser 
vendors, and the suggestion that they subscribe to SVGT's text-layout 
algorithm is likely to be rejected; the algorithm also defines behaviors 
for certain properties that are indeed likely to not perfectly match CSS 
(being based on XSL), and this would add to the difficulty of 
implementation. The path of least resistance toward text-wrapping in SVG 
is to reuse existing CSS code-bases;

4) It has a few minor warts: the camelCased tag name is out of fashion, 
and error-prone (I've been bitten by viewbox/viewBox myself several 
times); it uses 'xml:space' in a way that we know is an abuse;


I want to note that I actually quite like most of the way <svg:textArea> 
is defined, and I would like for CSS to adopt some of its 
characteristics, including a well-defined text-layout algorithm and the 
XSL-based, internationalization-friendly layout properties. It's just 
that it's not pragmatic to insist on <svg:textArea> when there is likely 
to be well-justified resistance, and I want to meet the needs of authors 
in a short timeframe more than I want to see the "best" solution win; in 
this case, compromise also has other benefits, because CSS offers a very 
workable and familiar model that will help CSS experts adopt SVG.

I also want to point out again that Tav's proposal for text layout into 
arbitrary shapes, using CSS conventions wherever possible, is also quite 
good, and he and I believe it is complementary to what I'm proposing. In 
fact, my simple text-wrapping proposal would be a good fallback for the 
more advanced shape-wrapping that Tav is describing.

Does all this seem reasonable to you?


> But what one needs additionally, from my point of view:
> a) overflow: scroll and overflow: auto for text boxes
> with a behaviour as known from ordinary CSS.

Agreed. Cameron mentioned this during the telcon (well, F2f, but I was 
not there, so I dialed in), and it seems sensible to me.


> b) Additionally an alternative approach for the
> situation, that the text with line wrapping does
> not fit into the rectangular box.
> To be able to have a method to adjust the
> font-size automatically would be a good
> idea, for example a property named
> scale-font-size with values like auto,
> resize,  reduce,  increase, none.
> reduce only applies in case there is a
> need to reduce the font-size, that the
> text fits into the box.
> increase only applies to in case there
> is a need to increase the font-size,
> that text fits into the box.
> resize fits in both cases the text into
> the box.

We talked about this during the telcon, and Tab suggested that we use 
percentages for this; if we define a width and height for <svg:text>, 
then we can also define a way for 'font-size' percentages to fill that 
space.

Tab also mentioned that CSS was looking at a more advanced way to do 
this, and we could simply use what they create.


> c) Increase the box (depending on
> the text direction either horizontally or
> vertically) including wrapping
> to a size, that the text fits and be
> able to reuse this size for backgrounds
> or positions of other elements and
> the size of the viewBox
> (maybe difficult to do this, if one
> does not use such a content model
> as assumed for XHTML+CSS).

This is actually somewhat tricky, involving multi-directional constraints.

Note that in the future, we would be able to use 'calc()' for some of 
these use cases.


> Currently one does not even have
> all of this, if one puts an XHTML fragment
> into a foreignObject.
>
> At least for use cases I have in mind,
> it is typically not meaningful to clip text,
> if there is more text that fits into the box.
> And if there is no clipping and the text
> flows out of the box there is at least
> a need to require the user agent to
> extent the viewBox on demand in an
> easy way, that the reader has a chance
> to read all the text.
>
> Clipping text is maybe of some relevance
> only, if the text consists of repeated segments
> like a pattern and there is no really need to
> see more than one segment at all to
> understand the message.

I reckon you're right about clipping for the vast majority of cases. 
Again, relying on CSS should help us do the sensible thing for most cases.


[1] http://www.w3.org/TR/SVGTiny12/text.html#TextAreaLayout

Regards-
-Doug

Received on Tuesday, 4 June 2013 18:05:18 UTC