XD16, and XD17 trial SVG import issue

[simsmj]

Hi, Egg, thanks for the time you put into the video. As I was watching it, I noticed you were saving and loading the second ship counter, which was the enlarged one that resulted from importing the export of the small one at the top. The already enlarged one doesn't enlarge further, but the small one does.

I loaded both of the xar files you posted, and the red rectangles work fine, though I note that they are the same length as the enlarged counter. So let me ask you to take my xar file I will attach here, containing two blue rectangles, and export the small one as svg, then re-import it. That's the one giving me the problem. I have been using X16 for over a year, and X17 since yesterday, and will be buying the upgrade to X17 tomorrow. Both X16 and X17 are enlarging the small ship on importing its SVG.

You could also try exporting the top small ship in the existing Adventures in SVG.xar file you have there, and try importing that, too. I would be surprised if that behaves. Actually, you could also try exporting a red rectangle sized to match the small ship counter, and see if that behaves or not. I just did that with your red counter.

I took your red counter and shrunk it to the size of the small ship, and exported it, then re-imported it. It came back the same size as the large red counter!

It's late, do not try this till tomorrow!! Otherwise neither of us will get any sleep till next Monday!

G'night all
Mike

[ss-kalm]

Hi, Mike ... As was said earlier "It's been a while"

When you resize it does it just make it more dense ... if you look at the status line if you shrink a 96 dpi object by 50 % it may just say it's 192 dpi. So it's smaller, but has the same pixel count. Are they actual SVG objects or bitmaps resized and saved as SVG (don't know if this is even possible) I'm just babbling again ...

[simsmj]

They are actual SVG-XML files. The reason for the interest is that shortly after I retired more than seven years ago I took up an interest in CNC milling, and bought myself a Shapeoko kit, and built it. The first plan was to design and build a mount that would let me attach my then iphone 4S to a pair of binoculars so that I could take a better photo of the moon. To mill something out of a material you need to draw it in a suitable prog (Xara was perfect!) and export the drawing as an SVG to another prog to specify and produce the toolpaths the CNC toolbit would follow while meandering through the material at various depths to cut out your drawn shapes.

The toolpathing app I use most often is an open-source utility called makercam.swf which only accepts SVG, while others can also accept dxf files. Both of these are vector-based. Makercam generates gcode which is a essentially a list of x,y,z coordinates to go to in sequence at set speeds and in either a straight line (G0 or G1 x y z) or an arc (G2 or G3 x y z, clockwise or anticlockwise, with other parameters). The CNC machine is itself vector-based.

I had been using makercam pretty happily for years, though it does have its little idiosyncracies, but last year I started a project to remake a tabletop naval wargame called Seastrike, replacing the cardboard printed counters with ones made from sign-makers plastic laminate, which is a sheet of one colour with a thin surface layer of another colour. You just cut through the top layer to reveal the body of the plastic where you want it. However makercam proved to be a real PITA with it, primarily because of one bug, so I looked around for an alternative, didn't see one I liked. So I looked to see if anyone was developing or supporting makercam, but no-one was. I made all of the blue fleet, gritting my teeth, then decided to have a serious go at fixing makercam properly before tackling the red fleet and the grey/white submarines, and other bits and pieces.

Boy, did I fall through some rabbit hole! Looking through the source code and trying to understand how it all worked and came together was a real voyage of discovery! (I'm from Dundee, where the Discovery came from, and is now still berthed.) I found myself often using the phrase 'voyaging through strange seas of thought forever' except I replace voyaging with becalmed!

Anyway makercam's replacement SVGKam is pretty much done, and the current aspect I am working on is the SVG import/export functions, which I think are now working correctly. But in the process I was aware that XD16's SVG features were not behaving consistently, but I had been assuming it was doing things correctly and that any deficiencies were the fault of makercam/SVGKam. Makercam certainly had some serious issues with SVG, but SVGKam plays nicely with other SVG-apps, at least as far as sizing is concerned, but XD16 and now XD17, no they're both doing something I think they shouldn't.

[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...