bearingX is the left-inset, advance - bearingX - width = the right-inset (of import with space!=0). bearingX is the left-inset, advance - bearingX - width = the right-inset (of import with space!=1). -- This email has been checked for viruses by AVG. https://www.avg.com

I think we both understand the concepts and largely agree on how they should work in OpenSCAD. On 12/31/2020 11:24 PM, MichaelAtOz wrote: > _Perhaps an option in text() for those who don't care? _ > > galign=true (glyph-align), purely uses the BB of the set-of-glyphs, > moved to OpenSCAD origin, > > (origin appropriate to ltr/rtl/ttb/btt). > Perhaps.  I'm a bit more inclined to say "query the metrics and use them to adjust as desired". With respect to "spacing", I'm increasingly convinced that it isn't meaningful in the general case and so not worth worrying about.  What killed it for me was the ligature issue.  If you want some particular spacing behavior, crack your string up into characters on your own and translate them as you like. > The backward compatibility Force is Strong... > Yeah.  Mixed feelings.  Breaking something that was working before, even something that was only arguably right, is usually bad.  Fixing something that was clearly wrong, even if people might have come to implicitly depend on it, doesn't seem nearly as wrong - especially if it's subtle. Remember that a backward compatibility break is a one-time pain, while leaving a bug in place is pain forever. Mucking with "spacing" probably isn't worth it.  Without major changes to semantics (e.g. making it an addition rather than a multiplication, and doing something about ligatures), it's arguably right.  For better or worse, it's doing what it's designed to do, and it's hard to come up with answers that are more clearly right. The 2.4% problem, in the other hand, is small and clearly wrong.  Backward compatibility is the *only* rationale for preserving it.  I'd fix it. > > a few of the metrics (advance, offset, ascent, descent, but *not* the > glyphs themselves) are scaled down by 2.4% > >   > > I had presumed it was opposite (the glyphs were bigger) but that > explains my observations. > The glyphs have the same internal scaling factor (100,000) on both "sides".  The metrics are scaled up by 100,000 and down by 102,400.  Although you could make them match by changing the glyph scaling, that would expand the weirdness. > Perhaps we should ask the community (in a separate thread) what damage > > the various fixes would do to their designs? > Yes - after we think we understand the issues, I was thinking of making some concrete proposals for commentary. A capsule summary of what I'm thinking of is: * Just fix the 2.4% problem.  (Or *maybe* make it an option, probably a $ variable.) * Just fix the TTB/BTT alignment issues for explicit halign and valign values.  Retain backward compatibility for cases where halign and valign are not specified by making the defaults for TTB/BTT be halign=center and valign=top.