W3C home > Mailing lists > Public > www-svg@w3.org > November 2001

Re: Patterns and Clipping (Adobe SVG Plug-In)

From: Jeff Tupper / Pedagoguery Software Inc <tupper@peda.com>
Date: Mon, 5 Nov 2001 11:50:03 -0500
Message-Id: <a05100304b80c6dcab082@[192.168.1.2]>
To: www-svg@w3.org
Cc: Vincent Hardy <vincent.hardy@sun.com>, AndrewWatt2001@aol.com
Vincent and Andrew,

Thanks for the replies. In return:



At 9:53 AM +0100 11/5/01, Vincent Hardy wrote:
>I am not sure and I think it would be better for someone at Adobe
>to give an answer. We have done fairly extensive tests in Batik and
>I do not know whether or not Adobe implemented that area of the
>spec. Also, I think Adobe does not support external <use> (i.e.,
><use> elements with an xlink:href to an external document and
>all the Batik examples have an external <use>).

At 4:18 AM -0500 11/5/01, AndrewWatt2001@aol.com wrote:
>The documentation for Adobe SVG Viewer RC1 indicates that external 
>files are not supported for the <use> element.

I am not using extern files with <use>.

I define my pattern with <defs> just prior to using it (all in one file).

Does anyone have an example of an SVG file with a visible overflow 
pattern that works with the Adobe SVG plug-in?



At 9:53 AM +0100 11/5/01, Vincent Hardy wrote:
>Does your export work with Batik as you expected?

Batik generates the output I expect.



At 9:53 AM +0100 11/5/01, Vincent Hardy wrote:
>You tool seem really
>great and it would be nice to have the SVG export you want: looking
>at your product description, I understand why patterns with overflow
>are important to you.

Thanks. It would be nice if, with SVG, you could specify patterns 
whose generating translations are not perpendicular (although I may 
be able to work around it with skewed patterns). If overflow causes 
problems (or is not implemented) for common browsers, I could work 
around it, at the expense of slightly larger files.

I haven't looked through the SVG documentation much, but I do wonder 
if the output from using patterns with visible overflow is 
well-defined. (Is the order of rendering elements of a pattern 
defined? What should happen when an element of a pattern overlaps 
another instance of itself? Tess doesn't run into this as all of its 
elements are 100% opaque and are a single colour.)



Jeff
-- 
Received on Monday, 5 November 2001 11:50:24 GMT

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