I really appreciate the time it took to details all of that process.
I’m curious though as to why you are using a PDF (and all these steps) vs just using an Inkscape SVG file with the Raster embedded?
I really appreciate the time it took to details all of that process.
I’m curious though as to why you are using a PDF (and all these steps) vs just using an Inkscape SVG file with the Raster embedded?
Our design uses the outline of some of the text as a vector cut path, and GFUI requires cut paths to stay in vector format, which means we can’t just rasterize that text to keep GFUI from detecting & deleting that text. Being unable to express any text in vector form would be a disappointment anyway.
Once the filter is added to Inkscape, the process for print-and-cut is just:
A. Design the SVG file with engrave items on one layer & cut items on another layer. Many graphic designers would probably do this anyway without thinking about it, AND this step is totally optional; I just mention it for convenience.
B. Anything that is supposed to be engraved and isn’t already in raster form, apply the “rasterize” filter to it. “Already in raster form” could include a JPEG photograph, etc.
C. Begin the PDF export. (I do this by using menu item File > Save A Copy… and making sure the filetype is PDF.)
D. Make sure the options in the PDF export dialog are set correctly. Verifying the DPI setting is optional; the print-and-cut will probably work just fine with any DPI value of at least 72 or so. So the only setting that absolutely needs to be verified is the “Rasterize filter effects” checkbox. AND once you have chosen any settings in the PDF export dialog, they stay that way on future uses of the dialog. AND I think that most people don’t have any reason to uncheck that checkbox when they export any PDF from Inkscape for any purpose, which means the settings would still be correct the next time the person does a print-&-cut, even if the person doesn’t think to verify the settings.
E. Once the PDF is exported from Inkscape, the process for uploading to GFUI isn’t any different than uploading an SVG. Also, having a PDF copy of the design can be handy for other purposes, such as looking at it in a PDF viewer without the chance of mistakenly editing something (“mistakenly editing” might happen if you open the original SVG in Inkscape just to look at the design).
Which means that the only 2 steps that need any attention, after the user learns this procedure the first time, are B & C.
In Inkscape, click on the text to select it, then click Path> Object to Path.
And there is no more Text error message. (In other words, all you have to do is convert the Text to paths, and it will Engrave just fine. One step.)
If you then want the Text to Cut instead of Engrave, just set the Fill color to Null, and give it a stroke color.
If you prefer to continue to do it the way that you are doing it, you can. But there is an easier way to deal with it. If you then Embed the raster image into the file and save it as an SVG, you’ll probably save some steps, and a few incorrectly loaded files.
I believe we tried “Object to Path” and the resulting SVG file was too complex for GFUI. Also, it felt like quite an affront to be told that SVG files aren’t allowed to have text. (Now that I think about it further, maybe this is because fonts aren’t usually embedded into SVG like they are into PDF. It is still inconvenient.) We switched to PDF because the GFUI doesn’t have this “no-text” limitation with PDF.
For people who want to convert all their text to paths, there is an even quicker way than:
Namely, use PDF export, and in the PDF-export dialog box, turn on the “Convert texts to paths” checkbox. As mentioned in an earlier post, Inkscape will preserve the setting of this checkbox for future PDF exports.
Using this checkbox prevents “Oops, I forgot to click on that text and convert it to a path.”
There is no raster image to Embed, since the artwork was designed in Inkscape in vector form.
The “rasterizing filter” approach also makes vector-graphics style issues such as those mentioned at the end of marmak3261’s post totally moot. In other words, it makes the design process WYSIWYG, which is what people want & expect.
I’m guessing that by “incorrectly loaded files” you are referring to files that GFUI doesn’t handle as expected. I will leave that train-of-thought here unless someone wants to continue it.
I’m not ruling out the use of vector engraving, but our file when uploaded to GFUI in 100% vector format was too complex for GFUI to handle, so we had to find another way.
Our “rasterize-filter” process:
Again, I agree that vector engrave makes sense for designs that are simple enough.
A previous version of our design file in question had gradient fills, which, as I recall, GFUI doesn’t accept in vector format at all. But raster format can represent gradient fills with no problem.
Too complex from what standpoint?
Re: your resolution, you’ll be missing out on some quality. You should shoot for 2x your desired LPI.
Too complex in the sense that GFUI refused to engrave it.
As for your resolution comment, we can try exporting @ 450 dpi & observe how it compares to exporting @ 225 dpi. Thanks for the suggestion.
We have been leaving GFUI’s lines-per-inch at the default of 225 because we assumed the Glowforge company had found that any higher setting wouldn’t provide any noticeable improvement (but would slow down the engraving).
And what was the specific error?
There are two ways it can generally go: it can tell you your design has a lot of colors, which means it creates separate jobs for each color. Or, it can tell you the design is complex, and to break it up - which generally means that it’s going to take a long time to perform the engrave (several, several hours).
Nothing wrong with doing it how you are doing it - rasterizing is just fine if you rasterize to a sufficient resolution, but reading your steps made me cringe because it’s making it way more difficult than it really is.
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:
rasterizefilter 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
rasterizefilter is applied can be as simple as selecting everything on your “engrave” layer and selecting the
rasterizefilter from the top of the Filter menu. (You can even use a keyboard shortcut for the submenu if you want. Also, you might have named the layer something like “raster_engrave” if you also have a “vector_engrave” layer.)
rasterizefilter 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
rasterizefilter applied to the group, whereas if you Ungroup and re-Group the group, you would have to re-apply
rasterizefilter 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.)
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.
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.
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 email@example.com.
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.
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.
Noticeable differences in my tests, and in reality.
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.
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.
rasterize filter, no resizing is needed. The raster output from Inkscape always registers perfectly with the vector lines on the other layers.
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.
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.
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:
rasterizefilter applied, and that things you want vector-cut/engraved/scored do not have that filter applied. Bitmaps (photos etc.) don’t need the
rasterizefilter, since they’re already in raster format.
When revising the design:
rasterizefilter 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
rasterizefilter 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).
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:
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.
Except that you cannot engrave the interior of a no-fill object, rectangle or otherwise.
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.
(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:
raster_engraverectangle to have fill (white). (The stroke is left unchanged.)
rasterizefilter to the
raster_engravelayer be the only one visible.
vector_engravelayer be the only one visible.
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)