Geometry Manager

Code routine that automatically positions widgets in a GraphicalUserInterface.

One example I can think of is SpringsAndStruts.

TclTk and its derivatives, such as GTK+ (GtkPlus), do this type of stuff. Make application interfaces easy. Sometimes though, I want to make a fixed size program and set everything up myself. GTK+ makes that harder than need be.

HyperTextMarkupLanguage manages geometry. Not well.. not usefully... but it does (sorta).

Would Display PostScript (from NextStep) count?

Why would it? Postscript itself certainly doesn't automatically position anything, and I don't recall a DisplayPostscript extension that does any such thing, either.

Regarding SpringsAndStruts, the NextStep (and now MacOsx) InterfaceBuilder tool has this feature too. Actually, I'd like to see (or perhaps write) a GeometryManager that mimics the boxes and glue of TeX, where different glues can have different orders of infinity [affinity?] in their stretchability and shrinkability. You'd have to use it to understand why it's important. -- EricJablow

InterViews was based on the TeX notion of boxes and glue, and was in general a beautifully small, flexible, and powerful system.

I meant infinity. In TeX, glues (or rubber lengths) have a natural length, a stretch component, and a shrink component. For example (from the Plain TeX code)

\abovedisplayskip=12pt plus 3pt minus 9pt

defines how much space should appear above a display (a floating table, etc.) The natural length is 12pt, it can be extended to 15pt without the TeX engine screaming too loudly, and can be shrunk to 3pt if necessary. (Actually, the engine will go past 15pt if really really necessary, though it complains very loudly). The space character may be defined (depending on the current font) to provide 4pt plus 1pt minus 0.5pt of space, for example. When the engine fills a box, it adds up the natural lengths, the stretches, and the shrinks, and it decides how big to make the box and chooses lengths appropriately. For paragraphs, it breaks the lines up in various ways, computes scores for each set of line breaks, and chooses the best.

However, the stretch and shrink components can be denominated in 3 different orders of infinity: fil, fill, and filll. When a box has infinite stretch in it, all finite stretch is ignored. For example, the end of a paragraph has \parfillskip added on automatically:

  \parfillskip=0pt plus 1fil

The natural length is zero, but it can stretch to the right as much as necessary. The last line of a paragraph uses its natural lengths for everything else. What if you wanted to center the line instead?

\hfill provides natural length 0pt but 1fill worth of stretch, and the centering commands do the equivalent of

\hfill The line.\hfill

Adding the \parfillskip doesn't matter, because the \hfill comands provide a higher order of infinite stretch, and override the \parfillskip.

So, to do what Laurent mentions below, one writes:

\hfill A\hfill B\hfill

The space will be allocated evenly before A, between A and B, and after B. Similarly,

\hfill\hfill A\hfill

will put the letter A 2/3 of the way along a line.

Sorry about the excess detail. --EricJablow

Definitely. It's entirely beyond me why the TeX model for page layout wasn't adopted as a standard conceptual model by every system concerned with layout ever since, from HTML to Word to XSL/FO. Just about the only things you can do with a box nowadays is center it, or position it to pixel precision - but simply distributing two boxes along a line so that the remaining whitespace is evenly proportioned is beyond most of the programs I can think of. -- LaurentBossavit

What changes would you make to the TeX model to avoid the problem of (in TeX terms) overfull boxes? Also, how would you handle discretization error? -- EricJablow

I'm not aware of a TeX "problem" with overfull boxes; they arise when something is just too big to fit under normal policies, and human intervention is desirable to figure out what to do, such as to rewrite the text so that it doesn't happen, or choosing to temporarily override policies, or inserting a hyphen point. And if the "final draft" command is given, there's no ugly "look here" mark in the margin. I would think that's about as good as it gets.
I haven't seen problems with quantization error in TeX, Postscript, X11, etc, either; either tracking coordinates in floating point, or the idea used in Bresenham's algorithm generalizes to general use (maintain an error estimate), and is used in essentially all systems that layout to a discrete grid.
If you mean something beyond that, there's an endless number of clever things that have been done; for instance, Adobe's MultipleMasterFonts? allow automatic micro-adjustments to font sizes to assist in better laying out paragraphs, to decrease the amount of white space needed. TeX uses dynamic programming to adjust multiple paragraph layout to best fit the page, rather than the far more common one-pass approach.