XD16, and XD17 trial SVG import issue

I have been using XD's SVG export and import features rather a lot recently, and I have been having several issues, but the most obvious one is this;
If I export a group or a single shape as SVG, then re-import that SVG it comes in 25% larger than the original shape.

This was in XD16. I just d/loaded the new XD17 as a 7-day demo and tried it, and it has the same issue. If I import the 1st SVG into another app,
it appears to be the correct size, but if I have that app re-export the SVG, and import it back into XD, it appears 25% larger.

Interestingly, I still have XD11 on my laptop so tried that. It imports its own SVG export at the same size. I had SVGKam (a CAM utility I've been working on) import the XD11 svg, and it showed the correct size, and its own re-export imported correctly back into XD11, albeit minus any colour.

So, what's going on? I was aware through 2019 of several updates to XD16, but they all seemed to differ in how to break SVG handling. But I do like the export selection option.

Attached is a xar file demonstrating the problem.

Mike

Hello Mike, long time no see. From what I can make out it's the old 72ppi/96ppi issue (the 25% difference).
However I can't see why it should make a difference if your not exporting the page.

I tried to reproduce what your getting but can't.

If I export the attached as svg (Selected Only) it imports into Inkscape at the same size. If I save it as an svg in Inkscape (can't export it) and import it into the Xara file it comes in ALMOST the same size give or take 2 pixels.

Ii think reading Mike's post he's saying if you export from Xara and immediately re-import into Xara it grows 25%. Almost as if it exports at 96 ppi and imports at 72 ppi. Although that should be 33% bigger (I think)!

Hi, Egg, it's been a very long time. Yes, I suspected the 72/96px ratio too, but that must be an internal Xara thing because Xara exports its SVG specifying pt (points) as the unit. It doesn't permit you a choice. But unlike pixels, it is a real-world unit that is accepted the world over as 1/72 of an inch so there is no real room for ambiguity. XD16/17 cannot import its own SVG exports correctly, and 25% is a huge error. The issue is a bit more complicated because having imported the SVG-1 back into Xara, you can then export that 2nd image as SVG-2, and re-importing SVG-2 does NOT increase its size. Only the first re-import increased in size.

Also, though I took no screen shots, I imported the Xara SVG-1 into three different apps, and they all showed the counter at the correct size, and they all could re-export/save as their own SVG, and correctly re-import those without issue. Even if they had their own issues, (I'm still working on SVGKam :D ) Xara has a clear problem. The 72/96px/" shouldn't be relevant unless Xara invokes an erroneous conversion somewhere, but I find that hard to believe, as Xara's own internal unit is the millipoint, 1/72000", which is why it is brilliant for engineering drawings. And because it always exports in pt and never px, other apps importing them never get confused about sizing, which has been an issue dogging the maker community because pixel-based SVGs routinely confuse many precisely because the px isn't a clearly-defined real-world unit of measurement, and really has no business being treated like an engineering unit. And it's not helped when apps that can export/import SVGs often don't allow the user to choose the export unit, and they default to px.

Also, Hi, ss-kalm, it's nice that there are so many familiar names still around. And I was sad when I found out that Soquili is no longer with us. I peek in now and again, but whole years can go by in between.

Cheers, all.
Mike

I looked at this with P&G16 - my experience was that the reimported svg was at a fixed size - that is it reimported at that same size even from a rexport of the object at a different size

it did not happen in XDP15.1

ther has been a change from 15 to 16/17 in that the program now allows you to export 'selection only' as opposed to 'whole page' [all objects] only - it may be linked to this, but obviously it is wrong [unless it is Xara doing something 'smart' for the web and screwing up the non-web yet again]

Hi, handrawn!

P&G16 can re-import at the same size, it didn't change the size of the SVG-2 even after re-exporting it again, and importing it back in. Also P&G16 didn't initially have 'export selection only', that came in a later patch, which I liked, but it was upsetting my exports that I had just got used to, so I re-installed the earlier version to maintain consistency, and my update facility has expired. I can opt back in before Friday and get P&G17 at a well-reduced cost, and I'm going to do that, but I am disappointed that SVG import/export appears to be so inconsistently managed.

In P&G17 importing an SVG results in a clipview of the imported objects, even if no viewBox parameters were present in it. That doesn't seem right, and P&G16 only used clipview when the viewBox was present. Because I am updating an open-source CAM prog at the moment (a very LOOOOONG moment :D ), which is SVG-based, one of the things I am correcting is its own SVG export facility as it has its own issues, and so I have been doing a lot of testing with it. I was expecting that Xara with its very long pedigree in vector-based drawing would be pretty much pitch-perfect on SVG import/export, and I have to say I'm pretty disappointed that it has been having these issues.

The viewBox settings if present in an SVG file is a clipview/zoom-level combo facility, and is optional, it doesn't have to be present. But that isn't behind P&G16/17's issue, because it still enlarges my ship counter if the viewBox is absent, which means explicitly no scaling, and even if it is present, if the viewBox width and height match the document (viewport) width and height, scaling is 1:1 anyway, ie no change.

I have also now found the opposite problem, where a collection of ship counters exported as SVG from my CAM prog is about 23.5cm across, but when imported into P&G16 it is scaled down to about 7.6cm across! Inkscape imports it correctly, and so does P&G11.

If I import it into P&G17, I see nothing but I am told there is a clipview object. If I remove the clipview and give the clip rectangle (actually it was unclosed and P&G17 reports it as a line) a line thickness to make it visible, the collection appears outside the clip rectangle, which is why it was invisible. And it is also only about 7.6cm across, not 23.5cm.

I am wondering if this is related to the treatment imported photos are given, whereby they are rescaled to a 'suitable' size? I may do some testing on that, see if there is an acceptable range where the imports are not scaled.

its good to see you back mike :)

yes what I got, with Xara Photo & Graphic Designer 16.3.0.57723 DL x64 Oct 25 2019, is the scaling down.... it's a pigs ear.. SVG is supposed to have standards, but I suspect xara uses libraries that are either out of date or not up to the mark

Hi Mike, I think the issues being caused by your Adventures in SVG file rather than a Xara bug:

Can you try this with the attached. Do you still get a sizing discrepancy?

Just a thought, have you Run X17 as Administrator?

Here's a similar file based on your token, which works fine for me:

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 :D
Mike

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

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! :D 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.

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.

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 :D

I think that ends this thread.

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:

Quote:

---

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!

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.

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

I knew it :eek:, 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

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

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! :D

Mike

Xara has never been SVG compliant - I don't think xara has ever been standard[s] compliant in anything oher than in it's own way of doing things.. I understand it's HTML generation code is 'interesting' but others would have to confirm that one way or the other

I am at least glad I can export vector in PDF to Harmony, or for others to use in Illustrator; I don't do engineering, but I do animation, and that needs precision as well

The code base for the desktop program is long in the tooth... sometimes I wonder if there is anyone still in the company that truely understands it all in detail....

I just can't understand the need to resize everything to 300px up or down. Why? If I import an svg I know how to resize it to a size that suits my requirements. Same-same is if I import a huge bitmap.

Sods law of course the rectangle I chose to use as an example just happened to be 300px!

I checked the manual - as far as I can see this automatic resizing should apply only to OCC stock illustrations - there is no mention of it applying to vectors imported from elsewhere, nor should it in a 'PRO' design program...

so in that respect [leaving aside the OCC where there might be a case for it] I'd say it's a bug.. quite possibly yet more unintended consequence of change elsewhere....

Quote:

---

Sods law of course the rectangle I chose to use as an example just happened to be 300px!

---

:D

Egg, it's also just plain rude. Whoever created the original SVG artworks in their Stock Illustrations didn't set their dimensions at random, the authors chose a size they deemed appropriate and suitable to the content, and we are talking about people with skills and talent for the most part, but Xara has overruled them to choose an arbitrary and irrelevant 300px, deeming that Xara users can easily amend the size themselves. And indeed they can but whatever size they come up with may not be what the original author intended, and in the case of SVGs like mine, the exact original size is the only appropriate one, and nobody else but me would know what that size was supposed to be without examining the SVG file itself.

I know that SVGs are meant to be re-scalable, but that doesn't mean that all scales are equally useful or appropriate; for many SVGs the actual scale used might not matter much at all, but it's wrong to think that it never matters.

At best Xara could take the view that they are showing a large thumbnail of the original, but to not offer the original sized version as an option could be seen as thoughtless and inconsiderate.

On a related matter I note that Xara17 is now treating things like 'rotation' of objects as specific attributes of an object, so selecting an object will show its current rotation state in the rotate field in the infobar. If you export it as an SVG it now contains the rotation information;

rect x="-113.385" y="-113.385" width="226.771" height="226.771" transform="translate(131.216 695.164) rotate(90)" This is an 8cm blue square but the units are pt as are all Xara SVG exports.

(Xara, I would like to choose the export unit, pretty please, or at least have it use the current user unit.)

This was from my sizing experiments in Xara17 a day or two ago. I'm still tweaking my SVGKam SVG loader code, and having this kind of stuff in them is useful for making sure my code is robust enough to handle them properly.

Mike

Edit: Ha, just saw Handrawn's crosspost! Egg's 300px came I think from his video where he used my 2nd ship counter which of course was the 300px resized SVG import of my original smaller ship counter. :D

Good point about the dimensions not being set at random in the OCC... I don't use it, but from that point of view it is just as bad a practice as outside of the OCC

It's just wrong on ALL counts as far as I can see.

There is NO reason why the program, should resize anything to whatever size. There's no reason why the end user can't be relied upon to use their own judgement for final sizing.

those of us who use the program to create vector asset/drawings/designs may well think this way - but it is not the way xara think it seems...

lets look at this:

Quote:

---

Originally Posted by xara manual

Because the original vector files vary enormously in size, graphics larger than around 300px are scaled down.

---

patronising - just like the 'squish'

This really shouldn't be the way a PROFESSIONAL GRAPHIC DESIGN APPLICATION thinks. If it was just WEB DESIGNER, I could understand it, but I have no idea what the programmers thoughts (or lack of) are here.

sadly, i don't think they actually care, based on passed experience

Thanks guys for the investigation, you were exactly true: we always resize SVGs on import, that was done to keep all imported graphics nearly the same size, as was requested when importing from a certain source. You can disable it through the registry key: HKCU\SOFTWARE\Xara\SVGFilter\6.1\scale - set this to 0 to avoid resizing on load. On the next release we'll come up with a smarter decision on keeping original SVG dimensions vs resizing in only certain conditions.

Hi nice to hear from you again :)

I can't find the registry key you mention for P&G16 - in fact there is no entry for SVGFilter in the registry at all...

Quote:

---

Originally Posted by handrawn

Hi nice to hear from you again :)

I can't find the registry key you mention for P&G16 - in fact there is no entry for SVGFilter in the registry at all...

---

Look exactly in Xara key - along with Xara products. If it isn't there - you will need to create it! Just create a new SVGFilter key as a child of Xara key, then step inside and create 6.1 key, then make a new DWORD value named 'scale' in it and set it to zero, then restart P&G product.

ah.. I'll try that thanks

[I did look originally for a key, and then checked again globally after your post]

thanks also for the info about next release

I am so going to try that, I hope it works. But I found an exception to the 300px import of an SVG, one of my SVG files came in at 200px, and I have no idea why.