USER FORUM
(you are viewing a thread; or go back to list of threads)
Issues filling contours from sketch text curves (by Craig)
I'm designing front panels for electronic prototyping and using a laser cutter to cut/engrave acrylic. Pretty simple 2D stuff, I'm using SolveSpace because I find it helpful to use constraints to get dimensions and layouts to match where components on a PCB go.
When using text curves from a TrueType font, I'd like the strokes of letters to be filled when engraving, rather than having them outlined. I'm running into a couple of issues.
The main issue is that the interiors of letters like "O" get filled. This happens with all the fonts I've tried. Is there any way to prevent this? It seems like the fill ought to alternate so that negative space, inside of an even number of sub-contours, goes unfilled.
There's also inconsistency between solvespace's display and other software about filling letters when exporting to an SVG at least. SolveSpace shows only the letter interiors and not the strokes themselves filled, though all the other programs I've tried display both as filled (I've tried this with Inkscape, Edge on Windows, and Beam Studio which is the laser software I'm using). This is a pretty minor annoyance once I figured out that it was happening, if I can figure out how to not have the letter interiors filled, since I actually care what Beam Studio will engrave rather than what it looks like on-screen.
When using text curves from a TrueType font, I'd like the strokes of letters to be filled when engraving, rather than having them outlined. I'm running into a couple of issues.
The main issue is that the interiors of letters like "O" get filled. This happens with all the fonts I've tried. Is there any way to prevent this? It seems like the fill ought to alternate so that negative space, inside of an even number of sub-contours, goes unfilled.
There's also inconsistency between solvespace's display and other software about filling letters when exporting to an SVG at least. SolveSpace shows only the letter interiors and not the strokes themselves filled, though all the other programs I've tried display both as filled (I've tried this with Inkscape, Edge on Windows, and Beam Studio which is the laser software I'm using). This is a pretty minor annoyance once I figured out that it was happening, if I can figure out how to not have the letter interiors filled, since I actually care what Beam Studio will engrave rather than what it looks like on-screen.
(no subject) (by Ryan)
Craig,
I'm not entirely sure what your problem is as I don't see the interior of letters like "O" getting filled in exported files. I'm not able to mess with the other programs you mention so this could be the source of my confusion about your questions.
It may help to extrude(or not) the text then export a 2d view as this changes the fill characteristics of the text. Only the lines of 2d text are exported from a sketch, but the text is filled when a solid is exported. Changing the color of the extrude may enable filling from another program(especially if you can map a color to a line style that has your engraving pattern). I cannot speak to TrueType font as it is not on my machine either.
TextOutputTest.zip has files with some text both in sketch and extruded then "Export 2d view" to pdf and svg. Changing the color of the extrude comes through too, though not shown in these example files.
Hope this helps.
I'm not entirely sure what your problem is as I don't see the interior of letters like "O" getting filled in exported files. I'm not able to mess with the other programs you mention so this could be the source of my confusion about your questions.
It may help to extrude(or not) the text then export a 2d view as this changes the fill characteristics of the text. Only the lines of 2d text are exported from a sketch, but the text is filled when a solid is exported. Changing the color of the extrude may enable filling from another program(especially if you can map a color to a line style that has your engraving pattern). I cannot speak to TrueType font as it is not on my machine either.
TextOutputTest.zip has files with some text both in sketch and extruded then "Export 2d view" to pdf and svg. Changing the color of the extrude comes through too, though not shown in these example files.
Hope this helps.
(no subject) (by Craig)
The difference appears to be that in my work I have the text contours inside another path - the rectangle that defines the edges of the panel to cut on my laser cutter. So the fills are defined the way I suggested, but they count all contours, not just the contours in the one text object. I was able to reproduce the behavior I was seeing in your sample by drawing a rectangle around the text objects.
The workaround for this is to add another outline around the whole design that doesn't get exported (or if it shows up exported, I can tell my cutter software to ignore it). So, I have a workaround at this point.
Feature suggestion: add an option to styles that fills interiors should be defined by same-style contours rather than all contours, or something of that sort.
The workaround for this is to add another outline around the whole design that doesn't get exported (or if it shows up exported, I can tell my cutter software to ignore it). So, I have a workaround at this point.
Feature suggestion: add an option to styles that fills interiors should be defined by same-style contours rather than all contours, or something of that sort.
(no subject) (by Craig)
I'm off in that last post - the same problems with filled letters occur when exporting. Apparently no SVG renderer that I have agrees with SolveSpace about how to render these, because all of them fill empty spaces inside letters.
I did however miss your point about extruding the letters, but I couldn't get that to work with a few minutes of trying (the letters didn't get filled on export and all my constraints disappeared from view, probably because its no longer a sketch, and I can't figure out how to get back to the sketch). So I guess I need to dig deeper into this extruding business but I will have to get back to it later.
I did however miss your point about extruding the letters, but I couldn't get that to work with a few minutes of trying (the letters didn't get filled on export and all my constraints disappeared from view, probably because its no longer a sketch, and I can't figure out how to get back to the sketch). So I guess I need to dig deeper into this extruding business but I will have to get back to it later.
(no subject) (by Paul)
Extruding creates a new group. See the home screen in the text window.
(no subject) (by ruevs)
The 'Esc' key is your friend (for getting home) ;-)
(no subject) (by Trevor Luscombe)
Sorry to resurrect an old topic, and for the following wall of text, but I'm experiencing the same issue as Craig. It's the same scenario: a front panel with text.
The mentioned solution works. Extrude the text layer and then export the 2D view. However, this has the downside that the geometry gets converted to a triangular mesh, causing you to lose the original exact 2D representation. You also have to increase the segmentation and chord tolerance to get acceptable results.
I've identified a few issues with how Solvespace exports 2D views.
The first is that by default it isn't exporting the filled contours, even though the contour fill style has an "export these objects" setting. There is a workaround: if you assign the 2D shapes to a custom style, you can specify that the contours are filled and that these objects get exported. Now, when you export the 2D view, you have filled contours.
The real issue is that Solvespace is aware of how the paths stack together to create a filled contour with cutouts, but the SVG/PDF export doesn't handle this correctly. In SVG terminology, the shape needs to be represented by a compound path to represent, say, a donut shape or the letter O. Currently, it is just exporting the individual paths (cutouts won't work) and incorrectly assigning fill to cutout paths (bug).
I presume this behavior is intended to support typical use cases, but it does fall short in this instance. Arguably, there should be two types of 2D export: export paths and export contours. An additional third option to export paths but apply a cutter compensation like the g-code export would be extremely useful for laser cutting work.
The mentioned solution works. Extrude the text layer and then export the 2D view. However, this has the downside that the geometry gets converted to a triangular mesh, causing you to lose the original exact 2D representation. You also have to increase the segmentation and chord tolerance to get acceptable results.
I've identified a few issues with how Solvespace exports 2D views.
The first is that by default it isn't exporting the filled contours, even though the contour fill style has an "export these objects" setting. There is a workaround: if you assign the 2D shapes to a custom style, you can specify that the contours are filled and that these objects get exported. Now, when you export the 2D view, you have filled contours.
The real issue is that Solvespace is aware of how the paths stack together to create a filled contour with cutouts, but the SVG/PDF export doesn't handle this correctly. In SVG terminology, the shape needs to be represented by a compound path to represent, say, a donut shape or the letter O. Currently, it is just exporting the individual paths (cutouts won't work) and incorrectly assigning fill to cutout paths (bug).
I presume this behavior is intended to support typical use cases, but it does fall short in this instance. Arguably, there should be two types of 2D export: export paths and export contours. An additional third option to export paths but apply a cutter compensation like the g-code export would be extremely useful for laser cutting work.
I agree this is a bug in the SVG export (by ruevs)
Attached is a zip file with two test slvs files:
- TextOnAPanel.slvs uses the default styles and the exported SVG is only countours - this OK
- TextOnAPanelFilledContoursCustomStyle.slvs uses a custom style with "contours are filled" set and the SVG export is wrong.
If one compares the two SVG files the only difference is the extra
class='s100' fill='#4c4c4c'
added to each contour/path.
This is apparently not the right thing to do.
- TextOnAPanel.slvs uses the default styles and the exported SVG is only countours - this OK
- TextOnAPanelFilledContoursCustomStyle.slvs uses a custom style with "contours are filled" set and the SVG export is wrong.
If one compares the two SVG files the only difference is the extra
class='s100' fill='#4c4c4c'
added to each contour/path.
This is apparently not the right thing to do.
Post a reply to this comment: