Re: Progress of text system

[Fred Kiefer]

Hi Alexander,

you did include some of the needed layout reuse by now. I think this is 
still on the wrong basis, so I will have to explain my point in more 
detail. I was hoping that Richard would step in on this, as he knows a 
lot more than me on the layout mechanism.

Alexander Malmberg wrote:
> Fred Kiefer wrote:
> [snip]
>
> > Instead it does include handling for multiple text containers and a bit
> > for glyph generation (most of this will only come when we use the pango
> > library, but the place to integrate it is now there).
>
>
> Using pango in a backend to handle this is one option. My plan is to use
> freetype's opentype support (once it actually has any), but this isn't a
> high priority at the moment.

I don't know what opentype is, up to now I mistook it for a font 
technologie that merges Postscript and Truetype. What Pango offers and 
what I was revering to is glyph generation for different scripts 
(something similar to languages but not quite the same). If something 
similar is also to be in opentype it is fine for me.

> > We should try to
> > resurrect the optimisations that where there to reuse already created
> > layout. At least for the case where the text container is rectangular
> > shaped.
>
>
> There isn't much point in trying to resurrect the old code, as the
> structure of the new system is very different. Reuse of layout
> information is an important optimization, though. I've implemented the
> basics of this, so layout information for glyphs above a change will be
> reused now. The interface for soft invalidation (effectively, reusing
> layout information for glyphs below a change) has been worked out, and
> I'm working on the implementation. I've also committed a bunch of minor
> optimizations that should help performance with large amounts of text.

According to the Apple documentation glyph handling should be quite 
different. There is some unnamed object that generates glyphs, I would 
see this as located in the backend for GNUstep, and inserts them into a 
datastructure of the NSLayoutManager that Apple calls glyph stream. This 
stream behaves like one big array, but should be implemented differently 
for efficency reasons. There used to be an implementation for this in 
GNUstep done by Richard. Glyphs are generate into this stream as soon as 
they are needed. The glyph generator is a somewhat magic devices as it 
is able to store all the information on font and character into 32 bits 
and does so very efficently. I don't have the slightest idea how this 
can be done.
On top of this glyph stream there is the breaking of glyphs into 
fragments. This gets done by the NSTypesetter or a subclass. You are 
right that this class is not very clear in the Aplle documentation and 
that we may implement it differently without doing much harm.
Now when the user changes the text it is neccessary to regenerate the 
glyphs for the changed characters, but for the rest of the document only 
the layout fragments may need regeneration not the glyphs.
Perhaps we should get further away from the notion glyph run, as this is 
mostly used for dispaling only.

> > If the
> > extension methods are needed here, we should move them to a GNUstep
> > category. Similar changes should be done to the layout manger files. The
> > current separation into GSLayoutManager and NSLayoutManager is more or
> > less arbitrary.
>
>
> There is nothing arbitrary about this split.
>
> GSLayoutManager is a generic layout manager, capable of dealing with
> arbitrary layouts (horizontal, vertical, mixed, or even more complex
> stuff). GSLayoutManager is only a dumb storage class for layout; it has
> little knowledge about the layout, and can't implement all the methods
> that NSTextView requires. When you want to handle generic layouts (eg.
> if you want a layout manager that lets you use vertical layouts in a
> text view), you subclass GSLayoutManager to get all basic glyph and
> layout handling (and impose constraints on the layout), implement the
> methods that NSTextView requires, and subclass GSTypesetter to make a
> typesetter that lays glyphs out according to your constraints.
>
> NSLayoutManager is a layout manager that supports only heavily
> constrained layouts (normal left->right layout with line frags strictly
> arranged in lines, and lines strictly ordered vertically, etc.; a
> detailed list can be found in NSLayoutManager.m, and includes a lot of
> things ranging from trivial (but important for simplifications) ~"each
> text container has at least one line frag", to more complex ~"layout is
> affected by context only as far back as to the previous line"). Thanks
> to these constraints, NSLayoutManager knows a lot about the layout, and
> can implement all the methods that NSTextView requires. NSLayoutManager
> should be compatible with OPENSTEP's NSLayoutManager (except for
> "internal, do not call" methods), and will probably be compatible with
> most of apple's extensions eventually.
>
> Merging these classes would severely limit their usefulness. We need a
> standard layout manager for text views (and its behavior matches what
> OPENSTEP calls NSLayoutManager), so we would lose GSLayoutManager. This
> would make any work on anything more exotic than standard left->right,
> top->down layout practically impossible.

I have to disagree on this. Even after you put a few more optimisations 
that only work for left-to-right top-to-bottom layout into 
NSLayoutManager there are plenty of methods in this file that rather 
should be in GSLayoutManager according to your definition. I would name 
the drawing methods, the handling of text container, typing attributes, 
 text view ruler markers. Other methods should be implemented by 
calling abstract interfaces that provide the same interface indepenend 
of the specific layout strategy. This would leave us with only a few 
methods with internal knowlegde of the layout strategy of 
NSLayoutManager and of course this are the ones that a subclass must 
overwrite.
I don't see any lose in extensability if this is done in one file as 
opposed to two. Or am I missing your point here? Would you like to have 
GSLayoutManager for a totally different reason? Could you give an 
example of using a subclass of GSLayoutManager without a text view?

> > We should merge those two files together again and
> > instead make sure that we separate out the GNUstep extensions into
> > a separate category. That way the GSLayoutManager_internal header file
> > will no longer be needed and all further optimisation may be done in a
> > single file.
>
>
> This file would still contain internal details of the layout manager
> that are needed by eg. glyph generators in -back, but that a user of
> -gui should never see.

Wrong, the glyph generation, be it in the backend or where ever, should 
use the public method on NSLayoutManager to store glyphs, 
[insertGlyph:atGlyphIndex:characterIndex:] to name it.

> > 3) Further optimisation as listed.
>
>
> I consider proper behavior (in eg. typesetting and text view actions)
> more important than this, but I'll try to work on these optimizations as
> well.

I again dare to disagree. The layout mechanism is not there for its own 
beauty, it servers the purpose of displaying and editing text. Currently 
even with your latest optimizations (which help a lot when editing the 
end of a text) it is to slow to be actually usable. If we could make a 
new release of GNUstep based on this, we would offend all the users of 
for example Mail.app, that need the layout mechanism a lot.

> > If Alexander agrees on this I am willing to join in. If not I will try
> > to be patiened and wait.
>
>
> Well, it seems that we disagree about the structure of the text system.
> There are still things to work on that don't touch it, eg.:
>
> - The ruler system is something I haven't started looking at yet.
> - rtf parsing and producing (this is very important because text views
> use rtf internally to copy and paste).
> - Resolving the many behavior issues (stuff like: what should happen
> when the user presses page-down? generally involves thinking a bit about
> and writing a short blurb about how it should be handled (and why!) in
> the wiki).
> - Smart deletion and insertion only has stubs currently.

For me this are nice to haves, but none of this blocks the release of 
GNUstep gui 0.8.5.