[SVG 2 editors-draft 2013-08-08] Text layout

Hello,

I think, the major problem for SVG authors with longer sections of text is,
that for not exactly known fonts as the generic font families, they do not
know, how to chose the font-size, that the text fits into the intended area.
For example in my SVG-photo-gallery such a problem occurs with
image descriptions. Currently I'm counting glyphs with PHP to wrap
with tspan, however, if no monospace font is used, this is just a rough
approximation and usually it does not fit very well.

If this new text layout section is intended to solve real problems, this 
should be covered, for example by providing an option to set a 
font-size-correction property that scales the font-size to a value, that
the text fits into the intended area, respectively, if for example the
height of the area is not restricted, that the texts fits into the 
viewBox/viewport or can be made accessible else.
There can be different values for this new property to decide whether
the scaling only applies, if there is more text than area, or only if
there is less text than area or both etc.

Something similar was already discussed, therefore it is surprising
still to find such a concept in the draft, that almost no author needs
to make good use of this new option of automatic text wrapping.

I think, for most SVG use cases the mentioned property text-overflow
is almost useless (maybe for (X)HTML as well, at least how I use this
as author and reader - at least for CSS styled (X)HTML it is an option
to switch off CSS interpretation to get access to the complete content,
but for SVG this does not solve the problem). 
Such ellipsis may inform the user, that something is missing, but obviously
there is at least a requirement to define a method how to access the missing
part of the text (how to present it for the viewer).
But of course, typically SVG authors want the text to fit into the area and
need no ellipsis - scrolling would be maybe acceptable as well for several
use cases (this could be done in SVG as well with declarative animation to
provide more control to the author, but this requires an animatable feature 
to define, which part of the text is displayed in the area).
Users obviously want to have access to the complete text and not just
an information, that it is clipped.  What is the idea, what the users
should do with these ellipsis? If the text contains words longer than the
width of the area, they do not even manage to read the first lines
completely - and even if this is not the case, one cannot assume, that
the final, missing part contains no relevant information anymore.

For both authors and users there is additionally the problem, that for the
user it is not necessarily obvious, whether such ellipsis belong to the text 
or whether it is an indication of missing text. If this is used at all, there 
is a need to indicate, that it replaces not accessible text, for example with
an additional warning and an interface  by the user agent to provide the 
missing text.




Olaf


PS: for basic shapes like lines, polyline, polygon provide non trivial
examples - because a line does not create an area, show how this
basic shape can be used at all. For polyline, polygon show, how
intersections, 'hole' have influence on the text layout.

Received on Friday, 9 August 2013 13:00:33 UTC