svgdata = import("file.svg");

[*] in the OpenSCAD-language sense, not in the sense of being
add-ons to the application.

On 9/19/2026 9:52 AM, Thomas Richter via Discuss wrote: > Maybe I get you wrong. As far as I can tell > > ``` > svgdata = import("file.svg"); > ``` > > curently doesn't work. Correct, it does not.  (But at least it now explicitly says "I don't know what to do with .svg" rather than "that doesn't look like valid JSON".) > So, to my understanding, to achieve what you're describing, I'd have to extend the OpenSCAD application itself. Yes. > 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. Fork?  Well, only sort of.  All OpenSCAD development is done in forks, but when it's ready to go back into the mainstream the changes are folded back into the master branch of the main repository, and the fork can be deleted. You only need a long-lived fork if you want to add something that can't be accepted back into the mainstream. A note:  the bar is pretty high for accepting changes to the language and built-in modules[*], because we want to be fairly confident that we'll be able to support them forever; we don't want to have to make an incompatible change a year or two down the road.  That's why I wrote the discussion of issues surrounding an SVG Importer (17 Sept, 18:41 UTC).  In addition, we're weak on reviewers, and that can be a serious obstacle. [*] in the OpenSCAD-language sense, not in the sense of being add-ons to the application. > Am I getting you wrong? Only in that we seemed to be having a terminology mismatch. I was confused by your use of "module of the program" versus "build it in OpenSCAD directly".  OpenSCAD is not modular, from an external viewpoint.  You can't plug new C++ modules into it.  The only way that you can add new C++ functionality to it is do what I would call "building it in OpenSCAD directly".

svgdata = import("file.svg");

Thank you for the clarification. So we have the same understanding. To my understanding every software written in an object oriented language is modular since it allows for abstraction and inheritance. Even though this often not the case in practice with long evolving monoliths... I don't know if this would be a long living fork, but I would assume so currently. I haven't thought about pull requests yet and would only do so if I was pleased by the quality of the implementation, with respect to code quality, tests, and the conventions of OpenSCAD development I would then study intensively. Best, Thomas > Am 19.09.2026 um 19:15 schrieb Jordan Brown <openscad@jordan.maileater.net>: > > On 9/19/2026 9:52 AM, Thomas Richter via Discuss wrote: >> Maybe I get you wrong. As far as I can tell >> >> ``` >> svgdata = import("file.svg"); >> ``` >> >> curently doesn't work. > > Correct, it does not. (But at least it now explicitly says "I don't know what to do with .svg" rather than "that doesn't look like valid JSON".) > >> So, to my understanding, to achieve what you're describing, I'd have to extend the OpenSCAD application itself. > > Yes. > >> 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. > > Fork? Well, only sort of. All OpenSCAD development is done in forks, but when it's ready to go back into the mainstream the changes are folded back into the master branch of the main repository, and the fork can be deleted. > > You only need a long-lived fork if you want to add something that can't be accepted back into the mainstream. > > A note: the bar is pretty high for accepting changes to the language and built-in modules[*], because we want to be fairly confident that we'll be able to support them forever; we don't want to have to make an incompatible change a year or two down the road. That's why I wrote the discussion of issues surrounding an SVG Importer (17 Sept, 18:41 UTC). In addition, we're weak on reviewers, and that can be a serious obstacle. > [*] in the OpenSCAD-language sense, not in the sense of being add-ons to the application. >> Am I getting you wrong? > > Only in that we seemed to be having a terminology mismatch. > > I was confused by your use of "module of the program" versus "build it in OpenSCAD directly". OpenSCAD is not modular, from an external viewpoint. You can't plug new C++ modules into it. The only way that you can add new C++ functionality to it is do what I would call "building it in OpenSCAD directly". > >

On 9/19/26 12:38, Thomas Richter via Discuss wrote: > 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 I got the impression you were already a Uni prof, but the memory is now 30+ years old >> 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. I might have an opinion but its way above my pay grade now.  I think flowers were due at the time. >>> nnnn >>> >>>> 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 > > _______________________________________________ > OpenSCAD mailing list > To unsubscribe send an email to discuss-leave@lists.openscad.org > .