Hmmmm... I can't help but feel like this technique is related to the TeX layout engine.<p>If you've ever read Knuth's TeX design, you'll know that TeX has a intricate solver to determine the "badness" of lines. The spaces between words (and sentences: such as the ".") will be manipulated to minimize the "rivers" of poor-justification algorithms.<p>Today, instead of manually writing a constraint-solver like Knuth did for TeX in the 1980s, it makes sense to leverage open-source solvers like Z3.<p>-----------<p>We can see that TeX is simply a domain-specific language that puts glyphs (in the form of letters) into a set of constraints... constraints of the form "width = target_size +/- adjustable_size".<p>And TeX is simply a constraint solver that iterates over all possible combinations (!!!) and selects the set of adjustable_sizes for all glyphs for the best looking paragraph (where "best looking" paragraph is a set of calculations Knuth thought looked good back in the 1970s/1980s).<p>Knuth proved that TeX's solver traverses across an NP complete problem. But it turns out that written paragraphs are "small enough n", and that exhaustive search (with some good heuristics to speed things up) is possible on computers, even computers 40 years ago.<p>-------<p>I also can't help but feel like a lot of UI-design is about layout engines like this. Flexbox makes my head hurt but having the web-browser "solve" constraints that I gave it is more flexible across different devices (phone vs 1080p laptops vs ultrawide desktop screens).<p>Constraints are already used for 3d CAD for engineers (this point must match that point. This angle must be 2/3rd of that angle. Etc. etc. Computer, now solve for the shape). Using them as 2D designs for GUIs, figures, and text only makes sense.