OK, so that resulted in resounding silence.

For those of you who work with InkScape and SVG files often, take a look
at the image, below.  It consists of four "words" of text, 8 thick black
lines, and 4 thin red lines.  Let's assume that the text and the thick
black lines are in fixed positions, they are boilerplate, and can/should
be ignored.  Were I to import this into OpenSCAD, is there a way to
identify the 4 red lines and work with them separately?

My bet is that I will have to write a post-processor to find the 4 red
lines and turn them into data for OpenSCAD, but I'm hoping there is a
better way.

Thanks!

Jon

On 3/26/2023 2:29 PM, jon wrote:

Your original post was not clear as to your need.  The second post helped a
lot (presumably).

My take would be to import the image into openscad using "surface" (only
works with PNG files, apparently).  The colors will set the height of the
shapes.  Assuming that you can have the desired colors import at a higher Z
height than the undesired colors, you could then slice off the lower part
of the imported shape to get only the desired color shape(s).

On Tue, Mar 28, 2023 at 10:59 AM jon jon@jonbondy.com wrote:

On 3/28/2023 8:58 AM, jon wrote:

Not really, working in a straightforward way.  You know where they are
and where the other markings are, so you could use intersection or
difference to isolate the red lines... but then what would you do with
them?  They would (all four of them) be one polygon.  You could
transform them and extrude them, but not much else.  (Rotational
extrusion might be interesting, depending on exactly what you want.) 
You could not, for instance, extract the coordinates and work with them.

The development snapshots have an option to "import" that can specify a
particular SVG object or set of objects, and that can help a little, but
it still would only let you bring in those red lines as polygons, not as
lists of coordinates.

PR#4478 includes a feature that renders a sub-model into coordinates.

r = render({{ square(10); }});
echo(r);

yields (reformatted for readability):

ECHO: { min : [0, 0, 0], max : [10, 10, 0], center : [5, 5, 0], size
: [10, 10, 0], objects : [ { points : [ [0, 0], [10, 0], [10, 10],
[0, 10] ], paths : [ [0, 1, 2, 3] ] } ] }

That would let you extract the coordinates.  But it's still only a PR
and there are some key aspects of the design that are not yet nailed down.

Right now, I think that's about it.

One of the libraries has a function that parses an SVG string into
numbers.  I thought it was in BOSL2, but I'm not immediately finding
it.  That would make your post-processing be a matter of extracting the
right string from the SVG and copy-and-pasting it into an OpenSCAD
program.  (Or otherwise constructing an OpenSCAD program out of it, of
course.)

This can't be done in current OpenSCAD, but here is a possible plan:

• First, vertically line up the black lines for RA and SC with those
  for OFX and OFY. Why make it more difficult than necessary?
• Convert SVG to PNG using ImageMagick, like "convert file.svg file.png".
• Use a programmatic language and a graphics library to load the PNG
  image, process it, and output an OpenSCAD code fragment (such as an
  module or list declaration) that can be included by an OpenSCAD
  program. For example, C++ using stbi_load() or Python using PIL
  Image.open.
  o Loop for x = [0, image_width - 1] and look at each column of pixels.
  o Scan down each column, saving the Y coordinate each time the
  color changes. Only consider columns that match the following
  pattern, where W is a series of white pixels, B black, R red:
  o      W1 B1 W2 R1 W3 B2 W4 B3 W5 R2 W6 B4 W7 B5 W8 R3 W9 B6 W10
  B7 W11 R4 W12 B8 W13
  o Calculate values using the starting Y coordinates for each
  series of pixels.
      RA[x] = (B2 - R1) / (B2 - B1)
      SC[x] = (B4 - R2) / (B4 - B3)
      OFX[x] = (B6 - R3) / (B6 - B5)
      OFY[x] = (B8 - R4) / (B8 - B7)
• Now you've got arrays of values in the interval (0, 1) that you can
  sub-sample horizontally and scale vertically as needed.

Regards,
Curt

On 3/28/2023 8:58 AM, jon wrote:

Curt:

Thanks!

I wrote software to parse the SVG file, but that turned out to be 
increasingly complex.  I had it nailed, and then I edited the SVG file
to adjust a line, and that changed the format of the SVG file, so in the
end I started heading in the direction that you recommended (scanning a
PNG file).  I'm not sure it is worth pursuing this.  In a sense, I'm
trying to take the Customizer and enhance it with the ability to
generate a curve or a list of numbers.  It sounded more exciting when I
first conceived of it.

On 3/29/2023 7:43 PM, Curt McDowell wrote: