On 03-04-16 21:58, Igor Stasenko wrote:
Yeah, i did similar thing in TxText - also create morph(s) only for > part of text which is currently displayed.. and basically it is same
> idea for TxText itself: it calculates layout only for a portion of >
text, the portion that currently displayed, but never for whole > text,
which can be megabytes long. Thus, it guarantees that overall >
performance are bound to the area, covered by UI control that > displays
the text, but not to text size.
Which, if I understand it correctly, works fine for code editing,
but does not cover the needs of high-quality typesetting like we
might want in pillar rendering or advanced word processing.
Systems like TeX, Framemaker and InDesign need to recompute
layout back to the beginning of a hard page/column break, like a
new chapter, and page numbering requires whole document
recomputation, as references to page numbers in the text get a
new width. Most documents have enough spacing margin that
the recomputation does not propagate so far as to have a user
noticable impact. I used Framemaker version from version 5,
and that was able to do so with acceptable speed in 1995.
20 years of CPU improvements should allow us to do the same
in Smalltalk
Stephan
