[Pharo-dev] [bloc] shape size?

Igor Stasenko siguctua at gmail.com
Mon Apr 4 05:58:36 EDT 2016

On 4 April 2016 at 10:47, Stephan Eggermont <stephan at stack.nl> wrote:

> 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
Well, the changes to text and amount of (re)computations they triggering
was out of the scope of our discussion. Yes, indeed this is possible to do
with acceptable speed.
But in addition to that, TxText was never thought as a base for
full-fledged word processing. There's no model for paper-press era things,
like page numbers, chapters, columns etc.
Its primary focus is to support displaying text in our UI and overcome
shortcomings of old model.
Since most of text is source code and for code editing, not a surprise that
most features was prioritized accordingly around that fact.
Frankly i don't think we need to focus on making yet another all-doing,
all-knowing word processor. First, it is huge investment of workforce and
time, and second - it is investment with no return or infinitelysmall
marginal return.
Apart from being 'cool to have', full-fledged word processing is not a
thing, that you dealing with on a daily basis in environment, like Pharo.


Best regards,
Igor Stasenko.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/attachments/20160404/f77c9aac/attachment.html>

More information about the Pharo-dev mailing list