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

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

It doesn't. For example, if I have a path element which has multiple
subpaths that trace out disjoint shapes, then a gradient with
gradientUnits=objectBoundingBox is computed relative to the entire path
element. Similarly with text, the bounding box is the entire text
element.

We noted that occasionally, implementors would put the gradient on each
individual character, and therefore added this warning note.

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.

OK. We reviewed it, and in fact 'many' overstates the case. There were
some things relative to vertical text, that we have since removed. in
some cases though , its easier to give a more general description,
place limitations on it for Tiny, and lift those limitations in full
than it is to describe what Tiny does and then state that Full has an
entirely different model.

TR> 10.11

TR> <textArea> needs an example or two.

Yes it does, I have an action item to produce some examples.

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

Right. So for example a foreignObject could also be used for something
that uses a non-box model (like MathML which uses struts and springs, or
X3D which  uses a 3D coordinate system). So, its not trying to say that
foreignObject always produces a box model. Rather, its saying that if
you want some layout model other than the SVG one, for elements not in
the SVG namespace, then use a foreignObject.

Having a foreignObject point to XHTML with a CSS style sheet would, for
visual media, give a box model.

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 is what we thought too, and the previous draft tried hard to make
this not be user agent defined. However, there are cases where it will
be - for example, the tesselation of a curve into straight line segments
will be implementation dependent and could easily have differences of
1/100th of a pixel between implementations. such differences, while
hardly affecting the appearance of eachglyph, could affect whether a
given glyph intersects the side bound of a wrapped text area or not.

More seriously, the I18N group told us that the previous approach
precluded good but user-agent dependent layout for some languages 9eg
Thai, which does word breaking based on a dictionary. The size and
content of a Thai dictionary is outside the scope of the SVG spec.

So currently we have the default layout be user agent dependent -
thatgets youtext which wraps, for example in a call-out box on a
diagram, but does not get you reproducibility. And we have a mode which
uses the algorithm in the spec, which gives you more reproducibility (eg
for more graphics intensive material) but may look awkward for certain
languages.


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

Yes, exactly.

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

If wrapped text does not fit in the space, the remaining portion it is
not layed out. So it does not appear, but also since it does not
generate geometry, it does not need to be clipped.

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

On your last point, we are looking at rewording where the cursor
position is defined in terms of a logical position in the backing store
rather than an on-screen cursor position.




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

Received on Monday, 22 August 2005 07:04:28 UTC