Print&cut-- From Inkscape SVG, how to engrave (raster) & cut (vector) superimposed correctly [Solved]

Everything Else
13

I believe that was the error.

You have a point about the duration. I seem to remember that one instance of the business card (remember, the first file I uploaded to this forum thread was named “Business card r7”) now takes 10:21 to engrave @ 225 LPI (that duration also includes the cutting). A full sheet (16 business cards) would therefore take almost 3 hours to engrave & cut at that number of lines-per-inch. (We haven’t engraved-&-cut a full sheet yet because the design is still at the “draft” stage & we don’t want to waste a whole sheet of material on unfinished artwork. Also, there is room to put about 4 more business cards at the bottom of the sheet, rotated 90 degrees, but we haven’t chosen to do that.) Since the movement speed of the laser head depends on the material, a different material may take a different length of time, but many materials will likely be similar in duration.

There seems to be a tradeoff between editing effort & the duration of the “burn” (burn = operation of the Glowforge machine). I will elaborate on this for a few paragraphs:

Letting the laser cutter run for 3 hours isn’t a lot different than many 3D-printer designs that may take 12 hours to finish in our makerspace. (Some of these 3D-printer designs are almost simple enough to do on a laser cutter!)

I strongly disagree:

  • If you refer to my reply to jeffreyp above, you’ll find that the only “step” that requires any thought, after the rasterize filter is initially set up, is to make sure that items to be rasterized have the filter applied to them. (At the bottom of that posting, I also mentioned the “export to PDF” step, because that’s different than the process for uploading the design to GFUI in SVG format, but the PDF step takes only a couple of mouse clicks and, in my opinion, doesn’t really require any thought once you’re used to it.) If you separate your design into layers in Inkscape, then making sure the rasterize filter is applied can be as simple as selecting everything on your “engrave” layer and selecting the rasterize filter from the top of the Filter menu. (You can even use a keyboard shortcut for the submenu if you want. :smile: Also, you might have named the layer something like “raster_engrave” if you also have a “vector_engrave” layer.)
  • Just now, I was revising the design in question, and indeed I found that use of the rasterize filter didn’t noticeably add any complexity to the editing process. I did find it valuable, when about to edit a component of a group, to double-click on the group to “enter group,” rather than Ungrouping the group. Using “enter group” keeps the rasterize filter applied to the group, whereas if you Ungroup and re-Group the group, you would have to re-apply rasterize afterward.
  • When I explained the rasterize filter to the makerspace director yesterday, she was visibly surprised, which means she hadn’t thought of it before, just like many readers of this thread - but she immediately understood the process, even before we successfully laser-engraved & -cut a business card for the first time without the failure messages that had happened before, or the manual resizing & alignment that we’d been doing in GFUI.

Also please be aware that our design in question includes vector clipart:

On the one hand, suppose I’m going to use a 100% vector output process, so that I want to correct the kind of vector-graphics style issues pointed out by marmak3261. Then I have to edit vector clipart which was drawn by someone else and which could easily be very complex. Vector clipart that looks fine onscreen could have

… that keep the clipart from rendering properly on the laser cutter.

On the other hand, with the rasterize filter, the thought process that replaces that is to plan what things in my design should be engraved & what things should be cut, which is a thought process I should do anyway. As long as the Inkscape screen looks like what I want, I’ll very probably get what I want from the laser machine, without having to reverse-engineer the structure of someone else’s vector drawing.

I definitely agree that standardizing the structure of a vector drawing, and outputting that drawing to GFUI in vector form, can pay off in letting the laser machine take less burn time. That is a point that I hadn’t thought of before.

(I am intentionally not @ “mentioning” users unless I want to alert them that they particularly should read or reply to the discussion. I think those who’ve posted to this thread will automatically be notified of all traffic on the thread anyway.)

14

I really appreciate your description of this and the time you are spending in getting it right.

Trying to simplify for how I would do it and keep it all SVG but also editable.

Use three layers in Inkscape. Base layer that has your cuts that don’t change. The next layer the vector graphics that are editable and the text that is editable. Export this layer as a bitmap. Place the bitmap in a third layer and size it as needed. You can turn on now and turn off second layer. Export the file as an SVG. It will only export the layers that are turned on in Inkscape and visible.

As to how long the process will take to engrave in the Glowforge, not sure what to say about that.

3 Likes
15

It’s because of the data buffer in the machine, and the total time the project runs.

So let’s say the engrave area of the bed is 18" x 11", at 225 LPI that is 44,550 linear inches of head travel. At full tilt, the head moves at approx. 335 IPM which equates to roughly 8,000 seconds or 2.2 hours. That’s well within the machine buffer, unless you have a second engraving step that also spans the entire sheet, which will add another 2.2 hours to the job. A third, or fourth, fifth, etc. engrave step will add another 2.2 hours per EACH step to the job.

This “time stacking” can easily happen when engraving vector artwork because every color in the design will generate another step. It’s not really because the artwork itself is complex. You could load a file with four rectangles each a different color (thus four steps) scale them up to full sheet engrave and you’ll have the same complexity problem.

5 Likes
16

Thanks for the help with this, everyone. @LinuxDrawing, since you’ve marked this thread as “Solved”, I’m going to move it to Everything Else so the discussion can continue there. If you run into any other trouble, please post a new topic in Problems and Support, or email us at support@glowforge.com.

17

We did this with a design that included curves (that would look “jaggier” as raster resolution gets poorer) as well as fine detail (nearly parallel curves very close to each other).

We did not happen to include gradient fills or anything similar, such as a photograph.

Material was opaque acrylic, which doesn’t tend to have charred cloudy deposits downwind of the engrave like wood or leather does (I’m not sure of the jargon term for these deposits).

I was fully expecting that the higher bitmap resolution would make higher engrave quality (due to interpolation done by GFUI). Instead, we didn’t find any clear difference in engrave quality between the two bitmap resolutions. The makerspace director even got out a magnifying glass.

Maybe on other materials, or with gradient fills etc., the DPI = 2 x LPI guideline is more applicable.

18

I’ve made test files to compare gradient quality @ 225 vs. 450 DPI. When my makerspace’s Glowforge machine is available, I can try these.

19

Noticeable differences in my tests, and in reality.

20

Item 1.

That is a very important point that I haven’t commented on until now. I agree that it is better to keep the text editable.

One of the workflows suggested in this thread involves Path > Object to Path. If you do this on the original text in your Inkscape file, then the text is no longer editable as text. (The text, once converted to paths, can be edited by having graphical effects applied to it. This is necessary sometimes, which is one reason the Object to Path menu item exists, aside from situations where an Inkscape file is to be used by something that can handle paths better than text.) In my business-card example, if the makerspace changes its hours or e-mail address, then it is much easier to update the business-card design if the text is still text than if all the text were converted to paths.

In the legal realm of software licensing, “source code” is defined as (to my recollection) “the preferred form for modification.” If you change your original text into paths, then you would be removing the source code for that text from your own design. Having the text-to-path or text-to-raster conversion be done by some means that makes a copy, preserves the source code for you.

Item 2.

Manually resizing one layer (the bitmap in this suggestion) to match another layer (the vector cuts) is exactly what we at our makerspace are trying to avoid.

When we were manually resizing in GFUI, we would get artifacts like, a ridge of non-engraved material inside of the cut line, because the engraved rectangle didn’t quite line up with the rectangle of cut. Then this ridge has to be trimmed off by hand.

With the rasterize filter, no resizing is needed. The raster output from Inkscape always registers perfectly with the vector lines on the other layers.

Item 3.
Some general points:

Techniques that use one layer to generate another layer that looks the same, can lead to mistakes in which you leave the wrong layer visible when sending the design to the laser cutter.

Also, you need to generate that output layer all over again whenever you make any change, no matter how minor, to its source layer. With the rasterize-filter approach, any change that doesn’t add any top-level objects to the set of rasterized objects doesn’t require you to do that generating step at all - Inkscape automatically updates the raster data in the next PDF that you export. (“Top-level objects” refers to grouping. If you apply the rasterize filter to a group that contains a rectangle and some text, and then you draw an ellipse within that group, you haven’t added any top-level objects; the ellipse, being contained within a group, isn’t a top-level object.)

I think that “I’m about to Glowforge this; I need to make a PDF and then upload that to GFUI” is easier to remember, and less error-prone, than exporting & re-importing a PNG, or doing any other manual process for copying one layer to a layer of a different format.

Both procedures, namely exporting as a PNG bitmap (then re-importing into Inkscape), and exporting as a PDF (with the rasterize filter), produce another file besides the source SVG, which means, the export steps are a similar number of mouse clicks (re-importing adds more mouse clicks). But the PDF contains both the raster & vector data, and includes the overall size of the design in mm or inches, while the PNG contains only the raster data, and has no scale factor. So I think the PDF is more useful. For instance, you can send or give the PDF electronically to someone to show them what the design looks like, even if they don’t want to use an SVG program such as Inkscape. Or you can print the PDF to an ordinary printer to produce a mockup, including the vector cut/engrave/score lines, without needing to start Inkscape if Inkscape isn’t running at the moment.

Having the file that’s sent to the laser cutter (PDF in my suggested process) be different than your design file (SVG) has the advantage that you can (optionally) leave a “comment” layer visible in the design file, without that layer printing on the laser cutter. We did this, for example, in the business-card design, where we were trying different fonts. Each instance of the business card in the design file has a comment underneath it that says what font(s) were used on that instance. This process can involve:
a. File > Save in the source SVG file;
b. making the “comment” layer invisible;
c. exporting the PDF;
d. Edit > Undo to make the “comment” layer visible and mark the file unmodified so I won’t think I have to save the SVG again.

Item 4.

In Inkscape, I suggest that vector layers (e.g., cut) should be higher in the layer stack than raster layers. I had some vector cuts (the phone number) superimposed on a raster engrave rectangle. If the layer that contains the (raster) rectangle is higher than the (vector) cut layer, then the cuts won’t be visible on your Inkscape screen (unless you happen to make that area of the raster rectangle be transparent).

We also use an invisible layer called “unused”, where we can send unwanted parts of vector clipart instead of deleting them. This way, if we later want a deleted part of the clipart back, we can just pull it back from that layer, instead of having to repeat all steps in standardizing the clipart for our Glowforge design.

Item 5.
I wish someone would try the rasterize-filter method and at least post to this thread that they were able to engrave-and-cut something on their Glowforge with it. Even if that person never uses the technique again.

All you need to do is:

  1. Put the filter file into your Inkscape filter folder and restart Inkscape.
  2. Make an Inkscape print-and-cut design.
    a. For testing, you don’t have to put the engrave & cut on separate layers if you don’t want to.
    b. One of the cases of most interest for this testing is to engrave a complex vector drawing of any kind. As alluded to by mpipes, you should reduce the drawing to monochromatic (I use shades of gray) to keep GFUI from converting it into many engrave steps. I believe you would equally have to edit the drawing to monochrome whether you output in raster or vector form.
    c. Another case of interest is to engrave text.
    d. But the process is the same whether you do [b] & [c] or not.
  3. Make sure that any vector item that you want raster-engraved has the rasterize filter applied, and that things you want vector-cut/engraved/scored do not have that filter applied. Bitmaps (photos etc.) don’t need the rasterize filter, since they’re already in raster format.
  4. File > Save a Copy… as PDF. In the PDF export options dialog, make sure “Rasterize filter effects” is turned on.
  5. Send the PDF to the Glowforge. As with any Inkscape vector design, you’ll need to specify in GFUI which vector steps are to be cut vs. engraved vs. scored.

When revising the design:

  • You never need to do step 1 again on the same computer.
  • Step 3 is much simpler if you combine things into groups; then you can just apply the rasterize filter to the group. If you do all edits to the group by double-clicking the group as I mentioned in an earlier post, then you don’t have to touch the rasterize filter again. Only if you add a new group, outside any existing groups (i.e., at the top level of the group hierarchy of your design), would you need to set the new group to be filtered by rasterize (only once, then the group will retain that filter setting).
1 Like
21

But the consensus in this thread was that vector engraving usually takes a lot less time than raster engraving with the same bounding box. Which means, if the vector versions of our makerspace’s designs are rejected by GFUI due to complexity, but the raster versions, taking more burn time, are successfully laser-engraved, then burn time must not be the only reason for GFUI to reject a design. My guess is that the Glowforge company is trying to limit CPU load on their cloud servers, for processing vector designs, and therefore vector designs with more than a certain number of fonts or path elements are rejected, even if the burn time of those designs wouldn’t be very long.

There are some things that can make that time even longer:

  1. Some materials require slower laser-head movement.
  2. From watching the Glowforge in operation (I didn’t specifically look for this), I think the laser head overshoots the end of each raster row; in order to slow down, stop, and turn around for the next raster row. This will increase (probably by only a few percent for a full-sheet engrave) the time needed per raster row.

Yes, my idea of making a design for a laser cutter is to plan what artwork will be done by what method (raster/vector, engrave/score/cut). All the artwork in each step should be monochrome, so that both GFUI, and anyone looking at your design file, are clear on what artwork should be processed how. This typically means converting colorful vector clipart to monochrome.

The point you’re making seems to be about raster engraving of vector artwork. The “time stacking” may happen in both a vector design & a rasterized version of the same design, but if vector-engraving that full-sheet rectangle (suppose it has only stroke; no fill & no bitmap, nor other contents) takes 11 seconds ((58-inch perimeter / 335 IPM) X 60 seconds/minute), then the “time-stacked” total burn time would be 44 seconds, which isn’t much, vs. 8.8 hours for a rasterized version of the same 4 rectangles.

22

Except that you cannot engrave the interior of a no-fill object, rectangle or otherwise.

23

You have done such a great job of documenting the challenges inherent to the Glowforge workflow. In a production environment where all these things need to be addressed and standardized, I really appreciate the challenges you are trying to manage. For me it’s only ever a few pieces of text, usually don’t have to worry about rights, repeatability, and shared working environment. Thanks so much for taking the time.

1 Like
24

(Suppose it is a rectangle, just so we have a specific example to visualize.)
You can’t engrave the interior of a no-fill object in vector mode (although, if that object is a group, there may be many objects engraved within the bounding box of that group). In raster mode, however, the laser head spends a lot of time in the interior of that rectangle.

Yes, technically, due to a limitation (detailed below) in GFUI, in most cases you don’t want to raster-engrave a no-fill object. However, I didn’t propose raster-engraving a no-fill object. I proposed engraving:

no-fill vector rectangles (emphasis added).

The fact that GFUI misinterprets your design intent (changing “no laser power” in the middle of a no-fill raster rectangle to “full laser power”) doesn’t alter the vector vs. raster comparison that mpipes was making.

The attached files illustrate this raster vs. vector question, and were made as follows:

  1. Make a vector rectangle that fills the vector_engrave layer.
  2. Set this rectangle to have stroke (black) but no fill.
  3. Duplicate this rectangle (Inkscape will put the duplicate at the same location as the original).
  4. Move the duplicate to the raster_engrave layer.
  5. Set the raster_engrave rectangle to have fill (white). (The stroke is left unchanged.)
  6. Apply the rasterize filter to the raster_engrave rectangle.
  7. Make the raster_engrave layer be the only one visible.
  8. Export the Inkscape file as PDF (using File > Save a Copy…) at 225 dpi. (I will use the terms DPI and PPI interchangeably.)
  9. Make the vector_engrave layer be the only one visible.
  10. Export as in step 8.

If you omit step 5, then the following will happen:
a. A rectangle with stroke but no fill gets rasterized by Inkscape to have transparent fill, and is stored in the PDF that way.
b. GFUI doesn’t support transparency, so it converts the transparent fill to a solid color.
c. The color picked by GFUI is black (full laser power), which is the opposite of the white (no laser power) that we wanted.

Anyway, notice that the filesize of the raster PDF is bigger, by a significant ratio, than the filesize of the vector PDF. Also notice that GFUI will let you engrave, cut, or score the vector PDF, but only engrave the raster PDF. These differences are as we’d expect for vector vs. raster.

Our makerspace’s Glowforge machine isn’t turned on at the moment (and I’m not there), so I don’t have an official estimate of the burn time for each of the 2 PDF files, but my expectation is that the burn time of the attached raster file is a lot more than the burn time of the vector version.

vector engrave vs. raster engrave.svg.zip (1.4 KB)
raster engrave.pdf (15.0 KB)
vector engrave.pdf (983 Bytes)

27

Language barrier.

Other laser ecosystems refer to vector engrave, which is what the “score” function is on the Glowforge.

The Glowforge has the ability to accept vector graphics directly. Those systems utilizing a print driver rasterize everything when sent to print. That’s why stroke sizes have to be below a certain threshold on other systems, and the Glowforge doesn’t care about stroke size. A 1” stroke is treated the same as a .0001” stroke.

In Glowforge world, you have 3 functions. Cut, score, engrave. Cut and score are vector elements. Engrave can be a raster or vector element.

1 Like
28

Vector artwork is not being rejected because of complexity. It’s being rejected because every object of a different color is an entirely different operation so a design with 10 colors ends up with 10 independent steps/operations. If each color spans the full bed size that means the laser head is going to zip back and forth over the whole sheet - 10 times. Using my example above of 2.2 hour run time for a step, a job with 10 colors (even vector shapes) is going to take 22 hours.

And that’s why GF does not like them, it does not have a 22 hour buffer.

Part of your other problem with things is using white as a fill color when you don’t actually want a fill color at all. If you dont want that shape completely engraved, don’t use white. Just make it a NO FILL object, give it a stroke, and things will be fine. GF knows how to translate that fine and so do all the main design apps we use.

2 Likes
29

@vee or other staff member, can I please have a response to ticket 122616 which I opened on April 16 about this thread? By e-mail to me would be the best way. Thanks.

30

She might not see it here, your best bet is to send a reply to the original (automated) email response that you got when you sent your first email. (It keeps everything in one place, notifies them again, and is easier for them to track.)

31

Thanks for your suggestion. I’ve sent an e-mail as you recommended.

1 Like
32

Our initial attempts at vector uploads to GFUI had only about 3 colors. So I don’t think “too many colors” was the reason for our uploads to be rejected.

“Zipping back and forth over the whole sheet” only applies to rastering over the whole sheet; it doesn’t apply to our initial vector uploads (prior to the revision 7 that I uploaded at the start of this thread) that consisted only of text in a large font size. Some revisions did have raster elements (a gradient that got converted by GFUI to a solid color) but these weren’t a large percentage of the full bed size, and were all the same color.

I think the phrase “(even vector shapes)” is inaccurate; a vector step in GFUI, unless that vector step is remarkably complex, is not likely to take as long as rastering over the whole bed area. See next paragraph.

I notice this to be true, for instance, during vector cutting of the phone number at the bottom of my local makerspace’s business card.

This is good advice for vector engraving. As I’ve noted, vector engraving is important & valuable because it’s usually faster than raster engraving. Some users may also prefer the smoother look of vector engraving.

If the user doesn’t want to design-rule-check their drawing to make sure fills aren’t used where harmful & are used where required, or if the drawing is still rejected by GFUI, then rasterizing may be an option.

If area fill (non-white) is specifically desired within a vector object (such as text), then that object will have to be rasterized somehow. I have found that doing this during Inkscape export to PDF seems to be easier than expecting GFUI to do it.

33

Earlier in this thread, I provided a rasterize filter for Inkscape; I’ve now fixed an error in this filter.

The previous version of the filter worked correctly only for opaque rectangles that were aligned with the drawing’s horizontal & vertical axes.

For any other kind of drawing object, the previous filter would leave transparent pixels (needed to pad the outline of the drawing object to a raster rectangle) as transparent, which would then get converted by GFUI to black. So, for example, black text would be laser-engraved as a filled-in black rectangle.

The solution was to “Merge” into the filter a “Flood-fill” of opaque white. This way, any transparent pixels in a non-rectangular drawing object are rasterized as opaque white, which GFUI then interprets as transparent (no laser power). It’s still a very simple filter, and it now works with any shape of drawing object, including text.

If a drawing object has partly transparent pixels, the filter will blend those with opaque white in the obvious way, and the laser output should still be what you expect.

I made this fix a while ago, but only now have I had time to upload the corrected filter to this thread.

The attached .zip file contains both the corrected & previous filters as 2 separate SVG files, with their names & descriptive text updated so users can tell the 2 filters apart from each other. (The descriptive text appears in the Inkscape status bar as noted in an earlier posting.) I’m including the original filter in case anyone ever has a (non-Glowforge) use for leaving transparent pixels transparent during rasterization. There are 2 separate files so that if people want to install only one filter, they can do so without needing to edit the SVG files. The correct filter to use now for Glowforge is called “glowforge-rasterize”. The SVG files should be put into the appropriate Inkscape configuration folder as noted earlier in this thread.

inkscape_rasterize_filters.zip (1.5 KB)

34

At my local makerspace, we used the attached files to check whether GFUI combines overlapping rasterized objects into a single raster. The answer is no, it does not; “time stacking” applies to both raster objects & vector objects.

To confirm this, we had to send the design to the Glowforge machine, not just upload the design to GFUI. This is because, if you try to separate the individual steps to different areas of the machine’s workspace by using drag-and-drop in GFUI, the steps stay together, implying they’ve been merged by GFUI into one raster.

The test is: Does the laser make one pass over the area in the middle where the 2 squares overlap, or two passes? It makes two passes, meaning that the 2 squares are sent by GFUI to the laser cutter as 2 separate rasters.

Overlapping rasterized objects.svg.zip (1.7 KB)

Overlapping rasterized objects.pdf (5.0 KB)