Re: So long as we're tidying up text

Hi David,

On 13/07/11 1:54 PM, David Dailey wrote:
> Take a look at this screen shot of five modern browsers rendering a
> relatively simple SVG file with one text tag having various text
> effects applied:
>
> http://srufaculty.sru.edu/david.dailey/svg/text/FancyTextBrowsers.jpg
>
>
>
I must surely get some sort of prize for maximizing the ratio of
> Sum(BrowserDiscrepancies) / SVGFileSize . The browsers depicted are
> (clockwise from upper left):
>
> Opera, Firefox, Chrome, IE9, and Safari.

Indeed, nice example. :)

> The raw file (barebones version ) is at
> http://srufaculty.sru.edu/david.dailey/svg/text/textfeatures.svg
>
> (Though the one depicted in the screen shots is actually
> http://srufaculty.sru.edu/david.dailey/svg/text/textplay.svg . )
>
> I think much of what we’re seeing here stems from lack of
> specification rather than bugs, though bugs appear to be ample as
> well.
>
> The operative text tag reads as follows:
>
> <text id="T" fill="none" stroke-width="4" stroke="url(#g)"
> stroke-opacity="1"
>
> font-family="serif" font-stretch="ultra-expanded"
> stroke-dasharray="10 5" rotate="-25 -20 -15 -10 -5 0 5 10 15 20"
>
> textLength="90" lengthAdjust="spacingAndGlyphs" font-style="oblique"
> text-decoration="overline"
>
> font-size="50" x="5" y="65%" font-weight="bold">
>
> Conclusions:
>
> 1.Firefox doesn’t yet handle overline or textLength="90"
> lengthAdjust="spacingAndGlyphs" . I am pretty confident that these
> are known bugs and not surprises. textLength, though is rather
> important since it seems to be the only way (short of converting
> text to paths) of making sure that text will occupy roughly the same
> footprint on different sized devices.

Indeed, known bugs / lack of implementation.

https://bugzilla.mozilla.org/show_bug.cgi?id=317196
https://bugzilla.mozilla.org/show_bug.cgi?id=569722

> 2.The browsers don’t seem to agree on what units to use (pixels or
> viewport) for dash array when applied to text.

There is definitely an issue with stroking text in Firefox.  For
example, try viewing

   http://people.mozilla.org/~cmccormack/tests/text-stroke.svg

and zooming in and out of the page (with Ctrl + or Cmd +).  Notice how
the stroke of the <rect> zooms normally, but the <text>'s changes.

Filed: https://bugzilla.mozilla.org/show_bug.cgi?id=676178

> 3.The browsers don’t seem to agree on whether overline and glyphs
> use the same dash-array units or not.

I think the dash-array units should be the same for both, and should be
in the coordinate system that the <text> is in.

> 4.The extent of the spread of the gradient through the text seems in
> some cases to be based on total cumulative path length of the glyphs
> rather than on each glyphs own horizontal size. Note the difference
> in gradient spread across the four browsers where we can see the
> completion. IE hits the final stop at about .8, while Opera does the
> expected thing at about .9; Chrome hits it at about .1 and Safari
> only reaches the final stop color in its overline. Only Opera seems
> to keep the gradients of the overline and the text in sync.

Yes, looks like Opera's behaviour is correct there.  I think Firefox's
is too, if you modify the document to show more of the text.

> 5.Commencement values of the dash-array seem to be differently
> calculated for different glyphs than for others in some browsers.

That's something we noticed too while playing around with some text
during the F2F.  I suspect this is not defined very well, and also
depends entirely on what font is actually selected.

> 6.The overline is discontiguous in most browsers.
>
> 7.Rotations of the overline follow rotations of the glyphs in most
> browsers. Opera does it as I would expect.

That's undefined too, but I agree that Opera's behaviour of not having
the glyph rotation affect the text decoration is reasonable.  (If you
want decorations to follow the rotation of text, you can rotate the
<text> itself.)

The fact that the decoration is discontiguous just seems to be because
it follows the rotation of the glyph in the other browsers.

> 8.The baseline of the phrase seems to droop from left to right in
> some browsers. It appears to be nonlinear in others. The simpler
> file (with the guidelines at the bottom make this clearer).

I wonder if that is due to a different position being chose around which 
the rotation is done?  The spec is clear that it should be done around 
the "current text position", which seems to support the drooping effect.

> 9.Some browsers allow the rotated glyphs to begin outside the
> drawing area, others interpret textLength and spacingandGlyphs
> obviously differently.

I think if you have

   <svg xmlns="http://www.w3.org/2000/svg" width="100" height="100">
     <text x="0" y="50" rotate="-90">D</text>
   </svg>

then most or all of the D should not be visible as it has been rotated 
around the point (0,50).

I feel that adjustments due to textLength/lengthAdjust should just scale 
and reposition the computed positions for each glyph such that the 
position of the first glyph is still at the initial x position and the 
position the last glyph plus its (scaled) advance is the initial x 
position plus the textLength.

> Hope this adds more clarity than confusion, as that is the goal.

:)

Received on Wednesday, 3 August 2011 04:47:23 UTC