On Wed, 2004-05-26 at 20:30, bulia byak wrote:
In fact, from my programmer's experience, both <image> and pattern fills must support the same set of operations (affine transforms, opacity) and therefore are likely to be rendered by mostly the same code.
Patterns are tiled. It's hard (when the enclosing rect is transformed) to not have fringing due to opposite sides of the tile peeking through due to roundoff errors.
It's a fairly common bug in renderers that do tiled patterns/bitmaps.
- there should be a command to "wrap" the selected objects into a patterned rect (determined by their collective bounding box)
Yes, I thought about it too, and it's very easy to implement (once we clear the pattern bugs, that is). It will be usable not only for converting an <image> to a filled rect but for creating non-bitmap patterns too. I think "Make a tile" is a good name for such a command.
Sounds about right.
- there should be a corrseponding command to "unwrap" the objects in an SPShape's fill pattern as they appear in the SPShape; I think it's better to make copies of each rather than destroy the pattern. I'm not sure whether this operation ought to remove the SPShape or alter its fill.
Yes, this would be nice to have too, although more difficult to implement (most of the difficulty is in finding out how many copies of the pattern you need; once you know that you need to do either boolean intersection or masking of each object in the pattern copies with the former container shape).
Perhaps; an initial implementation that just copied one tile's worth and didn't bother with clipping would still be useful, however.
(I would hope it would be able to detect the image-in-rect situation and short circuit in that fashion anyway)
-mental