Re: textPath method="stretch"

I agree with David - these are very persuasive demonstrations.

The tricky part will be working out how to define the syntax for such effects. 

Dean

On 12/07/2011, at 6:50 AM, Israel Eisenberg wrote:

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