I would like to export my Corel files and parse them myself with C# code for display in Microsoft’s WPF. I've tried this with SVG files with mixed success. Does anyone know of a resource that explains the coordinate system of Corel's SVG export data?
After parsing corel SVG paths, I've noticed some odd behavior. Here are a few things:
The position of a Corel graphic on a page prior to exportation affects the size of the graphic in the SVG file? This makes no sense to me.
I get negative numbers (x y points) in the SVG file when corel numbers are all pos.
The x,y values seem to be flipped to y,x values.
I haven't spent a ton of time trying to reverse engineer corel's exported svg output values. I was hoping there is a link to an explanation.
I have a large volume of our own clip art that I need to put on line via Microsoft's WPF (windows presentation foundation) all of which is saved in CDR files (love Corel since ver 2!).
Some information about SVG at http://en.wikipedia.org/wiki/Scalable_Vector_Graphics
I haven't looked at SVG but I did a lot of work with postscript many years ago and can make some guesses which may or may not be useful.
"The position ... affects the size "
Seems odd, but remember that most Corel objects are stored internally as the size you originally created them, plus any modifications you've done since -- stretching, scaling, rotating. You might possibly get more consistent results if you ungroup all and convert the objects to curves before creating the SVG. This ensures your SVG object will be based on "what you see now" rather than a base object and a series of transformations.
"I get negative numbers"
Postscript inherently measures everything from the bottom left of the page, consequently "up" is positive and the top of the page is a positive number. Most other programs (and many people) think page measurements should be taken from the top left, in which case the top of the page becomes zero and the bottom of the page might be either a positive or negative number depending on the coordinate system and transformations in use.
In postscript at least, all of the above can be further complicated by permanent or temporary transformations affecting the coordinate system of either the whole page, groups or individual objects.
"x,y values seem to be flipped"
This sounds like page rotation to me. It typically happens if you send a landscape page to a postscript printer. Printers presume sheets of paper to be portrait, so programs begin by sending a transform that rotates page space through 90 degrees. But ... printers do not rotate pages through their centres, like a human would. They rotate around that bottom left (0,0) corner. So as well as rotating the page, you either have to shift it sideways by the width of the page, or you have to use negative numbers for one of the axes. Which actually starts to look like another instance of the previous point.
I'm not sure whether any of this needs to be happening when exporting to SVG. But from your description it sounds like some of it probably is. And maybe something as simple as changing the page orientation in the original CDR file would eliminate some of the translations and simplify the resulting output.
After reading into SVG rendering rules, it turn out that SVG coordinates can be expressed in REAL or RELATIVE terms. REAL terms are what one would expect. RELATIVE terms are expressed like:
M100 200 l 0 100, 0 200, -100 0, ...
All coordinates after a capital letter are expressed in real terms. All coodinates after a lower case letter are expressed relative to the last REAL coordinate. M(X Y) c(X+x1, Y+y1) (X+x2, Y+y2) (X + x3, Y + y3) ... In REAL term, the above example becomes:
M100 200 L100 300, 100 400, 0 200