On Wed, 30 Jun 2004, bulia byak wrote:
- 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" style="fill:blue;stroke:black;stroke-width:2px;"/> <clipPath id="blah"> <rect x="0" y="0" width="50" height="50"/> </clipPath> </svg>
... from memory. I think that should work. Hopefully we support <circle>.
- 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)
-mental