This is in relation to text module issues issues #803 <https://github.com/openscad/openscad/issues/803> , specifically re "u) Discussion re valign/halign. I will post more on this shortly." Discussing here rather than cluttering up Github. My issue is about fitting text() generated geometry with other geometry. With all other modules (baring use of random) it is possible to calculate the edges of objects and position/align them appropriately. With text however, the generated geometry is incalculable, different fonts and glyphs have variable edges. This is inconvenient, but it will also increase the co-incident faces issue and non-manifold geometry. particularly in the future with Customizer and the similar GUI concept being discussed ATM, where the text is unknown at programming time. Firstly size (y-axis) is approximate (and glyph dependent), width (x-axis) is glyph dependent. (thankfully they don't have a variable z-axis...) The wiki says "text will have approximately an ascent of the given value (height above the baseline)". I measured these (size=10) by sizing a cube next to them. Font Size arial 9.983 rockwell 9.41 times new roman 9.215 Century Schoolbook 10.05 Courier New 7.9 halign/valign to the rescue? I hoped so, but "currently the center calculation uses the glyph bounding box multiplied with the spacing factor, so the additional space (in case of spacing > 1) is behind the character." Which means halign="center" is not centered when spacing<>1, and halign="right" is not aligned, but strangely "left" is OK. See images below, the coloured blocks represent the additional (for spacing=1.5), or reduced (for spacing=0.5) space, code is attached. <http://forum.openscad.org/file/n10556/ha_left.jpg> <http://forum.openscad.org/file/n10556/ha_center.jpg> <http://forum.openscad.org/file/n10556/ha_right.jpg> text_left.scad <http://forum.openscad.org/file/n10556/text_left.scad> text_center.scad <http://forum.openscad.org/file/n10556/text_center.scad> text_right.scad <http://forum.openscad.org/file/n10556/text_right.scad> I think the spacing for the first and last character should be adjusted as appropriate taking into case both halign and direction (as behaviour is illogical for direction="rtl" ATM). Alternatively if the bounding box for the text is retrievable (the actual text - ie ignoring space at edges), appropriate calculations and translations could be done. My concern is if it is released now, it will be forever locked in by backward compatibility. Perhaps release text() without halign/valign & direction (and possibly spacing), allowing this to be sorted out for next release??? Then there is vertical, I'm less prepared for that, so I'll post separately. But here's a teaser: <http://forum.openscad.org/file/n10556/valign.jpg> ----- Unless specifically shown otherwise above, my contribution is in the Public Domain; To the extent possible under law, I have waived all copyright and related or neighbouring rights to this work. This work is published globally via the internet. :) Inclusion of works of previous authors is not included in the above. The TPP is no simple “trade agreement.” Fight it! http://www.ourfairdeal.org/ -- View this message in context: http://forum.openscad.org/text-halign-valign-and-alignment-with-other-geometry-tp10556.html Sent from the OpenSCAD mailing list archive at Nabble.com.

> My issue is about fitting text() generated geometry with other geometry. > With all other modules (baring use of random) it is possible to calculate > the edges of objects and position/align them appropriately. > Same with most imports, except for DXF there's the dxf_dim() hack. > halign/valign to the rescue? I hoped so, but "currently the center > calculation uses the glyph bounding box multiplied with the spacing factor, > so the additional space (in case of spacing > 1) is behind the character." > We can change that. Any idea how to handle it? Distribute the spacing for each glyph at both sides and remove at the outside? > I think the spacing for the first and last character should be adjusted as > appropriate taking into case both halign and direction (as behaviour is > illogical for direction="rtl" ATM). Alternatively if the bounding box for > the text is retrievable (the actual text - ie ignoring space at edges), > appropriate calculations and translations could be done. > I think the alignment specific to text() should be based on the glyph information and not geometrically. If we remove that, there's no way at all to use the font specified metrics anymore. For geometric alignment we could have an additional module that does it. That would even allow to center other geometry, e.g. generated using rand() or imported files. That way we can have all cases covered and even make the (geometric) alignment functionality more general and not just specific to text. ciao, Torsten.