Papyrus Font SVG issue details - nailed it

So believe it or not, it is a specific letter of the papyrus font. It is the capital N produces an unsliceable file. I validated the XML (it’s really, really simple with just one letter on screen, I could hand validate it for that matter). Now I emailed @rita who suggested trying the “Save As” rather than “Export” in AI. Yep, the save-as one works fine, the export does not, and only when an N is on the screen does this make a difference! So in looking (and diffing) the XML of the SVGs it appears to be a line wrap issue? I will let @Rita figure out why this causes a problem in slicing.

for anyone who cares here is the bad one (export as):

<svg id="Layer_1" data-name="Layer 1" xmlns="" width="20in" height="12in" viewBox="0 0 1440 864">
          .cls-1 {
            fill: #006838;
      <path class="cls-1" d="M729.87,426.74a.83.83,0,0,1-.43.37,3.14,3.14,0,0,1,.27.72l-.08,1.6.08,1.27-.23.92.08,1.29-.12,1.8.12,1-.12.68.08,1.84,0,.53-.12-.2q-.33.25-.33.47,0,.39.57.76a5.36,5.36,0,0,1,.16,1.07,3.64,3.64,0,0,1-.3,1.47,15.38,15.38,0,0,1-1.1,1.94l-.27.43-.76.45-.16-.45-.92-1.41-1.17-1.46-.88-1.52-.31-.41.08-.43q0-.47-.68-1a9,9,0,0,1-1.07-1l-1.07-1.91-.57-.68-.35-1a1.24,1.24,0,0,0-1.25-.8l-.23-.47-1.13-1.86-.31-1-.64-.72-.12.16-.31-.2a7.46,7.46,0,0,0-2.56-2.91,2.66,2.66,0,0,0,.16-.72q0-.49-.37-.49l-.43.16a.85.85,0,0,0-.53-.31l-.,426l.12.31-.16.84.08,1.68-.12.57-.33.16,0,.47.33,1.13,0,0v0a2,2,0,0,1-.49,1l.,1.68v0a.33.33,0,0,1,0,.1l-.23,1.11,0,.23c.,6.07,0,0,1-1,1.64l-.23.35-.45,0c-.25.3-.45.45-.61.45h0l-.43,0-.33.08,0-.49a1.83,1.83,0,0,1,.18-.72l.43-.55.33-.49-.45-.39.12-.45.23-.57a4.67,4.67,0,0,1-.2-.66l0-.07a.21.21,0,0,0,0-.07l.29-1-.1-2.25a.9.9,0,0,1,.61-.39V437l-.43-.53.08-.43-.08-.41.12-1.11a.08.08,0,0,0,0,0l0,0-.25-.84.14-1.13-.08-.8q0-.39.55-.76l0-.47-.27-.64a2.06,2.06,0,0,1,.12-.57.82.82,0,0,1-.35-.62,5.44,5.44,0,0,1,.23-1.21l-.2-.27,0-.57-.18-1.35a2,2,0,0,1,.18-.57v-.45a2.94,2.94,0,0,0-.21-1.46l-.88-1.09.16-.43.49-.29a4.08,4.08,0,0,0,.68-.45,1.21,1.21,0,0,0,.31-.51l.33-.2.92-1.07a.32.32,0,0,1,.23-.08.75.75,0,0,1,.68.55l.88,,9.64,0,0,1,1.23,1.76l1,1.68a2.89,2.89,0,0,1,.,0,0,1-.18.43l.8.45-.,,1.76,1.88-.37.2a1,1,0,0,0,.25.52,1.45,1.45,0,0,0,.63.21l.92,1.27-.27,0,.53.37a3,3,0,0,1,.7.63,1.73,1.73,0,0,1,.21.74l.27.27,0,.27a1.89,1.89,0,0,0,.27.92l.45.29a5.47,5.47,0,0,1,.88.43l.84,,0-2.36.41-1a1.2,1.2,0,0,1-.41-.76.66.66,0,0,1,0-.27l.25-.8.12-2.79.31-.61-.23-.61.16-.92v0c0-.17-.16-.32-.47-.45l-.1-5.08a.46.46,0,0,0,.36-.15,1.24,1.24,0,0,0,.13-.52l-.61-.45-.08-.68a3.73,3.73,0,0,0-.24-,0,0,0-.6-.27,2.15,2.15,0,0,1-.08-.47q0-.72,1.68-1.15a2.43,2.43,0,0,1,.48-.57,5,5,0,0,1,.89-.45,1.43,1.43,0,0,1,.23.72l-.,0,.76,0,1.64a2.67,2.67,0,0,1-.12.84l-.16.8v0l.31,1.29-.08,1Z"/>

Here is the good one (save as):

<?xml version="1.0" encoding="utf-8"?>
    <!-- Generator: Adobe Illustrator 21.1.0, SVG Export Plug-In . SVG Version: 6.00 Build 0)  -->
    <svg version="1.1" id="Layer_1" xmlns="" xmlns:xlink="" x="0px" y="0px"
    	 width="1440px" height="864px" viewBox="0 0 1440 864" style="enable-background:new 0 0 1440 864;" xml:space="preserve">
    <style type="text/css">
    	<path class="st0" d="M729.9,426.7c-0.1,0.1-0.2,0.3-0.4,0.4c0.2,0.4,0.3,0.6,0.3,0.7l-0.1,1.6l0.1,1.3l-0.2,0.9l0.1,1.3l-0.1,1.8

This rule applies to Photoshop when saving PNGs. save-as breaks transparencies and changes the bit depth of the file vs. export / export quick PNG preserves the file. Non-GF related issue. I just notice this when making full color vinyl stickers a couple months back.


I never have had that issue, and I use export all the time with PNGs

1 Like

Wow, great detective work! I always do Save As, so at least in this case it may have saved me some grief.


There are lots of little quirks in how SVG files are saved or interpreted. I know that the Glowforge is eventually supposed to read a lot of different formats but every time someone says it should be easy, makes me cringe. Will the problems be in how an original program saves the SVG or is it in the interpreter? There are so many versions. Here’s one example I ran across. The image shows the design icons from the Glowforge app. The distorted file engraves as shown. Both files are identical except the distorted one had the image rotated just a couple degrees in Inkscape. They visually look the same on the art board if I re-open the files in Inkscape. Took me two days to chase down the cause.

Edit: I wonder if this is part of the reason the Glowforge app allows you to rotate an SVG but not an uploaded image file? Maybe something that’s stll being refined. Of course I don’t know whether the problem is on the Inkscape side or with the Glowforge app.


I believe that’s in the documentation :grinning:

1 Like

Both SVGs actually load fine in every other program I have tried (including direct load into the browser), so this is essentially some boundary condition in their slicer (I’m sure they have some other name than slicer, but coming from 3D printing, it’s an easy word to use) that they don’t handle.


There’s a lot more in those two SVGs that’s different beyond line breaks. The path data is completely different between the two. While they may render similarly, the actual path is created much differently in each.

E.g. The one that works uses relative bezier curves, whereas the one that doesn’t uses arcs, different math, different path construction.

There’s also fairly major differences that can choke some XML interpreters, such as not having the XML declaration, width/height being in inches instead of pixels, missing xml:space=“preserve”, etc. These things shouldn’t be an issue, but XML interpreters can be finicky.


Which by the way speaks for a really bizarre development process at Adobe. I have 20 places in our programs that spit out a facesheet for a patient. It’s all the same code that produces the PDF. This would seem to imply that 2 different groups wrote completely different SVG creation code inside the same product!!!


Yes, in fact Illustrator specifically says as much in the dialog when you use “save as” for SVG… At least it does for me. It specifically tells me that if I want a web-obtimized file to use “Export” instead.

The “Save As” version builds a more structurally complete file that should maintain finer editing capabilities within the SVG. The exported version really only wants to make something render properly in a browser, with as little code as possible.


Yeah, but the annoying thing about using save-as is that it in fact changes the doc type. Export is nicer as you are making an ongoing document, where you want to for instance do what I did, which was have a puzzle, place text, create outlines, export svg, roll back the outlines, edit text, create outlines, export, rinse-repeat…

Save as actually changes the document to an SVG and saves it out as that…

1 Like

I’m not sure what you mean by this… I save everything in illustrator as an illustrator file, and also save as SVG… in both cases I can continue to make changes, or close a file, open it back up again (.ai, or .svg) and edit it as normal…


Using Save As or Save Copy, with the following settings, should give you a good SVG file from AI. This is how I found to be able to export an SVG and drag-and-drop it into Discourse, without having to do any fiddly bits with the code to have it display correctly and the right size. I would love confirmation that this file saving setup renders well into the GFUI.

From here:


That one works even with the N in the file…


That looks like it would work fine. I’m using a much older version of AI, I Save As an SVG 1.1 with the images embedded.

The only thing I don’t recognize is the convert text to outline, and I don’t see why that wouldn’t work…it just saves a step that I have to perform.

1 Like

Seems to have worked fine, down to automagically converting text to outlines.

No problems with Ns, either. :wink:

The only warning from the UI mentioned that this SVG had lots of colors and reminded me that each one would have to be set manually.

The bounding box is probably user-error. I spent about 2 minutes putting this together in Illustrator (if that).


Awesome, thanks for checking!


You wrote that backwards. In Photoshop, Save As always preserves as much of the document as possible (bit depth, metadata, extra channels, etc.). Export can remove or change the document (ie: reduce the file size for the web, change 16 bit/channel to 8, etc.).