W3C home > Mailing lists > Public > www-svg@w3.org > July 2011

Re: textPath method="stretch"

From: Israel Eisenberg <owlgems@yahoo.com>
Date: Thu, 14 Jul 2011 14:17:49 -0700 (PDT)
Message-ID: <1310678269.31501.YahooMailClassic@web120715.mail.ne1.yahoo.com>
To: Erik Dahlstrom <ed@opera.com>, Dean Jackson <dino@apple.com>
Cc: www-svg <www-svg@w3.org>
Hi Eric,

>Wednesday, July 13, 2011
> http://owl3d.com/svg/tests/boundText/corner_in_out.svg

>In this example, I suspect some would want the effect of a fan, such
>that the glyph is folded over the cusp in a continous manner similar
>to how linejoin=round works.

You mean like this:

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

>...Perhaps respecting the stroke-linejoin
>for how to warp the glyph in this case would be interesting?

Definitely interesting and much desired if you ask me, but I think the decision 
to require it from UA's should be consulted first with the implementers.
As the linejoin algorithm already handles offset-curves (stroke edges)
it might be more simple than I think, but other than such assumption 
I'm not qualified to give an opinion simply because I'm not familiar with 
the said algorithm and I wouldn't call the way I produced the above demo
an algorithm but rather a single case solution.
In any event, considering the efforts I have invested in the production of
the above demo, if I'm the one to ask the implementer, just for precaution, 
I would make sure first that there aren't any rough/sharp objects around.

Hello Dean:
>I agree with David - these are very persuasive demonstrations.

Assuming 'persuasive' is kind of a compliment, thanks, and of course thanks 
to David for his kind words.

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

Agree. I already abandoned the naive idea that I can get away with just correcting
the algorithm description. 
Nevertheless, as it requires me for a more elaborate response than a simple demo,
and as I'm on my way back to the wild (literally :)) I will postpone my response 
to when I'm back to civilization.
In any event, my answer might contain some x-rated material like:

For the method='stretch' 'Text on a path layout rules' must be ignored.
(I don't know about you, but I already feel great relief).
Considering about half of these rules describe how to calculate a single point 
which is practically worthless for offset-mapping, this might not be as horrible 
as it may look at first glance. 

Guidelines: 
1) Make sure the offset-mapping operates at a minimum on the glyph 'd' 
    as if it was a 'd' of a path.
    Anything which has any chance of interfering with this core must be ignored.

2) Try to provide the designer maximum artistic features without violating (1).

Set properly, definition should make both the implementer and the designer happy 
(with precedence to the implementer) and any JS Ninja assassin frustrated.

(I guess last phrase is good for any definition in the spec)

Best regards,
Israel
Received on Thursday, 14 July 2011 21:18:20 GMT

This archive was generated by hypermail 2.3.1 : Friday, 8 March 2013 15:54:48 GMT