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
Why? Remember, optimization is guaranteed to always give the same results (modulo stroke scaling, as we discussed on the list recently).
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).
Yes, so with the old one being identity, most of the stuff in that function would not harm you at all. So I don't see a need for a new function.
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)
Oh. OK. But, it looks up _several_ pref values, one for each of compensations it does. If you want to move them all to arguments you can, but then please add applyTransformUsingPrefs so that we don't have to look up all these numerous prefs (with more likely to be added) in all the places (more than a dozen) where write_transform is now called. (Also, don't forget about the adv argument too.) And once you add it, I don't see much sense in having ApplyTransform without UsingPrefs - who's gonna use it anyway? :)