Re: [SVGMobile12] Comments: Text

On Thursday, May 19, 2005, 3:02:48 AM, Tor wrote:

TR> 10.2

TR> "It is possible to apply a gradient to text. ... object bounding box
TR> units are computed relative to the entire 'test' element in all
TR> cases..."

TR> Why have text behave different that other geometry (11.12)?

It doesn't. Text behaves the same as other graphical objects. For
example, if you have a path element which draws multiple disjoint
shapes, then a gradient applies to the entire bounding box of the path.
Similarly for text. We mention this since we have seen the occasional
implementor try to do individual gradients per glyph, so we are just
trying to head them off from doing that.

TR> 10.6.1

TR> "Many of the features here go beyond the functionality provided by the 
TR> elements in this profile..."

TR> This "tiny" specification is almost 400 pages - leave out verbarge not 
TR> associated with the specification in question.

Fair point, although "many" was incorrect also.

However, we did still want to describe text in a direction-indendent
manner (start-end rather than left-right; before-after instead of
top-bottom) because Tiny does support bidirectional text and because the
same definitions will also apply to Full, which does support vertical
writing in addition.

We found a couple of things specifically related to vertical text that we
have now pulled, but a review of that section in light of your comment
found that there was in fact very little that goes beyond Tiny 1.2.

We have also removed the scary statement about "many of the features"
and instead, explained why text layout uses directionally neutral terms.

TR> 10.11

TR> <textArea> needs an example or two.

Yes it did. We have added them.

TR> 10.11.1

TR> "For cases where box model layout is required, it is suggest that a 
TR> 'foreignObject'..."

TR> Section 10.1 says that "the exact semantics of this approach are not
TR> completely defined."

Yes, we agree that makes it sound as if using a foreignObject
automatically gets you a box model. It doesn't - its merely an
extensibility point to hand off to some non-SVG layout. That might be
box model, or it might be MathML layout, or it might be 3D, or whatever.
The SVG renderer itself does not handle it, is the point.

Other specifications or profiles (such as those from the CDF WG) will
define conformance requirements

We were mainly trying to say "this does not overlap with, or replace CSS
box-model layout" but maybe that way of saying it was confusing. On
reflection, to deal with your comment, we struck the sentence "For cases
where box model layout is required, it is suggested that a
'foreignObject' element be used." and will let the CDF specifications
define conformance profiles where the foreignObject hands off to a
box-model renderer.


TR> 10.11.1

TR> "The layout of wrapped text is user agent dependent..."

TR> Not good for interoperability, especially in light of having SVG defined
TR> fonts.

That was exactly our reasoning the first time around; we thought that
having SVG fonts meant that the layout would be deterministic. It
commonly is, but isn't in the general case. In SVG Full, where text can
be placed in an area of arbitrary shape, very small differences in curve
flattening  between implementations (of the order of 100th of a pixel or
less) while not affecting the rendering of that path, would affect
intersection calculations between a glyph and that shape.)

However, there is a more important reason why we switched to having two
layout models and having a totally implementation-dependent one be the
default. This came from the I18n WG review of the previous Last Call
draft. For some languages, such as Thai, there are no spaces between
words. Line breaking is done by text lookup in a dictionary. Different
implementations have different sizes of dictionary. We did not want to
preclude an implementation doing that sort of line breaking - equally,
for Tiny, we did not want to require all implementations to have a Thai
dictionary.

Similarly for Japanese, there are line breaking rules called kinsoku
(not just one set of rules, either) and again we did not want to
preclude their use.

So, reluctantly, we have had to accept implementation-dependent line
breaking.

This does give a side effect that in a combined SVG and XSL
implementation, for example, a single line wrapping layout
engine can be shared. Similarly for a combined SVG and CSS
implementation, such as one that does CDF XHTML+SVG, a single line
breaking engine can be shared.

TR>  Perhaps a "wrapping = auto | exact" attribute is needed, in the 
TR> same fashion that textPath in SVG full has a spacing attribute?

That option was considered, but we became aware that "exact" would not
in fact be exact.

TR> 10.12

TR> It seems one of the natural uses that editable text fields might be put 
TR> to is input fields, but there seems to be no way to control the "width" 
TR> of a field or clip over-long content (as SVGT lacks both <clipPath> and 
TR> nested <svg>).

With textArea, text which does not fit is not displayed. So it is not
clipped, it is just not laid out. The width can be controlled, however.

You are correct that to implement a rectangular scrolling text area
which displays a portion of a fixed-with, conceptually infinite height
text area displaying inside a fixed width and height region, clipping
(eith er the clip and overflow properties, or clipPath) would be
required and this is not available in Tiny 1.2

TR> 10.12.1

TR> "For WYSIWYG editing the following..."

TR> What should happen if current point is moved to an area not visible 
TR> (overlapping geometry, text running outside the outer <svg>, etc)?






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

Received on Monday, 10 October 2005 18:53:02 UTC