Import SVG file content into a string variable
Dear all,
I am using BOSL2 to extrude quite complicated shapes from paths that I create with pathbuilder from svg-strings that have been exported from a 2D CAD program (QCAD).
My current workflow is: export the svg -> open the svg with a text editor -> copy the contents of the <path d=".."> attribute into an OpenSCAD string variable -> process with pathbuilder -> extrude with offset_sweep
What I am aiming for:
I'd like to write in OpenSCAD a light-weight parser library that is capable of finding the first / any <path> element in the svg and extracting the content of its d attribute to avoid the tedious copying of the string and to allow for processing the files by non-programming-affine people. I am sure this can easily be done as long as the svg string is available in a variable.
What I already did:
I have read about OpenSCAD's svg import as well as the discussion about importing text files at Github: https://github.com/openscad/openscad/issues/6358
I have further figured out that text files can be imported like this:
stringVar = str(include<test.txt>);
IFF the text in test.txt is surrounded by double quotes ( " ) AND does not contain any other double quotes. This doesn't help with unmodified svg files since they surround their attributes with double quotes.
Nonetheless, neither brought me closer to a solution.
Do you have a suggestion how it can be achieved? Is there a function of the svg import I am not aware of that is capable of importing text (or could be abused in that way)? Is there already a library that can do? Using scripts outside OpenSCAD is not sufficient since that wouldn't be handleable by certain people I am working with.
Best, Thomas
No, there is no easy way to do this. The best that you can do is to
write some external pre-processor that massages the data as required to
fit into one of the few ways to get data into OpenSCAD.
You mention str(include<foo.svg>). If you can assume that the file has
double quotes wrapped around the contents, you don't need the str() -
the content is already a string. But more generally, this is an
incredibly risky technique, assuming that the text of one language will
be valid input for another, even as a constant string. You already
found the two most obvious problems: (a) that SVG files do not come
wrapped in double quotes, and (b) that SVG files make their own use of
double quotes that breaks parsing them as OpenSCAD strings. But then
there are subtler issues. Offhand: backslash is magic to OpenSCAD, but
not to XML. An XML document can have the string "\" in it, and it
means what it says: two backslashes. OpenSCAD will see that and
interpret it as an escape sequence that should be interpreted as a
single backslash, silently corrupting your data. You can use this
technique in some very limited cases, where the form of the input is
constrained so that it is legal to both languages and has the same
meaning in both languages. This isn't one of those cases.
Whatever you end up doing, know that XML is not easy to parse
correctly. Use a dedicated XML-parsing tool or library. You might be
able to get something that sort of works most of the time, but it's
likely that there will be cases where it falls on its face. (Corollary,
not applicable here: it's also not easy to generate correctly.)
There's a good example of using Python to parse SVG path strings at
https://stackoverflow.com/a/56913776
That would make a good base for generating a SCAD file that you could
include.
On Wed, Sep 16, 2026 at 11:34 AM Jordan Brown via Discuss <
discuss@lists.openscad.org> wrote:
No, there is no easy way to do this. The best that you can do is to
write some external pre-processor that massages the data as required to
fit into one of the few ways to get data into OpenSCAD.
You mention str(include<foo.svg>). If you can assume that the file has
double quotes wrapped around the contents, you don't need the str() -
the content is already a string. But more generally, this is an
incredibly risky technique, assuming that the text of one language will
be valid input for another, even as a constant string. You already
found the two most obvious problems: (a) that SVG files do not come
wrapped in double quotes, and (b) that SVG files make their own use of
double quotes that breaks parsing them as OpenSCAD strings. But then
there are subtler issues. Offhand: backslash is magic to OpenSCAD, but
not to XML. An XML document can have the string "\" in it, and it
means what it says: two backslashes. OpenSCAD will see that and
interpret it as an escape sequence that should be interpreted as a
single backslash, silently corrupting your data. You can use this
technique in some very limited cases, where the form of the input is
constrained so that it is legal to both languages and has the same
meaning in both languages. This isn't one of those cases.
Whatever you end up doing, know that XML is not easy to parse
correctly. Use a dedicated XML-parsing tool or library. You might be
able to get something that sort of works most of the time, but it's
likely that there will be cases where it falls on its face. (Corollary,
not applicable here: it's also not easy to generate correctly.)
OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org
Okay, I understand. I can't use a preprocessor. The people I want to give this tool to currently don't even want to export the SVG file from their CAD software themselves. Not to mention running shell scripts or anything like that. I could create a browser-based web service for this, but that would be a slight case of overbombing in the moment.
The escape sequence problem could be solved if a text file wouldn't be imported as plain text but into a byte or character array. In a second step - that wouldn't have to be part of the import function - one could analyze the byte array, escape all critical characters properly, and export the result as a string. This is just an idea I want to throw in, not a requirement to get that implemented.
Am 16.09.2026 um 18:34 schrieb Jordan Brown openscad@jordan.maileater.net:
No, there is no easy way to do this. The best that you can do is to write some external pre-processor that massages the data as required to fit into one of the few ways to get data into OpenSCAD.
You mention str(include<foo.svg>). If you can assume that the file has double quotes wrapped around the contents, you don't need the str() - the content is already a string. But more generally, this is an incredibly risky technique, assuming that the text of one language will be valid input for another, even as a constant string. You already found the two most obvious problems: (a) that SVG files do not come wrapped in double quotes, and (b) that SVG files make their own use of double quotes that breaks parsing them as OpenSCAD strings. But then there are subtler issues. Offhand: backslash is magic to OpenSCAD, but not to XML. An XML document can have the string "\" in it, and it means what it says: two backslashes. OpenSCAD will see that and interpret it as an escape sequence that should be interpreted as a single backslash, silently corrupting your data. You can use this technique in some very limited cases, where the form of the input is constrained so that it is legal to both languages and has the same meaning in both languages. This isn't one of those cases.
Whatever you end up doing, know that XML is not easy to parse correctly. Use a dedicated XML-parsing tool or library. You might be able to get something that sort of works most of the time, but it's likely that there will be cases where it falls on its face. (Corollary, not applicable here: it's also not easy to generate correctly.)
On 9/16/2026 1:23 PM, Thomas Richter wrote:
The escape sequence problem could be solved if a text file wouldn't be imported as plain text but into a byte or character array.
Sure. It's the "try to just include text in language A as input to
language B's parser" part that's the problem.
But right now there's no way to import an unmodified SVG file as data.
There has been some discussion of adding the ability to import a text
file and return it as a string. There's a bit of concern about security
there, since it might allow an OpenSCAD program to exfiltrate a file
that shouldn't have been leaked, but that's a pretty esoteric attack.
(It's more of a concern for a server installation, where the user
shouldn't be allowed to read random files.)
There's also been discussion of having a way to import an SVG file and
return the contents as structured data. Exactly what that would look
like I don't know, since I haven't looked at SVG in detail. That's what
you would really want. But it wouldn't be trivial, and as far as I know
nobody's working on it, and it's not at or near the top of my personal list.
I teach programming classes at a university and regularly conduct projects with student groups. Furthermore we have a very large FabLab and I am currently setting up an elective course where I plan to teach "programmatic" CAD with OpenSCAD as well as FreeCAD (Python console).
It would be easy to set up a studentic project group that implements an OpenSCAD SVG parser. If I understand it correctly, that would mean to fork the OpenSCAD project and implement as a module of the program rather than what I was planning for - to build it in OpenSCAD directly.
Am 16.09.2026 um 23:35 schrieb Jordan Brown openscad@jordan.maileater.net:
On 9/16/2026 1:23 PM, Thomas Richter wrote:
The escape sequence problem could be solved if a text file wouldn't be imported as plain text but into a byte or character array.
There's also been discussion of having a way to import an SVG file and return the contents as structured data. Exactly what that would look like I don't know, since I haven't looked at SVG in detail. That's what you would really want. But it wouldn't be trivial, and as far as I know nobody's working on it, and it's not at or near the top of my personal list.
On 17.09.26 09:50, Thomas Richter via Discuss wrote:
It would be easy to set up a studentic project group that
implements an OpenSCAD SVG parser. If I understand it
correctly, that would mean to fork the OpenSCAD project
and implement as a module of the program rather than what
I was planning for - to build it in OpenSCAD directly.
No, OpenSCAD already has a SVG parser.
I don't understand the fork and implement as module part.
The short-cut option to get SVG content into a script
in addition to the current (sort-of black box geometry)
would be:
-
Define a data structure that contains the information
-
Hook things up with the (experimental) import function.
This would allow something like
svgdata = import("file.svg");
ciao,
Torsten.
On 9/17/26 03:51, Thomas Richter via Discuss wrote:
OT:
Hello Thomas.This name rings a 3 decade old bell in my memory. You
fixed a compiler mistake for us back in the Amiga's 68060 heyday, and I
was so busy as the CE of an american tv station that I don't recall
saying thank you properly.
Now its 30+ years later, I am nearly done at 91 and I'm saying thank you.
I teach programming classes at a university and regularly conduct projects with student groups. Furthermore we have a very large FabLab and I am currently setting up an elective course where I plan to teach "programmatic" CAD with OpenSCAD as well as FreeCAD (Python console).
It would be easy to set up a studentic project group that implements an OpenSCAD SVG parser. If I understand it correctly, that would mean to fork the OpenSCAD project and implement as a module of the program rather than what I was planning for - to build it in OpenSCAD directly.
Am 16.09.2026 um 23:35 schrieb Jordan Brown openscad@jordan.maileater.net:
On 9/16/2026 1:23 PM, Thomas Richter wrote:
The escape sequence problem could be solved if a text file wouldn't be imported as plain text but into a byte or character array.
There's also been discussion of having a way to import an SVG file and return the contents as structured data. Exactly what that would look like I don't know, since I haven't looked at SVG in detail. That's what you would really want. But it wouldn't be trivial, and as far as I know nobody's working on it, and it's not at or near the top of my personal list.
OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org
.
It would be easy to set up a studentic project group that implements an OpenSCAD SVG parser. If I understand it correctly, that would mean to fork the OpenSCAD project and implement as a module of the program rather than what I was planning for - to build it in OpenSCAD directly.
Like Torsten, I am a bit confused by what you mean here.
Today, OpenSCAD has no mechanism for importing SVG or XML as data. The language and its library do not have the required features.
It would be entirely plausible to add that feature, in the usual way that features are added to OpenSCAD. You do fork the project, temporarily, creating your own copy during your development. You do your C++ development, test, rinse, repeat, and then when you’re ready you file a pull request and we add your changes to the main repository. At that point you can delete your copy, or keep it for future work, as you like.
The hard part here is not likely to be development per se. As Torsten says, we already have an SVG parser supporting the import() module, and even without that we probably have an XML parser around for some reason or other, and even if we don’t there are XML-parsing libraries readily available. (If you needed to implement an XML parser from zero, that would be more of a concern, and was what I was cautioning against.)
The hard part is design. What is an appropriate OpenSCAD data structure for representing an SVG file?
The first obvious answer is, as the message subject suggests, to suck the entire SVG file in as one string. That’s a horrible plan, because it would mean that you would have to write a new XML parser in OpenSCAD-language. We might want such an importer for other purposes, but it’s not a good answer for this problem.
The next obvious approach would be to write an XML importer, representing arbitrary XML as OpenSCAD data. That’s probably worthwhile regardless. But is that the right final answer for SVG? Maybe the structure of SVG should be distilled down a bit from the full richness of XML - I’m not familiar enough with SVG to be sure. Probably it would be good to parse SVG’s compact path representation, rather than returning SVG paths as plain strings. If so, what’s the right representation? Perhaps it would be good to offer that path-string parser as a separate feature. How do you design the representation so that it is very likely to handle the not-yet-designed next generation of SVG? Et cetera.
Jordan, what am I missing? An SVG is a vector graphics format, so it
represents a collection of point sequences defining paths in 2d space. The
obvious import format is a list of such point lists. It's obviously
idiotic to import SVG as a string. The way that you handle the next
generation of SVG is you recompile OpenSCAD with the updated SVG reading
library, which is already in OpenSCAD because the import() module turns an
SVG into geometry. So it's gonna fail the exact same way on the next
generation of SVG.
On Thu, Sep 17, 2026 at 11:29 AM Jordan Brown via Discuss <
discuss@lists.openscad.org> wrote:
It would be easy to set up a studentic project group that implements an
OpenSCAD SVG parser. If I understand it correctly, that would mean to fork
the OpenSCAD project and implement as a module of the program rather than
what I was planning for - to build it in OpenSCAD directly.
Like Torsten, I am a bit confused by what you mean here.
Today, OpenSCAD has no mechanism for importing SVG or XML as data. The
language and its library do not have the required features.
It would be entirely plausible to add that feature, in the usual way that
features are added to OpenSCAD. You do fork the project, temporarily,
creating your own copy during your development. You do your C++
development, test, rinse, repeat, and then when you’re ready you file a
pull request and we add your changes to the main repository. At that point
you can delete your copy, or keep it for future work, as you like.
The hard part here is not likely to be development per se. As Torsten
says, we already have an SVG parser supporting the import() module, and
even without that we probably have an XML parser around for some reason or
other, and even if we don’t there are XML-parsing libraries readily
available. (If you needed to implement an XML parser from zero, that would
be more of a concern, and was what I was cautioning against.)
The hard part is design. What is an appropriate OpenSCAD data structure
for representing an SVG file?
The first obvious answer is, as the message subject suggests, to suck the
entire SVG file in as one string. That’s a horrible plan, because it would
mean that you would have to write a new XML parser in OpenSCAD-language. We
might want such an importer for other purposes, but it’s not a good answer
for this problem.
The next obvious approach would be to write an XML importer, representing
arbitrary XML as OpenSCAD data. That’s probably worthwhile regardless.
But is that the right final answer for SVG? Maybe the structure of SVG
should be distilled down a bit from the full richness of XML - I’m not
familiar enough with SVG to be sure. Probably it would be good to parse
SVG’s compact path representation, rather than returning SVG paths as plain
strings. If so, what’s the right representation? Perhaps it would be good
to offer that path-string parser as a separate feature. How do you design
the representation so that it is very likely to handle the not-yet-designed
next generation of SVG? Et cetera.
OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org