> While awaiting delivery of my Egg-Bot (in a week or so) I've been
> having a look at Inkscape. As I understand it, I can create a drawing
> in Inkscape that has one color per layer and then use Inkscape's Egg-
> Bot extension to transfer drawing to egg via Egg-Bot. If that's
> correct, I have two questions:
Hi Cary,
Yes, that's correct so far.
> 1. When the drawing of each layer is finished, does the Inkscape
> extension pause, tell me which color pen is next and then wait for me
> to acknowledge that I've changed the pen?
What you are describing is the "old" model for drawing layers. The software distributed along with the 2009 Clear-chassis Eggbot Beta worked that way exactly.
So, please allow me to quote from the current documentation ( http://wiki.evilmadscience.com/Eggbot_Control#Layers ):
By default, the Eggbot Control extension will plot your entire drawing. However, if you divide your drawing into separate Inkscape layers, you can then plot each layer or groups of layers in distinct plotting runs. This makes it easy to plot drawings with multiple colors by separating each color into its own layer. Load the pen for the first color, then plot that layer. When that layer is finished, change the pen to the next color and plot that layer. The only requirement to using this feature is that you begin each layer name with an integer in the range 1 through 100. For example, if you have three layers with the names,
1 - Red swirls
1 - Red zig zags
2 - Blue circles
Then you can plot the two red layers with a red pen by specifying "1" in the "Plot only layers beginning with" field. You can then change the pen to blue and plot the blue layer by specifying "2" in that field. Click the "Apply" button each time to begin plotting of the selected layers.
> 2. Suppose, for example, my drawing displays a red disc that partially
> overlays a blue disc. I draw the blue disc on layer 1 and the red
> disc on layer 2. Let's assume Egg-Bot draws layer 1 first (blue pen),
> then draws layer 2 (red pen). On the computer screen, Inkscape would
> display a solid red disc next to a blue crescent moon. Does Egg-Bot
> do the same: draw a blue crescent moon, then a red disc, or does Egg-
> Bot draw a blue disc and then a red disc that partially overlaps the
> blue one (in which case the red-over-blue part probably wouldn't
> appear solid red)?
If you open the "Layers" pane in Inkscape you can choose which layers are visible. If you are going to plot the blue layer and want to see what it will look like, you can hide all layers except the blue layer to reveal what it will do. In this particular case, it will show you that it's going to draw the full circle-- not a crescent shape.
The subtle part is this: The fact that Inkscape shows you only a blue crescent in the layer stackup *does not* reflect a change in the geometry of the blue shape. What it reflects is that you are telling Inkscape to draw those layers as fully opaque. In real life, felt-tip pens are usually not fully opaque. But it is possible to use certain types of pigment markers that come very close. If you want a more realistic preview, set the opacity of all the objects in the red layer to 75%-- that will give you a much better idea of what will actually print.
You can get pretty neat effects by plotting one layer on top of another, too:
http://www.flickr.com/photos/oskay/4820203382/
As a separate issue, you should understand that filled shapes (like circles and crescents) require special care. Eggbot is a "vector" plotter that draws the actual "path" of path objects in Inkscape. If you give it a circle to draw, it will move the pen in a circular path, rather than rastering back and forth across an area to fill it. If you do want to create solid-filed areas, we have tutorials and notes to walk you through the process:
http://wiki.evilmadscience.com/Creating_filled_regions
http://wiki.evilmadscience.com/Drawing_a_smiley_face
> That's fine for drawings I create in Inkscape, drawings shared by
> fellow botters and SVG files generally than contain drawings using a
> single color. What I would like to be able to do, however, is use any
> SVG file that contains a drawing I like (and am permitted to use).
> But each layer of a drawing saved in an SVG file typically contains
> different-colored objects. That's the problem. I can think of a
> couple of ways of dealing with that. Both involve converting the SVG
> file to another SVG file that has but one color per layer, such that
> the drawings produced by the two files appear the same (on the
> computer screen anyway).
Interesting idea. This is how our laser cutter software actually works: you assign different cut speeds (for example) to paths of certain colors. I can't say that I'm too fond of it-- it completely messes up if your blue is R000G000B254, for example. I'd prefer to use layers if it gave me the option.
To the extent that you have a *very specific* color that you want to convert, you could easily write an Inkscape extension that would take a given color spec as hand-entered input and move objects matching it to a new layer.
If, on the other hand, you wanted to import any possible document, with an arbitrarily large number of colors and assign each to a new layer, things could get complicated. A document with dozens of apparent colors might end up with thousands of layers-- not too helpful.
> I am wondering if there already might exist a utility that does that
> (convert an SVG files to an SVG file with one color per layer), and if
> not, how difficult it would be to develop one. (I might be able to
> answer that myself if I were familiar with the SVG standard, but I am
> not.) I considered enquiring about this at an Inkscape forum, but
> then thought I should raise the question here first (even though the
> membership here is, er, not yet very large).
I am not aware of any existing utility like this.
If you're inclined to try on your own, I'd suggest that you could get stated by looking at how the Eggbot extensions are written, and modify them until they do what you need.
You probably would not need to dig into it, but if you really want to know, SVG is reasonably simple and well documented-- it's just XML for graphics: http://www.w3.org/TR/2003/REC-SVG11-20030114/
Cheers,
-Windell
I'm not aware of anything available to do this. It's actually quite non-trivial
to handle in general with SVG. If you're getting SVG files from a particular
source, then that should help reduce the scope of the problem sufficiently to make
it straightforward enough to tackle.
What's some of the issues with handling this in general:
1. SVG has a number of different ways to specify the same color.... Hopefully
a specific producer of SVG documents will confine itself to a single method
thus eliminating this nuissance.
2. What if the document already has groups of objects? The tool would need to
be prepared to ungroup those groups and at the same time be mindful of inheritence
issues (inherited colors, styles, visibility, coordinate transformations, etc.).
And, what if other objects or groups in the document are cloning this group? Then those
objects or groups will need to be carefully decomposed and -- this is nasty --
their XPath references semantically understood sufficiently so that they can be
correctly reconstructed. In the case of a specific creator of SVG documents, you could
likely just figure out what sort of XPath statements it builds and just have
a simple search-n-replace with a regexp to change the XPath statement. So, again,
having a specific producer of SVG documents would help greatly in reducing the
complexity of the problem. (I'd be tempted to just assume that even in the general
case you could assume that complex XPath statements are not occurring and just
doa simple string replace. Anything producing anything other than simple XPath
statements in SVG documents deserves to be put out of its misery.)
3. Did I mention that SVG documents can reference Stylesheets (CSS). Talk about
a real pain....
But, keep in mind that my more pragmatic friends (e.g., engineers) are forever
telling me to not let the perfect be the enemy of the good. An 80% solution may
be all that anyone really needs here.
I wouldn't attempt to use XSLT for this project. (I happen to have to use XSLT
quite a bit myself.) I'd stick to a language which comes with or has available
an easy to use DOM parser and minimal XPath implementation. Python fits the bill
and Inkscape extensions even better. (They are written in Python and provide you
with a DOM parser w/sufficient XPath.)
Regards,
Dan
It's actually a brand new site. If you click the "Documentation" tab at http://egg-bot.com/ it will take you to that page now. :)
> Windell,
>
> May I suggest: add a permanent one-message thread here that is
> something like, "Egg-Bot newbies: Read this first!". I would put a
> reference to your excellent "setup" video front-and-centre. It
> answered many of my questions.
>
> Cary
Hi Cary,
I don't think that we can post a "sticky" message in this group-- if you do know a way, please let me know. But, if you look at the home page of this mailing list ( http://groups.google.com/group/eggbotuser ), you'll find that the header text now points you to the documentation site.
That video *is* listed as part of our "essential documentation." I'm curious to hear what other people think as well, but it's rather dry, not a flashy demo or anything... and so it's probably best viewed in context. :)
Cheers,
-Windell
> Thanks, Dan. What about grabbing the drawing from the screen (e.g.,
> after cropping and resizing),
As in screen snapshot?
> create one layer per color and vectorize each layer? Whatever method is used,
> one could reduce the number of colors by treating each (R,G,B) point in a given
> 3D neighborhood as the same color.
That should work (with a screen snap). There are a number of tools now available
for tracing bitmap images to produce vector outlines. The eggbot wiki has some
links to some of them under the "Tracing images" topic. I don't know offhand
if any them are geared exactly towards your application so they may need some
modification.
Code to trace outlines in monochromatic cases is fairly straightforward and
you have such a case since you'll have a target color and you're going to ignore
all other pixels of a different color. Unfortunately, I no longer have
the code I wrote years ago to do just this. (Was used to make a test set of Type 3
fonts for Ghostscript circa 1987: image a font character in memory, then trace it
and produce Bezier cubics describing the outlines.) But, hopefully, some of the
existing tools will do the trick.
Dan
Inkscape can actually do color tracing of a bitmap. See this video
tutorial for an example: http://www.youtube.com/watch?v=fKQluUaqyGw
The output of the tracing operation is a group of objects with the
different colors. For use with the Eggbot, you'll probably want to
ungroup them, put them on different layers and (optionally) use boolean
path operations to eliminate overlap.
That method might be worth a tutorial on our site, too.
Depending upon what sort of SVG you end up with after the tracing, a
simple Eggbot extension to do "group colors in layers" might be pretty
straightforward. That is, handling just the case of SVG from that
operation may sufficiently confine the problem to make the rest of the
work a piece-o-cake(tm). I'll give it a look-see some evening this
week.
Dan
Hmmm. walk the document once, putting each color into an array. Make
new document, then traverse the array, using XPath to find each SVG element
from the original document with matching color. (Blast them for allowing
color to be spec'd in several different attributes but this is a restricted
case and not the general case.) Put the XPath-located node list into it's
own group with appropriate inkscape layer naming in new document. Close
out new document. Return it as the document produced by the extension....
P.S. If someone sent me a sample SVG document or two produced by this process,
I'd appreciate it.
By this process, that is,
> Inkscape can actually do color tracing of a bitmap. See this video
> tutorial for an example: http://www.youtube.com/watch?v=fKQluUaqyGw
Dan
I played around a little with this one. It looks like the tool builds a single
group. In that group there is one <path> for each color. That path may outline
many distinct "objects", but it's one SVG <path> element. This makes breaking the
result into multiple layers trivial for the case of this specific tool in Inkscape:
put each path into a group with the attributes necessary to make it appear as a
"layer" in Inkscape. As it's okay to nest groups, the outer group can be left
alone. I'll also see if Inkscape's "layer" attributes work as attributes in a
<path>. Dunno as I've never seen much documentation for the attributes in the
Inkscape namespace which Inkscape (or sodipodi for that matter) uses.
Dan
This all sounds right. My impression is that it creates a stack of
objects that assume fully opaque printing-- such that it would look good
as a stack of objects made on a vinyl cutter, but possibly less-so with
non-opaque markers.
While it is easy to use the boolean path operators to separate the parts
into just the visible sections (the blue crescent in the earlier
discussion), it's hard to automate the process because extensions cannot
actually call menu options. (So again, it might be approached as a
tutorial.)
> Dunno as I've never seen much documentation for the attributes in
> the
> Inkscape namespace which Inkscape (or sodipodi for that matter) uses.
I've learned a lot from looking at Inkscape files themselves, but
unfortunately the Inkscape Wiki documentation for developers is very out
of date.
>
>> I played around a little with this one. It looks like the tool builds a
>> single
>> group. In that group there is one <path> for each color. That path may
>> outline
>> many distinct "objects", but it's one SVG <path> element. This makes
>> breaking the
>> result into multiple layers trivial for the case of this specific tool in
>> Inkscape:
>> put each path into a group with the attributes necessary to make it appear
>> as a
>> "layer" in Inkscape.
>
> This all sounds right. My impression is that it creates a stack of
> objects that assume fully opaque printing-- such that it would look good
> as a stack of objects made on a vinyl cutter, but possibly less-so with
> non-opaque markers.
Correct. In a private message, I'll send you a working extension which does
the "move to layers". Turn off layers and you can see the stacking. (The
extension was quick to write. Trying to figure out why Inkscape would crash
when it ingested the output took longer than writing the extension.)
Any good idea for an extension name? What I'll send you is called eggbot_foo
for lack of any creative juices during lunch.
> While it is easy to use the boolean path operators to separate the parts
> into just the visible sections (the blue crescent in the earlier
> discussion), it's hard to automate the process because extensions cannot
> actually call menu options. (So again, it might be approached as a
> tutorial.)
>
>
>> Dunno as I've never seen much documentation for the attributes in
>> the
>> Inkscape namespace which Inkscape (or sodipodi for that matter) uses.
The documentation page at the wiki for the Inkscape specific attributes was a list
oof the attribute names. Nothing more. Sigh.
Dan
You're quite welcome.
> Still fishing for a name for your
> extension? I suggest you avoid a name that suggests it's an Egg-Bot
> utility, as other Inkscapers may find it useful for a range of
> applications.
If we distribute it with the other Eggbot extensions, then there's
some merit to keeping eggbot_ in the name: makes it easier for folks
to manually uninstall the Eggbot stuff and otherwise identify what
came along for the ride when they installed the Eggbot software.
OTOH, I also see the merit in your suggestion.
BTW, Windell mentioned something about unchecking a "stack scans"
option in the bitmap tracer as helping. I've not looked at the impact
of that. I'm hoping it saves the effort of doing the intersection
operations.
> Would there be any point for the Egg-Bot extension to "import" this
> extension?
Probably makes sense to keep it a separate extension that you run only
when you need it and not, for instance, make it a tab under Eggbot Control.
As to being a good example of Python programming for Inkscape, you were
probably disappointed: as you can see, the code was very minimal but
it does illustrate the basic pieces of an extension. The extension turns out
to be more an example of using the Python lxml library to manipulate
an XML document.
As an example of an extension which draws graphics, the eggbot_maze.py
might be instructive. Ditto for many of the extensions which ship with
Inkscape and do rendering of one form or another. E.g., the spirograph
and L-system extensions.
Regards,
Dan
-------------
This extension is intended for use after running the
Inkscape "Trace Bitmap" tool of the "Path" menu
Running Trace Bitmap:
1. Run the tool with the "Multiple scans" selection of
"Colors" or "Grays"
2. "Stack scans" should not be checked
3. "Remove background" may be checked
Running this extension:
1. Will move each scanned color to a separate Inkscape
layer
2. Can optionally remove the original bitmap image from
the drawing
3. Can optionally turn off the colored fills within each
traced regions
4. Can optionally outline the traced regions
-------------
The extension (if you have it installed) appears under EggBot... as
"Post process trace bitmap". The files in the code repository are
eggbot_pptb.inx and eggbot_pptb.py. See
http://code.google.com/p/eggbotcode/source/browse/#svn/trunk/inkscape_driver
Dan
http://wiki.evilmadscience.com/Post_process_trace_bitmap
I have made some fixes and whatnot since the version of the extension from this
morning. There's a little zip file at the code site with the extension bits.
See the "Notes" section at the bottom of the above referenced doc. page for
details.
Dan