Doug Moen doug at moens.org
Thu Oct 3 09:30:50 EDT 2019

```In Shadowwynd's example below, the problem is solved if you can query the bounding box of a `text` object.

In Curv, every primitive shape operation computes the bounding box of the shape, and makes that bounding box available to the program. This is fast, because it is done *without* rendering the shape. In the case of intersection and difference, the bounding box is an estimate (the true bounding box might be smaller), but in other cases, the bounding box is exact. In practice, it is these "other cases" where the bounding box is most useful, so it doesn't matter that the bounding box is sometimes an approximation.

This feature could be added to OpenSCAD, with restrictions that guarantee it is a fast operation, and it would not be difficult. In the case of text, the cost of computing the bounding box should be no worse than the cost of previewing the text, and that seems to be a fast enough operation. Since intersection and difference are super expensive to render, you use an approximation for these cases. For intersection(){A;B}, you use the intersection of the bounding boxes of A and B. For difference(){A;B} you just use the bounding box of A.

The bounding box is useful in lots of other situations. Eg, import an STL and position it so that the bottom is at Z==0.

Doug Moen.

On Thu, Oct 3, 2019, at 1:08 PM, shadowwynd wrote:
> Here's a simple example of why querying geometry would be useful.  Imagine a
> rectangular key fob with the person's name extruded above the rectangular
> backing, and a 5mm margin on every side between the text and the rectangle.
> This is very much a "hello world" problem, and I see many kids doing this as
> a "my first 3d print" introduction.
>
> The train-derailing starts with this simple question:  what are the
> dimensions of the rectangle?
> And yes, it is easy to manually adjust a number and refresh until it "looks"
> right - but this fight is about querying geometry and having computers ...
> well, compute.
>
> So the code starts off easy enough:
>
>     name = "Fred";
>     linear_extrude(2) text(name);
>
> With a monospaced font, the size of the rectangle is easy, but not trivial -
> we can resize our height to fit a given fob height, calculate the number of
> characters in name with len(), multiply by some constant, add 5+x+5mm, and
> now we have the dimensions of the fob to create.  I do this with Braille
> tags, which are monospaced with a set width and height - no big issues.
>
> But text() allows the user to pick a size, and to pick any font that is
> installed on the PC, including proportional fonts that are not monospaced.
> You can guess at it, you can do a character count - but without decoding the
> font file itself and building a table that lets you add up the character
> widths for a particular proportional font you have to enter constants for
> width and height until it "looks right".  Or you can size/scale it to fit a
> standard size fob, which distorts the font.  Or you decide you want a
> different font and you have to start manually calculating a new font width
> table, just like you DON'T DO in all other graphic design / word processor
> programs.  You could just try setting length of fob and let one side have an
> uneven margin, but then Murphy will smile on you and you end up with both a
> name="Ro" and name="Pippinpaddleopsicopolis" in the same class.
>
> There isn't a way to programatically calculate the size of the fob given a
> random proportional font because OpenSCAD doesn't allow geometry queries on
> the text object that OpenSCAD generated.  And yes, I know how the render
> pipeline works, and know that getting the dimensions would require the
> object being queried to be rendered first, and there would be a performance
> hit, etc.
>
>
>
>
> --
>
> _______________________________________________
>

```