Import SVG file content into a string variable
Could this be easier with PythonSCAD? I've only spent a little time
working with it and might be mistaken but I expect one could make a
PythonSCAD function that reads an .svg file and returns a BOSL2 path or
region and does so utilizing already written python SVG parsers. Then one
ought to be able to build their OpenSCAD project with BOSL2 exactly as
before but at the top of say main.scad in addition to "include
<BOSL2/std.scad>" one would add "use <MYPYSCAD/svgimport.py>" to make the
function callable from their OpenSCAD code.
On Thu, Sep 17, 2026 at 10: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
too much to think about...
and development is 'continuous'
On 17/09/2026 18:31, Adrian Mariano via Discuss wrote:
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
OpenSCAD mailing list
To unsubscribe send an email todiscuss-leave@lists.openscad.org
On 9/17/2026 10:31 AM, Adrian Mariano via Discuss wrote:
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.
It represents an enormous amount more than that. It's a document
format. It has semantic information.
As a trivial example: a rectangle is not just four points. It is a
rectangle, with whatever that semantically means. It has a fill style,
and it has a stroke style, and a unique identifier.
Add an ellipse. It's a mathematical ellipse, with a center and two
radii, not a list of points. The rectangle might be in front of the
ellipse, or behind it. It might be grouped with the ellipse, with
whatever user-level semantics that implies.
Saying "it's just points and paths" is like saying "OpenSCAD is just
polyhedra". SVG is not a full programming language, but it is a very
rich drawing representation. Perhaps there should be an import
mechanism that distills an SVG down into a list of lists of points, but
calling that an SVG importer is like saying that you can convert
OpenSCAD into STL, so an STL importer is an OpenSCAD importer.
Play with Inkscape and look at its capabilities and the SVGs that it
creates. Note that Inkscape uses SVG as its native document format -
not as an export format.
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.
The question was not how the OpenSCAD implementation evolves - that will
depend on a zillion factors, most of them internal.
The question was how your imported data structure evolves, so that it
can represent new constructs while not breaking old OpenSCAD-language
consumers reading old files.
Suppose that SVG 0.1 was just points built into paths. Your import
format is a list of lists of points.
Now SVG 0.2 comes along and lets you say that a path is closed and the
polygon can be filled. Where does that information go into your import
format?
SVG 0.3 adds Bézier curves. How are those added?
Et cetera.
As much as possible, this import representation needs to be defined so
that an SVG 0.1 consumer reading SVG 0.1 files will still work, even
when we're supporting SVG 1.0 in all of its richness, and the
representation of an SVG 1.0 file should look familiar to somebody who
has been importing SVG 0.1 files. We shouldn't have had to invent a new
import representation for each iteration. The problem is made easier by
the fact that SVG itself is designed for extensibility, so if your
representation basically follows the structure of SVG then there's a
good chance that it will easily and compatibly extend to the next version.
On 9/17/2026 10:56 AM, Todd Allen via Discuss wrote:
Could this be easier with PythonSCAD?
Absolutely. There are multiple Python libraries for reading SVG files.
That's the big upside of PythonSCAD and similar efforts, that they have
huge ecosystems of tools available.
There are in my mind two downsides:
- The simplest OpenSCAD program is "cube();". I don't know what the
minimum PythonSCAD program is, but more than that. - This (or something like it) is a legal PythonSCAD program:
o open(".profile", "w").write("rm -rf $HOME")
I cannot overstate the importance of that latter point. You must be
paranoid about what you download. If you think this is a completely
abstract fear: Blender has Python integration capabilities, and has
been attacked https://www.google.com/search?q=blender+python+attack.
<
- This (or something like it) is a legal PythonSCAD program:
-
- open(".profile", "w").write("rm -rf $HOME")
And yet somehow (PyPI?) Python still gets used, possibly even more than
OpenSCAD.
On Thu, Sep 17, 2026, 1:57 PM Jordan Brown via Discuss <
discuss@lists.openscad.org> wrote:
On 9/17/2026 10:56 AM, Todd Allen via Discuss wrote:
Could this be easier with PythonSCAD?
Absolutely. There are multiple Python libraries for reading SVG files.
That's the big upside of PythonSCAD and similar efforts, that they have
huge ecosystems of tools available.
There are in my mind two downsides:
- The simplest OpenSCAD program is "cube();". I don't know what the
minimum PythonSCAD program is, but more than that.
- This (or something like it) is a legal PythonSCAD program:
- open(".profile", "w").write("rm -rf $HOME")
I cannot overstate the importance of that latter point. You must be
paranoid about what you download. If you think this is a completely
abstract fear: Blender has Python integration capabilities, and has been
attacked https://www.google.com/search?q=blender+python+attack.
OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org
On Sep 17, 2026, at 12:38 PM, Todd Allen via Discuss discuss@lists.openscad.org wrote:
<
This (or something like it) is a legal PythonSCAD program:
open(".profile", "w").write("rm -rf $HOME")
And yet somehow (PyPI?) Python still gets used, possibly even more than OpenSCAD.
Yes, and malware HAS been spread that way. Worms that a developer will download, that will then infect whatever packages they provide to PyPi. You should be afraid.
- Revar
You should be afraid.
I am. Which is why I use Qubes. And virtual environments inside virtual
machines. And hashes. And backups.
On Thu, Sep 17, 2026, 2:56 PM Revar Desmera revarbat@gmail.com wrote:
On Sep 17, 2026, at 12:38 PM, Todd Allen via Discuss <
discuss@lists.openscad.org> wrote:
<
- This (or something like it) is a legal PythonSCAD program:
-
- open(".profile", "w").write("rm -rf $HOME")
And yet somehow (PyPI?) Python still gets used, possibly even more than
OpenSCAD.
Yes, and malware HAS been spread that way. Worms that a developer will
download, that will then infect whatever packages they provide to PyPi.
You should be afraid.
- Revar
On 9/17/2026 12:37 PM, Todd Allen via Discuss wrote:
<
- This (or something like it) is a legal PythonSCAD program:
- o open(".profile", "w").write("rm -rf $HOME")
And yet somehow (PyPI?) Python still gets used, possibly even more
than OpenSCAD.
Certainly more. But there is, I hope, a cultural difference. In the
3DP world and the OpenSCAD world, it's routine to grab a model that some
random guy posted on Thingiverse or Printables, and run it. That's more
or less safe with OpenSCAD, because (absent bugs that would be tricky to
exploit) it can't do anything malicious. I expect that Python
developers are at least somewhat more discriminating in what they
download and run.
I am [afraid]. Which is why I use Qubes. And virtual environments
inside virtual machines. And hashes. And backups.
Sure. And those are the sorts of precautions that you need to take if
you run untrusted Python programs. But unless you are exceptionally
paranoid you don't need to take those sorts of precautions running
OpenSCAD programs.
All I'm saying is that it would be tempting to say "PythonSCAD is just
OpenSCAD with Python", and treat it like OpenSCAD. What you need to say
is "PythonSCAD is Python with OpenSCAD", and treat it like Python.
To be clear: I don't want to seem down on PythonSCAD and similar
efforts. I would really like to see an OpenSCAD-like tool based on a
generic language, rather than having to live with the limitations of a
specialty language, and having to reinvent wheels that have been
invented numerous times before. But sandboxing is very important in the
bigger picture, and the only effective ways to sandbox Python are very
inconvenient for users. You must be paranoid if you want to be safe.
Dear Maurice,
Thank you very much for the compliments, but the credit doesn't go to me. Although I did live in the U.S. for a year around 1997 and also developed software for the Motorola 68000, I honestly can't recall ever working for a for-profit company while employed by a university.
Best,
Thomas
Am 17.09.2026 um 13:14 schrieb maurice e heskett via Discuss discuss@lists.openscad.org:
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
.
OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org
Maybe I get you wrong. As far as I can tell
svgdata = import("file.svg");
curently doesn't work. At least OpenSCAD 2026.09.18 with enabled Experimental: import-function throws a warning: WARNING: Unsupported file extension '.svg' while trying to import 'path_outline.svg' in file test-svg.scad, line 1
So, to my understanding, to achieve what you're describing, I'd have to extend the OpenSCAD application itself. To me that would mean to fork the code and create a new module that is capable of importing svg the way I need it. Regardless of how the svg string is being processed afterwards. For the time being I'd be satisfied with the possibility to just read the d-attribute of <path> elements and throw them at pathbuilder to get a path that could then be processed by the BOSL2 functions.
Am I getting you wrong?
Am 17.09.2026 um 12:15 schrieb Torsten Paul via Discuss discuss@lists.openscad.org:
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.
OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org