Handrawn also pegged it, and you are right, Egg. While it is deliberate policy to resize automatically on loading, the idea that all imported vector files can be suitably resized at will misses the point that sometimes the exact sizing of the original was actually important. Any engineering-based drawing for example. If there was an option to disable that policy then that alone would make all the difference. Or, since XD17 is good at remembering various features of objects, if it remembers the original size of the imported illustration, it could offer the option of restoring it, perhaps even a simple 'undo', depending on how it was coded.

It was important to me that while I was correcting the code in makercam's SVG import/export functions, I could rely on XD's gold standard pedigree in such matters to test the results of my alterations, and it was a bit of a shock that I couldn't do that. One of those things was ensuring that if an object sat in a particular place in XD's coordinate system, it would appear on import in the same place in SVGKam's coordinate system. I spent a fair bit of time to make that happen. It does that with XD17 -> SVGKam, but not SVGKam -> XD, since both size and position are ignored by XD17. XD11 respects the size but has issues with position, though that might be my code, but I cannot see what I could change in it to make it work with XD11 that wouldn't look like a fudge!

Makercam/SVGKam does have some drawing functions, but only because the original author was trying his hand in coding them, and not because it was a serious tool within makercam, especially when there are so many more powerful drawing apps around, and it doesn't make sense to me that SVGKam try to duplicate all that functionality. It was nevertheless useful to generate some quick simple shapes within makercam solely to test whatever code or bugfix I was working on but it would never occur to me to generate a whole CAD drawing in makercam, and I don't intend for SVGKam to do that either. Much as I admire makercam's simplicity of use, its drawing facilities are clumsy compared to XD and others, and I see no need to compete with them.

So I'm still dependent on XD behaving itself in a predictable and sensible manner.

Cheers,
Mike