I've been thinking of writing more. Doing real text layout is one of the tricky bits, and one that terminals sidestep because layout calculations are trivial as long as you narrow scope down to grids of monospaced ASCII characters.
back
1 comments
I'd be very interested in reading it! I've been thinking about the problem of performant real text layout a lot lately. I'm guessing you're not including optimization-based paragraph filling (like TeX or GNU fmt) in "real text layout"?
I think it's potentially in scope, but optional - there are other problems more urgent to solve, and then with more powerful compute and font technology, it's possible to go past TeX into microtypography (some of which was done in hz, but not really widely adopted). Either way, to do Knuth-Plass paragraph optimization, you need lots of metrics of the words to decide the line breaks, and to do the micro stuff, you need even more fine-grained information from the font. Breaking that across a process boundary is... tricky.
A thing I've been struck by when looking at medieval manuscripts is how ubiquitous "microtypography" is in them. No two copies of the same letter are ever the same width, swashes and scribal abbreviations are chosen to fit the space available, etc. If you can manage to do that kind of thing on a computer, pretty soon you're doing continuous optimization instead of discrete optimization, so maybe the optimization process becomes a lot cheaper computationally.
I hope you get around to writing up your thoughts! I'd be interested in providing feedback on drafts if that would be useful.