I’ve been making lots of things… and so far so great… until today. I’ve been using files with vector lines in multiple colors to make different Manual Cuts with different settings. Always worked so far.
But for some reason with my new file, it only gives me the option of Manual Engrave.
I compared two files - one that goes to cut menu and one that goes only to engrave:
The files are the same type -pdf
The lines are using the same 2 colors, same thickness, and no fill.
Same number and size of objects/paths.
I even took one that wasn’t working… simplified it to 2 circles… didn’t work. I redrew those circles over the exact same spot… removed the original and the new circles work fine. I’ve tried copying and pasting the non-working ones into a new document.
The real file I want to cut has a bunch of objects - so I don’t want to have to redraw it. But clearly it isn’t the number of objects, because just using even one object from the non-working file doesn’t work.
What kind of objects are they in the pdf? Rasters don’t cut as a rule. I don’t use pdfs much, I stick with SVGs, so I am not of much help… but if it’s an embedded raster in you pdf it would probably force engrave, if it’s like SVG that way…
Using Illustrator CC2015 on a Mac. Vector lines. Here’s 2 of the simplified files - circletest.pdf , which opens Manual Engrave (ie. doesn’t work), and circeltest-redrawn.pdf that will give me Manual Cut with different settings for each color(works).
i can’t see any difference between the two files, that’s really odd. i even tried re-exporting with my glowforge preset for acrobat and it made no difference. loaded them in GFUI and had the same results.
i honestly haven’t seen anything like that before. and, as mentioned above, i use PDF almost exclusively, with one exception where a complex file just wouldn’t load in GFUI and i made an SVG instead and it did.
I also use Illustrator CC and have encountered the same problem. What I’ve discovered is your stroke to cut defaults to “Align Stroke Inside”… when you align your stroke to inside or outside, Glowforge interprets it as an Engrave.
Fix: Align stroke to middle and cut should work again.
Did you pull them into Inkscape (or whatever tool you use) and make them SVGs? Something in me says that GF translates everything into SVGs (there isn’t a separate code path for PDF or DXF or whatever) and then processes it. They might generate different SVGs and we’d have something along the lines of the winding path rule they don’t support that would be helpful to know about.
when i had the job that just wouldn’t load (only problem i’ve had with PDFs, and just the one time), i just went back to my source illustrator file and exported as SVG instead.
The strokes were aligned correctly… but… it made me think of opening the Document Info window in Illustrator and look at all the objects… and it pointed out that one of the circles had transparency set!! I could still see the object, so I forgot about it… but once I turned that off it works again!!
So thanks for the nudge that pushed me to find the answer!
Super interesting. It almost needs to be added to some guide, @jules, you know of any tutorials that would need to be updated to talk about transparencies in PDFs? Is there a “everything about PDFs” post I never saw?
We haven’t added anything about PDFs other than a general statement that they can be opened in the interface.
@dan has repeatedly said that SVGs are a lot more “known” to the interface and easier for the interface to interpret correctly.
PDFs are necessary sometimes, due to the winding issue on certain CorelDraw files, but they’re not encouraged right now. So we haven’t done any tutorials on them that I know of.
I use a lot of PDFs and the main thing I run into is that embedded bitmaps that use transparency tend to turn into opaque images with clipping paths when saved as as PDF. I’m not sure whether that’s a PDF thing in general, or just an Affinity Designer thing. But it often results in black areas in images that should be transparent. (The fix is to make all the transparent areas white, or to just save as SVG if there isn’t some other reason to be using PDF.) Yet another reason I’m hoping GF supports clipping paths properly sooner rather than later.
Edit: On further examination this isn’t a clipping path issue. (The GF just doesn’t correctly handle transparent images embedded in PDFs.)
AD has a Geometry->Subtract function for subtracting one closed path from another closed path. I believe it works identically to the equivalent Pathfinder Subtract operation in Illustrator. (It may have somewhat different behavior on non-closed paths, but both programs have weirdness there.) What AD really lacks is something like the scissors or knife tools in Illustrator. That’s where I tend to end up wanting to use clipping paths.
But what I’m talking about here is something different, although oops, on further examination it looks like clipping paths aren’t actually the problem. (The spurious clipping path warnings that the GFUI likes to display had just made me assume that they were the problem.) If you have a transparent PNG (say an opaque orange triangle on a 100% transparent background) and you embed it in an SVG, no problem. But if you instead export it as a PDF, the resulting bitmap embedded in the PDF doesn’t have its transparency show up correctly in the GFUI.
I had thought that AD was converting the image to an opaque image and using clipping paths to clip out the parts that shouldn’t be opaque, but closer examination of the PDFs shows that this isn’t what’s happening. It looks like AD is generating PDFs just fine, correctly preserving the alpha channels in the embedded PNGs. It’s just the GFUI that’s failing to interpret them correctly. It looks like the GFUI has trouble with PDF’s “SMask” feature for handling alpha channels.
I need to make some test cases and submit them to support.
Thanks for the help, all! I’m going to close this thread - if the problem reoccurs, go ahead and post a new topic. Thanks for letting us know about this - I’ve let the team know.
