Re: stroke=gradient for lines or horizontal paths

As well as stroke-width, stroke-linecap and stroke-linejoin contribute 
to the "visual" bounding box.

ASV doesn't include stroke-linecap in David's example (slightly modified 
below with a much wider stroke).

<svg xmlns="http://www.w3.org/2000/svg" width="100%"
xmlns:xlink="http://www.w3.org/1999/xlink"
  viewBox="0 0 100 100" preserveAspectRatio="none" stroke-linecap="round"
 >
<linearGradient id="g">
<stop offset="0" stop-color="#870"/>
<stop offset=".2" stop-color="#520"/>
<stop offset=".4" stop-color="#000"/>
<stop offset=".6" stop-color="#840"/>
<stop offset=".8" stop-color="#210"/>
<stop offset="1" stop-color="#832"/>
</linearGradient>

<line x1="33" x2="67" y1="22" y2="22" stroke-width="40" stroke="url(#g)" />
<line x1="33" x2="67" y1="45" y2="45" stroke-width="40" stroke="red" />
<path d="M 33 68 67 68.01" stroke-width="40" stroke="url(#g)" />
<path d="M 33 81 67 81" stroke-width="40" stroke="red" />
<path d="M 33 84 67 84" stroke-width="40" stroke="url(#g)" />
</svg>

Ken

On 13/07/2011 5:03 PM, Alex Danilo wrote:
> Hi Andreas&  David,
>
> 	Yes I agree this is non-intuitive.
>
> 	Our implementation does the wrong thing in this
> case and _does_ produce the gradient the same as ASV.
>
> 	The object bounding box in this case has 0 size
> as per what's returned from getBBox(). But of course the
> actual physical extent of the stroked object has a size
> and that's what ASV and we use as the bounding box for
> the gradient fill.
>
> 	Putting my author hat on, I think the current
> definition is bad since it confuses people. It seems
> pretty intuitive to expect that the bounding box of
> something you can see is actually the bounding box
> used for these calculations.
>
> 	Which of course begs the question - how do you get
> the bounding box of a stroked object through the DOM?
>
> Alex
>
> --Original Message--:
>> Hi David,
>>
>> I learned about this limitation a few years ago when I programmed a
>> little color picker with sliders that had gradients on a line. I had to
>> change to<rect/>  elements instead of<line/>  elements for this purpose.
>>
>> I think this is a ugly limitation in SVG, and although Rob is right
>> that the browsers are ok (those<line/>  elements do not establish a
>> bounding box), due to the spec, it is hard to explain to users that one
>> cannot easily have gradients on vertical or horizontal lines.
>>
>> I am not sure if the SVG WG is able to fix this issue?
>>
>> Andreas
>>
>> On Tue, 12 Jul 2011 20:04:34 -0400, David Dailey wrote:
>>> Hi folks,
>>>
>>> In the relatively simple file at
>>> http://srufaculty.sru.edu/david.dailey/svg/text/gradientLines.svg [1]
>>> (source code included below), a series of five nearly horizontal
>>> lines
>>> is drawn using either  or  . In three cases the stroke value is a
>>> pointer to a gradient. In one of those cases, the line is drawn to be
>>> just a tad off of true horizontal.
>>>
>>> The following browsers fail to properly portray the gradient in the
>>> two cases that a truly horizontal line is stroked by a gradient:
>>>
>>> Opera 11.5
>>>
>>> Firefox 5
>>>
>>> IE 9
>>>
>>> Chrome
>>>
>>> Safari
>>>
>>> Safari and FF actually draw five lines (the others draw only three),
>>> but the gradients are ignored.
>>>
>>> Sigh… it looks like ASV passes the test though, so we can't hardly
>>> call it an "acid test" now can we since ASV was born before Hixie?
>>>
>>> Actually, since so many browsers seem to misfire here, perhaps the
>>> spec should say something like "lines may be stroked by gradients
>>> even
>>> when they are horizontal."
>>>
>>> Cheers
>>>
>>> David (whose reason for creating this example may be made clearer by
>>> my next post)
>>>
>>> --------------source code---------------
>>>
>>>
>>>
>>> Links:
>>> ------
>>> [1] http://srufaculty.sru.edu/david.dailey/svg/text/gradientLines.svg
>>
>> --
>> --
>> Andreas Neumann
>> Böschacherstrasse 10A
>> 8624 Grüt (Gossau ZH)
>> Switzerland
>>
>>
>>
>
>
>

Received on Wednesday, 13 July 2011 07:55:07 UTC