Thu Oct 3 09:08:06 EDT 2019

```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.

--