Re: pattern and rendering order

Erik Dahlström:
>
> What are the use-cases for wanting to do overflow="visible" on a pattern
> tile? Are there any of those use-cases that cannot be solved by editing the
> pattern tile so that it fits inside the defined viewport?
>

With perfect implementations there is of course always a workaround,
first creating a larger part of the pattern manually then searching a
rectangular viewBox for the repetition. With overflow="visible" a
problem-oriented clipping path may work better to safe some time 
and work or to gain some more precision.

This approach seems to be necessary for most of the 17 wallpaper groups
(or plane crystallographic group) possible for periodic tilings, because SVG
has only a convenient way to describe the p1 group.
For others the size of the viewBox is often an irrational number, therefore
precision of display is essential - but if not available an author may have
another chance to work around the problem with overflow="visible" to
compensate some nasty clipping effects. And obviously it can be slightly
simpler to provide the pattern with overflow="visible" for some of the
17 groups.

Developing completely asymmetric pieces in the M.C. Escher style
of tiling by warping initially simple paths, it happens often, that parts
of the pieces fall out of the viewBox - they are simply missing in another
area of the tiling of course, to fill the viewBox without the use of 
overflow="visible" requires to add more copies to the pattern 
element manually. This would not be necessary with overflow="visible" -
of course it typically creates no overlap-conflict. More arbitrary approaches
to get a pattern do.


The first time I wanted to use overflow="visible" was a combination
with a partly transparent gradient to simulate something like the 
distribution of the electron clouds of atoms on a regular surface
with a p6m group.
It turned out, that without overflow="visible" one has to provide
much more of the pattern manually to get the intended effect
in some viewers with some rendering problems (I still don't know
how to do it with pattern for the Adobe plugin; for most
viewers today it works indeed better with a massive use of 
use elements or very huge paths than with pattern to create a 
pattern of proper quality).
Another interesting case was an accuracy problem of Opera
with a p31m group - maybe Opera rounded numbers of the viewBox 
somehow - such inaccuracy could have maybe covered by the author, 
if Opera had not ignored the overflow="visible" too ;o)

The problems of Opera and the Adobe plugin show, that the 
residuals from clipping to a rectangular viewBox causes problems 
for many tilings of some of the 17 groups.

The other point is of course, that it is already available in SVG1.1,
therefore it should be defined in a meaningful way and leading to
something useful for authors, maybe simplifying both the creation
of pattern with higher symmetries and to work around inaccuracies
of viewers.


Olaf

Received on Thursday, 23 April 2009 14:31:54 UTC