Re: Comments on textArea vs flowText

On Friday, April 29, 2005, 3:20:18 PM, Thomas wrote:

TD> Hi all,

TD> I am deeply concerned about the changes to flowing text that the SVG
TD> 1.2 Tiny Last Call introduces. This concern lies on several fronts.
TD> The biggest concern for me, as has been echoed in other people, is
TD> the possible loss of functionality.

There were good and useful comments about the old flowText that the new
spec does address. Primarily from the I18N folks but also the current
text is much easier fro people like Opera and Mozilla to implement, as
they can re-use their layout engines.

TD> Going in another direction, one of the few objections to the old
TD> text wrapping proposal that I considered legitimate was the
TD> possibility that existing XHTML/CSS text layout engines might find
TD> the layout model of flowText incompatible (something I didn't agree
TD> with, however it was a legitimate concern).

The main thing that has been lost is the promise of repeatable
linebreaks. But as we discovered, that was a false promise anyway.
Comparing two floats is not going to be interoperable. Miniscule
(sub-one-thousandth of a pixel) differences in the intersection of the
glyph outline with the shape outline, caused for example by different
curve tessellation algorithms, would cause an entire word to either be
on the same line or be on the next line.

TD> Now I know that members of the WG have "promised" that almost
TD> all of the functionality will be added back for the full
TD> release, but this is in my opinion unacceptable.  What does
TD> 'almost' mean?  Can we have a concrete proposal?

The functionality of the new spec is largely the same as the
old one except:

- implementations can uses whatever I18N libraries they have to do the
best linebreaking they can (this is obviously an improvement)

- we don't promise that all implementations will break the same way(this
is sad, but then again it wasn't true before)

- it re-uses tref etc (that is better)

- some names have been changed

TD> Implementors and users have been able to look at implement and use
TD> the flowText element as specified by the WG in the last several
TD> releases of the specification (covering several years). I can count
TD> at least four fairly complete implementations of the feature (ASV 6,
TD> Batik, InkScape and BitFlash).

The code to implement that is largely reuseable. The changes mainly mean
that other implementors - of CSS rendering engines, or XSL FO
implementors - get to re-use their line-breaking algorithms when
implementing the new ttextArea stuff, rather than being forced to use a
whole new duplicate svg-specific set.

TD> So far the major feature that was listed as being dropped was the
TD> notion of paragraphs, on the grounds that this violates some taboo
TD> on "semantics". However, I would contend that this is _required_ for
TD> proper handling of international text. The first step in UAX-9
TD> (http://www.unicode.org/unicode/reports/tr9/) is splitting the text
TD> into paragraphs so the default embedding level can be determined.

Right. And block level containers like that are retained, for the
reasons you give. Although in Tiny 1.2, there is only one such
container; Full allows multiple ones.

TD> I am not sure how the SVG WG anticipates user agents to implement
TD> properties like 'text-align' properly without a proper embedding
TD> level. However, since I can't find any mention of text-align in the
TD> Tiny spec perhaps this feature was also dropped?

Its called display-align, and takes the values (from XSL, directionally
neutral and thus, also applicable to vertical text in Full):

  'auto' | 'before' | 'center' | 'after' | 'inherit'

TD> Is there a missing description of how text-anchor is supposed to
TD> apply to blocks?

text-anchor is for text defined by an anchored point position, like a text
element; it is inapplicable to blocks.

TD>     This change would probably not be as disappointing if it
TD> weren't for the fact that flowText was probably the most widely
TD> implemented of all the SVG 1.2 features.  A lot of implementation
TD> and usage experience was developed for flowText, much of which
TD> will need to be redeveloped for textArea.

In fact, we believe that a lot of that experience will be directly
useable.

TD> I'm especially concerned about the usage experience since that
TD> necessarily lags implementation, and in my opinion a number of
TD> important features have been removed that will make the usage of
TD> textArea in the real world much more difficult than flowText.

We don't believe that to be the case. However, all of your original
comments from this email have been logged into a 1.2 Full issue (since
the majority relate to 1.2 Full, rather than Tiny) so that we can be
sure to have not missed any of the points you made.

We hope that this explanation enables you to feel more comfortable about
the changes introduced for Tiny. Please let us know shortly if this
explanation does not satisfy that part of your comment that relates to
Tiny 1.2.



-- 
 Chris Lilley                    mailto:chris@w3.org
 Chair, W3C SVG Working Group
 W3C Graphics Activity Lead
 Co-Chair, W3C Hypertext CG

Received on Tuesday, 8 November 2005 14:02:00 UTC