New text system implementation

[Alexander Malmberg]

Hi,

The new text system implementation is getting close to completion (some
screenshots: http://w1.423.telia.com/~u42308495/alex/TextSystem*.png),
so it's question time again:

1.
I would like to commit this very soon so I can iron out the last issues
(currently, I have tons of hacks in place to be able to test it).
However, this will involve fairly extensive changes (-gui and -back),
and it will break stuff for a while. Thus, I would like to do this on a
branch and merge it in when it works. Is this ok? Couldn't find anything
in the coding standards about using/naming branches; should there be?


2.
I've collected a couple of behavior issues about actual text layout (not
interfaces or stuff like that) in the wiki:
http://wiki.gnustep.org/index.php/TextSystemIssues


3.
The interface. This has caused me some difficulties, but in the end,
I've come to the conclusion that full compatibility isn't worth the
trouble.

OpenStep doesn't mention any of the behind-the-scenes text classes, so
compatibility there is a non-issue. OPENSTEP only mentions
NSLayoutManager, and my implementation should be almost completely
compatible with it (for normal horizontal layout, but that's all
OPENSTEP supported). Apple has added a bunch of methods to
NSLayoutManager (some reasonable), and has made NSTypesetter and
NSSimpleHorizontalTypesetter public. Both Apple (and OPENSTEP, but
that's irrelevant) claim that these classes will be able to handle any
type of typesettting, but that they're currently limited to horizontal
text.

Anyway, following apple (and OPENSTEP, in part) is a bad idea here
because:
* The NSLayoutManager interface as documented isn't enough for it to
work (well) with NSTextView.

* The documented NSLayoutManager/NSTypesetter interface isn't enough to
support everything that should be supported, and even the stuff that is
documented is too underspecified to work with. (Besides, should this be
public at all?)

* The NSLayoutManager interface can't handle general layouts without
tons of extensions in the NSTypesetter interface (basically, each
NSLayoutManager would just forward the message to its typesetter).


I suggest, and will do: (unless someone can give me a good reason not to
:)

GSLayoutManager: Basic storage of glyph and layout information, basic
typesetter interface, can handle _any_ layout (which means that it won't
contain many of the methods that NSTextView needs).

NSLayoutManager: Sub-class of GSLayoutManager that assumes horizontal
layout (and a few other restrictions).

GSTypesetter: Abstract typesetter super-class. Not compatible with
apple's NSTypesetter.

GSHorizontalTypesetter: The default typesetter. Can be used with
NSLayoutManager. Not compatible with NSSimpleHorizontalTypesetter, but
can be subclassed to change behavior in a similar way.


This way, NSLayoutManager is there and works like on OPENSTEP. You can
still write custom typesetters (although I won't guarantee that the
interfaces between the classes won't change), or subclass
GSHorizontalTypesetter (fairly safe). You can use any kind of layout you
want to, but if it doesn't fit NSLayoutManager's restrictions, you'll
have to provide the NSTextView integration methods yourself if you need
them.

After working with it a while, this seems like the best solution. Most
of the code is done, so I'd like to commit this (to a branch) sometime
this weekend, if everything is OK :).

- Alexander Malmberg