On Wed, 30 Jun 2004, bulia byak wrote:
> > 1. I think the clipping-paths-not-activating-on-load bug is related to a
> > cut+paste mistake in sp_item_set -- if you compare the
> > SP_ATTR_CLIP_PATH and SP_ATTR_MASK branches, one ->clip_ref has not
> > been changed to ->mask_ref in the SP_ATTR_MASK branch. (hopefully
> > that's right; this is from memory) Could someone please check, fix and
> > commit that?
> I would but I don't have a file to test it on. If you could provide
> one that would help.
<svg width="100px" height="100px" viewBox="0 0 100 100">
<circle clip-path="url(#blah)" cx="50" cy="50" r="46"
<rect x="0" y="0" width="50" height="50"/>
... from memory. I think that should work. Hopefully we support
> > 3. The tools currently set the newly created item's transform by directly
> > assigning to SPItem::transform. That's incredibly bad, and I
> > had not intended to leave it in. It'd be nice if someone could
> > make a public SPItem::setTransform() method (which would more or
> > less just call the private sp_item_(mumble?)_set_transform() ..
> > sorry, this is from memory) and use that instead. SPItem::transform
> > should really be treated as read-only by outsiders.
> I just wanted to ping you about that. We have this function already,
> it's sp_item_write_transform that does all the compensations (stroke
> width etc.), calls/not calls object's own transform writer (depending
> on optimize/preserve) and emits signal. Why don't you use it?
write_transform does a little _too_ much; in this particular case
optimization is NOT appropriate, and we do not want to combine the
transform with the existing one, but replace it entirely (though the old
transform will be identity in this specific case anyway).
Ideally what I have in mind would be:
SPItem::setTransform(NR::Matrix const &xform)
- sets the object's transform directly, with no optimization
or special handling
SPItem::applyTransform(NR::Matrix const &xform, bool optimize)
- formerly sp_item_write_transform; applies the given
transform on top of the existing transform, optionally
optimizing it (according to the second
parameter -- preference lookup would become the callers'
responsibility; I want to decouple the SPObject classes from
the preferences API altogether)