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"
> http://en.wikipedia.org/wiki/Measure_%28typography%29  ^_^
> 
> ~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'
confusing.

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).

Tav

Received on Thursday, 21 May 2015 13:15:41 UTC