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

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

From: Thomas E Deweese <thomas.deweese@kodak.com>
Date: Wed, 7 Nov 2001 15:43:36 -0500
Message-ID: <15337.40184.37489.975581@gargle.gargle.HOWL>
To: Jeff Tupper / Pedagoguery Software Inc <tupper@peda.com>
Cc: thomas.deweese@kodak.com, www-svg@w3.org
>>>>> "JT" == Jeff Tupper / Pedagoguery Software Inc <tupper@peda.com> writes:

JT> Thanks for your comments.
>> This is due to an error in the SVG.  In looking at the SVG it
>> appears that the pattern consists of a yellow triangle with a pink
>> triangle drawn inside of it.  In reality the pattern is a yellow
>> triangle with a slightly smaller pink triangle drawn one pattern
>> tile height below the yellow triangle (see attached PNG).

JT> I intentionally placed the triangles apart in this manner; that
JT> was not an error.

JT> It seems we have a differing interpretation of what an SVG pattern
JT> is. We seem to place the iteration at different levels. I was
JT> thinking that all of the yellow triangles would be drawn and then
JT> all of the pink ones would be drawn. (This way, rendering order
JT> does not play a role between different elements and the 'depth'
JT> ordering between elements is preserved.) 

    This may make sense for your simple example but when the graphics
to be patterned is more complex it starts to break down.  What
happens when the patterned element is a complex tree? Do a depth first
traversal?  What if there is group opacity on part of the tree?

    No, Ideally think the only thing that makes sense given the SVG
rendering model is to have the children of the pattern element be as
if all the children are drawn as a whole entity, then translate and

JT> As was discussed earlier, there also seems to be a common
JT> assumption about the rendering order that I wasn't aware of as
JT> well. It seems that the SVG document should include some
JT> clarifying text about patterns.

    An issue has been raised in the working group to provide such a

JT> I did try the file again, with the pink triangle placed 'above'
JT> (lesser y value than) the yellow and got the result I expected. So
JT> it seems that I can generate patterns as long as, each time I add
JT> an element, I ensure that the y value decreases sufficiently.


JT> It does seem a bit funny to me that "tess1.gif" generates a
JT> pattern with pink triangles above yellow triangles, while
JT> "tess2.gif" generates a pattern with the triangles
JT> interleaved. (Moving the pink triangle down one more unit would
JT> have the pink triangles beneath the yellow ones in the pattern,
JT> even though their ordering is revered in the pattern element.)

    Well, personally I think that overflow="visible" is a pretty weird
feature so I guess I'm not surprised that it can give weird results.

JT> But perhaps developers whose first language is written right to
JT> left would have different assumptions.

    Would it help if I said:
They are rendered in order of increasing X followed by increasing Y in
the user coordinate system?

     I believe most people in the world count up. :)

     (I'll say it four you, perhaps someone with a vertical language
background would argue with the x/y ordering....).
Received on Wednesday, 7 November 2001 15:43:44 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 8 March 2017 09:46:51 UTC