XD16, and XD17 trial SVG import issue

[simsmj]

Oh, dear! I just spent the last 10 minutes or so exporting squares of increasing size from my new XD17 as SVGs ('selected only'), and re-importing the resulting SVG. ALL of the imported squares were exactly the same size, 7.94cm x 7.94cm. The originals started at 1cm sq, going up 0.5cm at a time until I reached 8cm sq, then I went to 9cm, 10cm, 15cm, 20cm, and 30cm. I verified the exported SVGs contained the correct height and width values, and several I imported into Inkscape where they had their correct sizes.

I took the 7.94cm sq and rotated it -45d exported it and re-imported it and its bounding box was still 7.94cm sq, but it was clearly smaller. I rotated it back to its original orientation, and it was now 5.61cm sq.

That's no richt! No richt at a at a!!
Edit: Playing with units, 7.94cm is 300px.
Edit: You were right about the 300px, Egg. But I see no justification at all for this. I haven't found anything in the manual about it, and the image restriction only kicks in if its larger than 1920 px, but an SVG isn't an image. But 300px also happens to be a default size for inserting new objects, at least for the few I tried.

[simsmj]

Hah! Found it. Pg 33 of the XPGD17 Manual, Stock Illustrations:

"Because the original vector files vary enormously in size, graphics larger than around 300px are scaled down."
In practice graphics smaller than 300px are scaled up, too.

So it is designed behaviour after all. I shall just have to cope with that. I'm sure I can manage

I think that ends this thread.

[Egg Bramhill]

I hope this doesn't end this thread Mike! There are serious issues here. I've been doing my head in all day as why are these anomilies being presented.

So I've looked at your great find relating to XPGD17 manual (Page 33)

If I search for the same in XDPX17 the manual page gives on Page 27:

Stock Illustrations
In addition to the STOCK PHOTOS, there is also a category of vector graphic STOCK ILLUSTRATIONS. All the images have keywords so you can easily search for the graphic you want. Because the original vector files vary enormously in size, graphics larger than around 300px are scaled down. Also un-grouped images are placed in a group for ease of manipulation. Because this is vector clipart, it’s re-sizable to any size without loss of quality.

Different answers. Not only that but I've experimented all day with creating squares and exporting as svg's. Often on importing the svg into Xara the square is almost double the size. At other times exporting rectangles as svg and opening in Xara they're smaller.

This is a serious bug!

[ss-kalm]

And it ALL comes back to the fact that this PRO Graphic Application is NOW all about producing content for the WEB ... it's a shame but its time as a serious graphic application is over. It's now ONLY targeted at website work.

[simsmj]

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

[handrawn]

I knew it , well done for finding that Mike - so after all the issues we have had with SVG libraries in the past, we now have this; sure we can live with it, but it is an indication of the way xara now approach things

resiizing on import means those for whom this is not the size they want are going to have to resize again; and I would suggest that is most people regardless of the way they are using it, so why not just leave it to import unchanged - either there are knock-on issues somewhere in the app UI, or Xara is again treating it's users as too lazy to learn anything beyond the surface of waht they are doing...

EDIT - cross posted with you Mike

[handrawn]

there is an option to disable automatic resizing of bitmaps in the UI, but not vectors... and there is a long list of things that ought to be in the UI but are not - had a quick look at the registry, but nothing obvious to me...

[simsmj]

Handrawn, while I was out on my exercise walk this morning, I thought that there may be a registry key that might disable, or amend the behaviour of that function. I'm still going to look at that, but one thing I note is that this policy makes XD16/17 non SVG-compliant because it ignores the viewBox, which provides the SVG's clipview/scale/panning settings. That said, I don't know that Xara have ever claimed that it was SVG compliant, but half-hearted or broken support for an international vector standard might not make for a good look for a vector-based app, I think. As I said in my previous comment, making it an option that the user can accept or refuse would solve that problem, and it would certainly help me, and I can't see that that would disadvantage anyone.

SVG also has currency as a medium of file transfers between drawing apps, and adhering to the relevant standards is important, and not doing so undermines that currency.

While we're at it, I'd like an option to choose which unit the SVG export will use, because having to manually convert pt to cm and vice versa on a calculator to verify my SVGs is depressing!

Mike