RE: Text "extent" in SVG 2 vs CSS Writing Modes

Tavmjong Bah wrote
Sent: Thursday, May 21, 2015 9:15 AM
To: Tab Atkins Jr.
Cc: Amelia Bellamy-Royds; www-svg
Subject: Re: Text "extent" in SVG 2 vs CSS Writing Modes

On Thu, 2015-05-07 at 13:32 -0700, Tab Atkins Jr. wrote:
> On Thu, May 7, 2015 at 1:24 PM, Amelia Bellamy-Royds

> >
> > The minutes from the F2F that chose the word `extent` aren't 
> > terribly informative [2]: does anyone remember why this particular term was chosen?
> > If it was intended to synchronize with the CSS terminology, then we 
> > got it wrong.  If its just an unfortunate coincidence, I wonder if 
> > it is not too late to replace it with `line-length` or something else?
> SVG chose the wrong term anyway - "measure" is literally "the length 
> of a line of text"
>  ^_^
> ~TJ

'extent' was chosen rather arbitrarily to replace the original 'width'
and 'height' on an SVG text element when dealing with horizontal and vertical text. I would have no problem to replace 'extent' by 'measure'.

Which reminds me, that I promised Tab an explanation of why we want the attribute in the first place (to replace the original 'width' and 'height' attributes). I wrote something up quite awhile ago but never got around to posting it.. so here it is:

To understand why the SVG working group replaced the original 'width'
and 'height' attributes by 'extent'/'measure' one needs to look at SVG text in general and especially how the 'x' and 'y' properties/attributes for text are interpreted. In SVG the 'x' and 'y' properties set the origin for rendering the first glyph (and not the corner of a content box). This makes, as explained below, using 'width' and 'height'

SVG 2 has three ways of obtaining multi-line text:

1. Use 'white-space' values 'pre', 'pre-wrap', or 'pre-line'.

   This mode is a simple extension to the SVG 1.1 <text> element where line-feeds create new lines of text. Line spacing is controlled by the 'line-height' property following normal CSS rules but alignment of the lines uses the SVG 'text-anchor' property. (This is already implemented by Firefox and to a lesser extent Inkscape.)

2. Use 'extent' (or 'measure') to define a content area in one dimension.

   This mode is also a simple extension to the SVG 1.1 <text> element that enables auto text-wrapping. The positioning of the first glyph is still established by the 'x' and 'y' properties but now alignment follows the CSS 'text-align' property. Defining the 'x' and 'y'
properties this way has two advantages:

   A. It is consistent with SVG 1.1 text.

   B. It allows for a natural SVG 1.1 renderer fallback solution.[1]

   For horizontal text, setting a "width" is perfectly well defined as is setting a "height" for vertical text. Setting a "height" for horizontal text when the 'x' property refers to the baseline of the glyph is confusing. Does having a height change the definition of 'x' so that it refers to the top of a content area? It would be strange if it did. But if it doesn't, what does height mean? Do you need to subtract off the height of the first line to find the bottom of the context area?
What if the the height of the first line changes? Then the positioning of the bottom of the content area would shift. The SVG WG decided that it was better not to allow a height to be set for horizontal text. If a user wants to defined a rectangle content area of a specific height then they can specify a content area using the 'shape-inside' property.

3. Use 'shape-inside' to set a content area.

   This mode assumes the full CSS text layout model inside (for SVG 2) an SVG shape. In particular, 'shape-inside' can reference a rectangle defined by 'x', 'y', 'width', and 'height'. (It might even be better to be able to reference a CSS rectangle shape like was in an early version of Shapes.)

[1] If a content area is provided, the 'x' and 'y' values, except the initial 'x' and 'y' values in mode 2, are ignored. Thus a content creation program can implement multi-line text using <tspan> elements with appropriate 'x' and 'y' values. An SVG 2 renderer will ignore the values and auto-wrap the text (taking into account the metrics of the font used). An SVG 1.1 renderer will use the 'x' and 'y' values (if rendered with a different font than used when the text was laid out, the resulting text rendering may not be ideal but will at least be readable).

Hi Tav, all.

If I had seven hours, I could describe 70 hours worth of frustration on alignment of multi-line text in SVG. 1.1 was bad, but things seem to be going downhill since about 2011. has examples that worked well across browsers in 2011, and work almost nowhere now. Trying to build text-flow into polygons as in was painful. Wasn't all of that part of SVG1.2?

For what it is worth, a day or two ago, I tried for several hours to get this example to properly size across browser, so it could be properly posted at Ello. It is at social media that people actually see animations, btw. 

IE and FF don't seem to understand things like font-family="serif" font-stretch="ultra-expanded" textLength="620" lengthAdjust="spacingAndGlyphs" font-weight="bold" , at least in the same way that Chrome does. I'm pretty sure that old Opera did things the way one would expect.

Ultimately, it has been very hard (for the past 14 years of experimentation) to get text to occupy just the proper footprint on the screen: sort of a requirement for text art and logos and such -- and having that happen is sort of a prerequisite for having people make accessible text rather than animated gifs. And that is sort of a requirement under the laws of many nations. 

Here is another example where the sizing of the text consistently seemed to be impossible. 

Getting this to display properly in Chrome, one actually has to view it as shown at Ello :

Really, getting it so that text occupies the same footprint across browsers is my use case, here. It'd be nice to be able measure the darn stuff for one thing and to get it to fill a rectangle, for another.


Received on Thursday, 21 May 2015 16:09:36 UTC