Comments on Text and Fonts in working draft of SVG 1.2

12.4 Hinting SVG Fonts

I did not know that this was in the pipeline, but was extremely glad to see
its inclusion. This has been a sticking point for many people when they
compare small SVG text compared with text the same size in HTML. Also, I
think this will help considerably on smaller screen sizes. I appreciate the
fact that it will be royalty-free.


2 Text Wrapping

On the whole, I was positively giddy at the extent to which text shapes can
be described. I was afraid that only rectangles were going to be allowed,
which struck me as woefully inadequate, but the WD far exceeds my hopes. The
exclusion areas are an especially nice touch, and the Eiffel Tower diagram
makes a very clear model.

A very few things concerned me, or left me wondering how they were to be
dealt with:

Text-Anchor
"Text progression direction" was mentioned several times, but I was unclear
whether that applied only to BIDI, or included 'text-anchor: middle/end'. It
shouldn't be much of an issue, but I thought it bore mentioning.


Dimensions/Shape of FlowArea
Is this intended to be animatable, by script or SMIL? I would like to see
this be the case. An practical example would be a resizable text-box.
Perhaps it could be implicitly expanded (if defined in relative units) to
fit the amount of text to contain.


Text-Overflow
In 2.2 (flowRegion), y'all state "Once the text fills a shape it flows into
the next shape." In the case where there is "leftover" text (text that
remains unplaced after all textRegions have been filled), what happens to
the remaining text? Is it placed as one long line outside the last
flowRegion? Or cut into strips of the same dimensions as the final strip and
placed at the logical "bottom" of the last flowRegion? Would it heed any x/y
coordinates that the parent <text> element might have possessed before being
contrained to the flowRegion? Or would it simply be clipped, and not
rendered?  I think that the author should be able to specify text-overflow
as 'visible', 'hidden', 'grow', or 'repeat'. 'grow' would continue to cut
the text into strips of the same dimensions as the last strip, placing each
strip on a subsequent line; this would make the most sense for rectanglar
flowRegions, of course, but that seems the most obvious and useful case.
'repeat' would simply repeat the same pattern of text distribution, starting
with the first flowRegion in the <flowText>, shifted down (or, in the text
progression direction) by the size of the bounding box. Or am I
misunderstanding this, and this is accounted for by 'maxOccurs="unbounded"'?


Line Breaking Within a Word
Though this may be outside the scope of this document, I would like to see
the introduction of a soft hyphen character/entity (a conditional hyphen);
from my reading of Unicode Standard Annex #14, it did not explicitly provide
a mechanism for a conditionally-rendering character/line-break opportunity.
In English, this is not such a problem, as most words are relatively short;
the problem is compounded in languages such as German. Without
hyphenated-word line-breaks, a given flowArea can be severely compromised in
its presentation quality; if a single word forms too long a text strip, the
entire flowArea may be bypassed. Absent an external resource for discovering
an appropriate place in which to break a word (such as a dictionary or a
language-specific algorithm), there is no way to determine where a word can
be broken without compromising semantics. An attentive author could provide
appropriate word-breaks if given the means to do so, via a conditional
hyphen; this soft hyphen would render (be visible) only when the word was
broken due to line constraints, and would not affect the programmatic
aspects of the word (that is, would not be copied/pasted, or taken into
account when the word was searched for).

CSS already provides the style attribute 'word-wrap' in HTML, with the
options of 'normal' or 'break-word'; however 'break-word' operates solely on
the fitting of single glyphs into a trailing space, with no consideration
for legibility or word integrity. That can sometimes be desirable, but I
would like SVG to include a word-wrap property, 'break-soft'. (Sounds rather
Shakespearean, no? :)



In addition, here were several grammatical mistakes thoughout the WD; I
realize that this is not  the final draft, but I thought I'd point out a
few, in case it would help:

2.2
"The child elements create a sequence of shapes in which the text content
for the parent flowText will be drawn into."
   should read:
"The child elements create a sequence of shapes *into* which the text
content for the parent flowText will be drawn." (or move "into" after
"drawn").


2.11.5
"Each Glyph Group has two extents calculated: is it's normal extent, and
it's last in text region extent. It's normal extent ..."
   should read:
"Each Glyph Group has two extents calculated: its normal extent, and its
last in text region extent. Its normal extent ..." (note the extraneous
"is")

(there are several other places in the WD where the contractions "it's" or
"who's" are used in place of the possessive "its" or "whose", which I won't
enumerate further.)

2.13
"If the text region removed had indent applied the indent is not applied to
the next text region in text progression direction it is simply ignored."
   could read, for clarity:
"If the text region removed had indent applied, the indent is simply
ignored, and is not applied to the next text region in text progression
direction."

Received on Wednesday, 30 April 2003 23:31:13 UTC