Joaqu�n Cuenca Abela wrote: > If we measure the cost of the operation in number of lines "reflowed", > we get: > > t: nb of lines in the document > n: nb of lines by page (approx.) > N: nb of pages > > t = n * N > cost = t + (t - n) + (t - 2n) + ... + (t - n * N)
Holy Goat! That's BAD! What if... I'm going out on a limb here, but what if we instead of "pushing" lines back (onto the next page, repeat as needed) had a "virtual" document/layout that the on-disk document got loaded into (without any of the flowing calculations/calls taking place of course, that would be the "virtual" part of it) and then the layout engine instead "pulled" runs/lines from that virtual document to layout the stuff as needed? It would obviously be a tremendous speedup for the loading case, but would it work in the general case? I think so, but obviously this is an area where some redesign is needed why additional input can't hurt. > And a last note, the breakSection (the root of this problem) is > convoluted (>500 lines for a single function?). I used to be a maintainer of project inherited from a proprietary code-base and we found functions that were several _thousand_ lines long! Speak about unmaintainable. AW has a function a couple of hundred lines? Pffft. :-) No, seriously, a function that large is too large and should be refactored. /Mike
