Re: Comments on textArea vs flowText

Hi Chris,

www-svg-request@w3.org wrote on 11/08/2005 09:01:56 AM:

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

   I disagree with this, please log my issues against Tiny. 
I consider all of the properties mentioned important for Tiny:
        text-align
        margin (in some form)
        indent
        line-height (or update line-increment to use quantities used
                       in the CSS line-height property).

   I also consider support for multiple paragraphs essential
for any text flow system (Tiny or otherwise).

   I consider the ability to separate the layout regions
from the text content equally essential for a text layout system
(especially one where you can't predict ahead of time where word
breaks occur).

   No baseline for word breaking (as it is a compliant implementation
could choose to do no word breaking). I would suggest requiring respect
for the unicode chars 'space', ZWJ, ZWS, NBSP & soft hyphen.

   A draft/sketch of how block/paragraphs will be added.
   A draft/sketch of how multiple flow regions will be added.
   A draft/sketch of how exclude regions will be added.

   I know that you consider the last three 'Full' issues but
I think the textArea element with x/y/width/height attributes
is an architectural dead-end.  I don't see how to gracefully
grow it to support multiple regions and paragraphs cleanly.

   Simply adding xlink:href is really ugly because you will 
be left with these residual x/y/width/height attributes. 
Adding a tPara/tBlock would also be ugly since you now have this 
strange situation with content outside a tPara/tBlock
(does it define a block or not).

---

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

   I consider this a straw man as making it easier for Opera/Mozilla was 
accomplished by simply removing any requirements on the text break & 
layout 
engines, something that is just as easy to do with the previous 
specification
(in fact virtually all of the text on layout continues to exist in the 
current
draft, it's just optional instead of normative). I am also surprised to 
see this comment in your response when you simply deleted my comments 
where I pointed out that in some ways the current specification makes 
reuse more difficult.

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

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

[Deleted text restored]

        However, it seems quite clear to me that the new "simplified" 
        line height calculation (the 'line-increment' property) is a 
        significant step in the wrong direction. While it may be _very_ 
        slightly simpler it is fairly divergent from the CSS line-height 
        property.  The ironic bit is that this is just about the only 
        piece of layout that implementations are required to follow.

  Is there some response on why the existing CSS property line-height
isn't used.  Or why the line-increment property isn't at least defined
in similar terms to the line-height property, rather than defining it
using new quantities?  This would allow implementations to leverage
existing CSS layout engines, a stated goal of the rearchitecture.

> The main thing that has been lost is the promise of repeatable
> linebreaks.

   I would argue a lot more has been lost so far (margins, indent,
text-align), support for multiple paragraphs, separation of layout
area and text content, the potential for out of order rendering, etc...

   All of these except for the out of order rendering (flowRef) are
significant losses to the utility of flowing text in Tiny.  Also the 
lack of any sort of baseline for word wrap will likely make for 
significant cross UA issues.  We probably should also mention the
ability to include arbitrary SVG in the flowText as a loss (although
not one I am particularly sad to see go, but it should at least be
listed).

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

   Yes, I was one of the first to raise this issue with the WG.
There is the potential to integerize the operations involved (your 
response as I recall) but in all likelihood I agree it isn't worth 
while. Anyway, this has little to do with my concerns about the
textArea (which are more with the model and lack of needed
property support). The way things are currently written I would
expect lots of implementations to go 'extend' the flow text with
additional properties from CSS, making cross UA interoperability
almost impossible.

   BTW curve tessellation was never involved in the previous 
specification, it was line/curve intersection (solving a cubic), 
min/max calcs (solving a quadradic), and summing font metrics.

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

   Except when the implementation doesn't have at least a TR14 
compliant line breaker (my guess, this will be most implementations).
I don't actually care so much about this, but I think it's a mistake
for the WG not to set a baseline (even in Western centric one).  I 
always considered the TR14 requirement in previous drafts to be a 
minimal requirement.

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

   - Important properties have been dropped. 

   - You can no longer have multiple 'paragraphs'.

   - You can no longer specify a list of rects that text
     will flow from one to another, you must know ahead 
     of time what text will fit in each rect which
     is especially problematic given that one doesn't 
     know where/how text will wrap/break (even more so 
     now than before).
 
> 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.

   So there is no need for multiple paragraphs in Tiny?
Did people feel that the code to support multiple paragraphs
was really that onerous?

   What character set's the progression direction for text?
The first character of <text> or the first character of textArea?

> 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'

   I was aware of display-align, that is for block progression (vertical)
alignment, I am asking about text-align (also from XSL with direction
neutral values) which controls inline alignment (i.e. horizontal 
alignment for western languages).  I would guess that this is used/needed
quite a bit more than vertical (although I think both are important).

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

   I was grasping at straws since I found it hard to believe that
the WG would overlook something as basic as "horizontal" alignment
yet provide a detailed description of how to accomplish "vertical" 
alignment. This makes me one wonder what else may have been 
inadvertently(?) dropped/omitted from the new spec.

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

   As one of those people with experience, I feel that my 
experience is almost worthless with the new textArea, as most
of the features/techniques I used to do useful things with 
flowText appear to have been dropped.  Since the WG has thus
far refused to give any hint as to how these things will be added
for Full, I am at a loss how to proceed.

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

   This does not satisfy me, I have yet to receive a reasonable
explanation of why flowText was dropped in favor of textArea.  I
feel that textArea is not as well thought out as flowText was
(especially as a basis for moving forward into Full).  It also has
some structural flaws (multiple region support, and paragraphs 
being the most notable),  I also think that the combination of
flowing and normal text in the same stream needs to be clarified 
further (how is progression direction set primarily).

Received on Wednesday, 16 November 2005 13:00:20 UTC