L. David Baron wrote:
I think in an ideal world, each text frame ought to store an array of the possible break points in it, and the measurement to reach each one. (How to handle trimming of final spaces?)
This sounds like it could be a significant space increase. Still could be a good idea though.
The plan ========
Which pieces of the above should happen first? One possibility is to do UAX #14, then line breaking, then reflow refactoring and dirty bits (which I suspect are effectively inseparable), then the frame construction changes. This is a somewhat logical order.
However, I think the parts from which we'd get the most real, user-visible, gain, and the most ability to implement new features easily, are the reflow refactoring of blocks and the UAX #14 linebreaking.
So an alternative, which I suspect is probably better, is to do the reflow refactoring for blocks but not inlines (which would solve most of the bugs). In other words, we'll continue moving inlines around to determine preferred width and minimum width. That would allow work to continue on incrementality optimizations and line breaking / text measurement in parallel, and the full reflow refactoring (or movement to whatever method we want to use for inline layout -- it's really a bit different anyway) would still wait until the end. I'm probably going to look into exactly what it would take to do this bit next, and probably write up some more detailed design ideas.
Sounds like a very good plan.
Rob
