W3C home > Mailing lists > Public > www-svg@w3.org > May 2003

Re: Comments on Text and Fonts in working draft of SVG 1.2

From: Thomas E Deweese <thomas.deweese@kodak.com>
Date: Mon, 5 May 2003 10:15:12 -0400
Message-ID: <16054.29168.126460.406580@frog.rl.kodak.com>
To: www-svg@w3.org
CC: doug@schepers.cc

>>>>> "DS" == Doug Schepers <doug@schepers.cc> writes:

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

    This is nice to hear.

DS> A very few things concerned me, or left me wondering how they were
DS> to be dealt with:
DS> Text-Anchor "Text progression direction" was mentioned several
DS> times, but I was unclear whether that applied only to BIDI, or
DS> included 'text-anchor: middle/end'. It shouldn't be much of an
DS> issue, but I thought it bore mentioning.

    Sorry, this should have been in the specification.  Flow text will
support CSS text-align (or the XSL equivalent) - right now we plan to
include a required implementation of full justification as well.  For
left/center/right (begin/middle/end) you will simply apportion the
space to the left/right or both sides of the text in each text region.
So if there are multiple text regions on a line each will be centered
separately (I'm not sure how you would do anything else).

    The current plan for full justification is to enable a tradeoff
between compression and expansion on the line.  Glyph _positions_ will
then be scaled to fit on the line (much like text-length in the
current SVG spec).  The required implementation will make no attempt
at features like white-space river reduction.  Some members have
expressed concern over implementation complexity so this feature (like
all other's I suppose) may not make it.

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

    The geometry in the flowRegion should be modifiable and the text
should reflow accordingly (the demo's of this are pretty cool:).  It
will likely not support implicit expansion (although versions of this
have also been discussed), the basic problem is this quickly gets into
dynamic page layout.  It is possible text overflow/underflow events
might be defined (no promises).

DS> Text-Overflow

DS> In 2.2 (flowRegion), y'all state "Once the text fills a shape it
DS> flows into the next shape." In the case where there is "leftover"
DS> text (text that remains unplaced after all textRegions have been
DS> filled), what happens to the remaining text? 

    Right now it is simply clipped.

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

    All good ideas but these are very much getting into dynamic page
layout.  Also it seems likely that for 'the real world' you need much
more complex behavior than is described above (I'm thinking something
along the lines of XSL's master pages etc).  Once again if we were to
define overflow/underflow events for dynamic user agents you might be
able to handle this reasonably yourself, however this is obviously
problematic for printing.  

    The Working Group is aware of these issues but right now is
leaning towards leaving the issues until after we have reproducible
text wrapping across viewers.

DS> Line Breaking Within a Word

DS> Though this may be outside the scope of this document, I would
DS> like to see the introduction of a soft hyphen character/entity (a
DS> conditional hyphen); from my reading of Unicode Standard Annex
DS> #14, it did not explicitly provide a mechanism for a
DS> conditionally-rendering character/line-break opportunity.  

    UAX#14 does support soft hyphens as well as zero width
space/joiners, and non-breaking spaces (and lots of other very cool
line breaking smarts). Implementations will be required to support the
conditional rendering of soft hyphen characters (this is one case
where the last on line length may be greater than the non-last on line
length), the issue of entities being supplied is another matter (and
one that is a bit complicated by the intent to move to schema).

DS> In English, this is not such a problem, as most words are
DS> relatively short; the problem is compounded in languages such as
DS> German. Without hyphenated-word line-breaks, a given flowArea can
DS> be severely compromised in its presentation quality; if a single
DS> word forms too long a text strip, the entire flowArea may be
DS> bypassed. Absent an external resource for discovering an
DS> appropriate place in which to break a word (such as a dictionary
DS> or a language-specific algorithm), there is no way to determine
DS> where a word can be broken without compromising semantics. An
DS> attentive author could provide appropriate word-breaks if given
DS> the means to do so, via a conditional hyphen; this soft hyphen
DS> would render (be visible) only when the word was broken due to
DS> line constraints, and would not affect the programmatic aspects of
DS> the word (that is, would not be copied/pasted, or taken into
DS> account when the word was searched for).

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

    I think we will only allow soft breaking (at least initially).

    One other comment a strong desire here is to specify the alg. used
to a point where authors can be given a reasonable level of certainty
that under the right circumstances (using SVG Fonts for example) they
will get identical word breaking across SVG user agents.  It is
possible that like the textPath with it's 'spacing' attribute there
may also be an 'enhanced' layout mode where viewers might use a local
soft hyphen dictionary or WS river reduction alg to do better full
justification but all viewers will be required to implement the base
alg. (to conform).
Received on Monday, 5 May 2003 10:17:02 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 8 March 2017 09:46:56 UTC