Re: textPath method="stretch"

Hello Eric,

Apologies for late response, computer and/or Internet connection are not always 
available to me as a result of my line of work.

Before I even start, somebody brought to my attention that offset-mapping is also 
a parallax-mapping so I must clarify:

Whatever I described as offset-mapping is *not* parallax-mapping

http://en.wikipedia.org/wiki/Parallax_mapping

What I meant could also be described as horizontally slicing the text and making each slice
a parallel-curve (offset-curve) of the textPath with y distance from the curve as its y distance 
from the text base-line

http://en.wikipedia.org/wiki/Parallel_curve

In any case, I will still continue calling it offset-mapping.


>Is it clear how to combine method=stretch and rotate? Opera currently treats it as rotating the possibly warped glyph, 
>but another interpretation could be to rotate and then warp the glyph.

I think rules must be set as clear as to not leave any space for such difference of opinions.
Different application order of an offset-mapping combo create significantly different results 
in most cases, hence clear decisive rules are essential.

Seems to me like the nesting should dictate the order of application with 'nearest ancestor has precedence'.
Since the text element has its own rotate and shifts in addition to those in the tSpan, and since the textPath,
which carries the stretch, is always sandwiched between them, it gives the designer great degree of freedom 
to create some exotic combinations like 'rotate stretch rotate'.
Nevertheless, if this suggestion will be accepted, it must be thoroughly explained in the spec in order to prevent 
UA's from incorrectly applying text element rotate/shifts prior to stretch.


Following demo shows results of different application order of rotate and offset-map to 'A'.
The animation performs final stage of the cycle 'rotate(-60) then stretch then rotate(42.2)'. 
Note that the angle of the final rotate, which sets 'A' back on the curve, is not a simple 
negative of the first rotate. Reason is that the offset-mapping is changing the rotated position 
of the right leg of A thus, in order to put it back on the curve, a new angle must be calculated.

http://owl3d.com/svg/tests/boundText/stretch_rotate.svg

>I'd be interested in seeing some more tricky cases, such as a textpath with sharp corners 
>(showing glyphs both on the "inside" and "outside" of the corner) 
>or a path with a loop such that the warped glyph would intersect itself.

http://owl3d.com/svg/tests/boundText/corner_in_out.svg
http://owl3d.com/svg/tests/boundText/single_glyph_loop.svg

The 'under' position in the loop demo looks kind of weird not because there is any problem with the 
stretch but because of an issue I have long prepared a proposal for SVG2, but as we bounce to it now,
it might be a good opportunity to make the proposal now and maybe even insert it into 1.1 recommendation.

Apparently there are cases where the fill is not painted neither with 'evenodd' nor with 'nonzero'. 
No need to elaborate on the Math involved, you can simply observe it in the above demo or with 
a more simple demo of a pseudo Calligraphy-pen (which is where I first encountered it):

http://owl3d.com/svg/tests/boundText/callipen_fill-rule.svg

My proposal is for additional value for the 'fill-rule' attribute - 'always'.
The meaning is simple: Paint the fill. Bypass the test for 'evenodd' or 'nonzero' with a 'true'.
As the current situation forces the UA to perform at least one check for every fill it paints,
assigning a value of 'always' will also have an effect of faster rendering.
Which is a good reason to make this value the default, but I guess for back compatibility, 
we should keep the current default.

If you'd be interested in seeing more demos, do not hesitate to ask.

Best regards, 
Israel


--- On Wed, 7/6/11, Erik Dahlstrom <ed@opera.com> wrote:

From: Erik Dahlstrom <ed@opera.com>
Subject: Re: textPath method="stretch"
To: "www-svg" <www-svg@w3.org>, "Israel Eisenberg" <owlgems@yahoo.com>
Date: Wednesday, July 6, 2011, 3:07 PM

On Tue, 05 Jul 2011 15:43:56 +0200, Israel Eisenberg <owlgems@yahoo.com> wrote:

...
> "align" treat glyphs like  solids, "stretch" should treat glyphs like rubber.

That's what I would expect too.

> Whatever "align" is doing to the glyph-midline
> <http://www.w3.org/TR/SVG/text.html#GlyphMidline>
> "stretch" should apply to *all* the glyph vertical lines.
> In spec words: "all points will be adjusted to be along the perpendicular vectors from the path,
> preserving vertical distance from the path."

Is it clear how to combine method=stretch and rotate? Opera currently treats it as rotating the possibly warped glyph, but another interpretation could be to rotate and then warp the glyph.

> Last interpretation practically maps horizontal straight lines to offset curves of the textPath
> hence will be referenced as "offset-mapping". In particular, base-lines of the glyphs are
> mapped to the textPath skeleton.
> 
> The problem: three different looking implementations, all confirm to the spec.

Right. The proposal to clear up the requirements sounds good to me.

...
> Personally, I'm convinced that the meaning of the spec is offset-mapping

As an author of svg content, that is the interpretation I would prefer too.

...
> Cameron:
>> I like and want to have support for this effect...I’d like to see someone prototype it in JavaScript...
> (To be accurate, this comment is on dual-curve-fitting, which demos follow later.)

I'd be interested in seeing some more tricky cases, such as a textpath with sharp corners (showing glyphs both on the "inside" and "outside" of the corner) or a path with a loop such that the warped glyph would intersect itself.

Cheers
--Erik Dahlstrom, Core Technology Developer, Opera Software
Co-Chair, W3C SVG Working Group
Personal blog: http://my.opera.com/macdev_ed