Hey all, had an exciting break wading through more gross Java libraries. This time instead of DXF, SVG. There are a lot of reasons to go with SVG, but I think the biggest is that we have a bit better defined file-format. Still, I (Colin) have the issue that you can make all kinds of wonderful, non point coordinate shapes with SVG. Take this for example:
<g
transform="translate(0,-62.362)"
id="layer1">
<rect
width="197.14285"
height="171.42857"
ry="85.714287"
x="71.428574"
y="104.28571"
transform="translate(0,62.362)"
id="rect2812"
style="opacity:0.8;color:#000000;fill:none;stroke:#980101;stroke-width:0.40000001;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none;stroke-dashoffset:0;marker:none;visibility:visible;display:inline;overflow:visible;enable-background:accumulate" />
</g>
That is a rectangle with rounded corners. We have to support the corner rounding and SVG still manages to sneak in transformation matrices.
Anyway, what this all means is that I'm still using libraries because we don't have time (or the insanity) to implement an SVG interpreter that would work. And why should we, there are plenty of great ones out there. I chose one called Batik, a Java library, under an Apache license.
Java
Well, the DXF -> SVG converter is in java. So we already need java. I like java. I needed an SVG library, Batik seemed pretty good and also was in Java.
I plan to communicate with the PIC using Java, too. Steve Zhangs group does this and it seems to work fine. There is a Java wrapper for LibUsb.
Lost in Translation
Okay, so still work to be done on interpreting. I'm trying to figure out units. DXF does units really strangely because its mainly for human-read drawings and humans would use a graphical scale printed along with the drawing. DXF kinda doesn't have units (but it also kinda does). Something similar is happening with SVG. SVG has some units, but it also allows relative units (IE, my drawing is 100% x 50%), in which case we don't know how large the user wants their cut object to be. I'm going to look through things a bit more, and if I don't get anywhere, we'll do everything in relative units and then ask for a scale or part dimension before actually cutting.
A Puzzle
I can now generate lists of coordinates like the following from SVG and DXF files. I'm mimicking the PIC instruction set Xy and Hyeon Taek came up with (at least, if I remember it correctly).
MT = "move to" -- these are entry points to a cut
LT = "line to" -- these are lines between absolute coordinates
Quesion: Xy and Hyeon Taek, we want relative steps, not absolute coordinates, right? Relative coordinates, scaling, and entry points are next on my chopping block
Anyone want to figure out what this instruction set cuts?
Hint: there's a twist
MT 0.01967497169971466, 0.3572882115840912
LT 0.022997645661234856, 0.3516520857810974
LT 0.02663806453347206, 0.34666678309440613
LT 0.030552467331290245, 0.3423894941806793
LT 0.0346980020403862, 0.33887743949890137
LT 0.039031147956848145, 0.33618777990341187
LT 0.04350868985056877, 0.3343777358531952
LT 0.04808733984827995, 0.3335045278072357
LT 0.052723854780197144, 0.33362528681755066
LT 0.05737502500414848, 0.33479732275009155
Download the full set if you're into cooridates!