Re: Progress of text system

[Alexander Malmberg]

Fred Kiefer wrote:
[snip]
> > 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.

It is, but it also includes definitions of tables with information about
glyph generation, relative glyph positioning, and other related things.

> 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.

I haven't looked closely at either one yet, but the anecdotal
information I have suggests that OpenType would be better. Since
freetype has had opentype support (in v1), and likely will have it
again, it makes a lot of sense to use it in back-art. Other backends
might find other glyph generation/positioning/etc. mechanism more
suitable.

[snip]
> 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.

The new layout manager has always worked this way with glyphs.

> Perhaps we should get further away from the notion glyph run, as this is
> mostly used for dispaling only.

Well, there are two kinds of runs. "Glyph runs" correspond to the
glyph_run_t structure in GSLayoutManager, and is just a range of
characters that is self-contained wrt glyph generation (and may or may
not have glyphs generated for it). There is also (a) "nominally spaced
(run of) glyphs", which is a run of glyphs spaced "normally" in some
sense. The layout manager does not have any layout information more
detailed than the position and range for the nominally spaced runs.
Users of GSLayoutManager, or subclasses of it, are free to use whatever
definition of "nominally spaced" that they want to. This is described
here: http://wiki.gnustep.org/index.php/NominallySpacedGlyphs . As an
example, when doing vertical layout of chinese text, "nominally spaced"
would probably mean that glyphs for hanzi are centered on a vertical
baseline starting at the range's position, and the vertical advancement
is used, and glyphs for western characters may be rotated 90 degrees,
and positioned somehow in relation to this vertical baseline.

[snip]
> 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,

Drawing is very dependent on what kind of layout is being done. A layout
manager that does vertical layout (exclusively, or mixed with horizontal
layout) might want to draw some glyphs rotated. Advanced layout managers
for advanced scripts might work by using DPS* functions to add strokes
programmatically (eg. a special pretty-cursive-writing-print-only layout
manager might want to add precise connecting strokes between characters
by generating bezier paths from connection points on glyphs; elongating
strokes used in full-justified arabic text also comes to mind).

> the handling of text container,

Non-text-view related parts of text container handling are in
GSLayoutManager.

> typing attributes,

This (and a few other ivar:s used by NSTextView) are pure text view
interaction things.

>   text view ruler markers.

Ruler existence and behavior depends on the kind of layout.

> 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.

True, it might be a good idea to decouple the NSTextView-interaction
interface from its implementation. Moving it to GSLayoutManager isn't
good, since for many uses of it, the text view stuff is uninteresting
and unnecessary, so there would have to be another class between
GSLayoutManager and NSLayoutManager. This would probably be a cleaner
approach, but using the approach you mentioned (subclassing and
overriding all layout-specific methods) also works.

> 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?

The new NSStringDrawing implementation (which I and a couple of other
testers are using currently) uses NSLayoutManager, NSTextStorage, and
NSTextContainer directly. The overhead and complexity of NSTextView
isn't needed, and using NSLayoutManager directly gives better control,
so no NSTextView is used.

For advanced high-quality typesetting, NSTextView support will probably
often be uninteresting (it's hard to get reasonable behavior, or it may
be too slow to be suitable for interactive use, or there's simply no
interest in having it, so implementing it is just an unnecessary mess).
For example, there are several scripts for which I would like to write
high-quality typesetters for, but where I intend it to be used to
display and print, not edit.

[snip]
> >>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.

As I said in my other mail, with the latest optimizations, I can edit
150kb worth of text without any problems. If you're still having
performance problems, could you profile it while editing and tell me
where the bottlenecks are now?

[snip]
> > - 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.

Most of them aren't critical, but rtf parsing and producing is very
important, since without it, copy and paste won't work. Anyway, I've
added a couple of test cases for this to the -gui test suite. Getting
them to pass would be very nice.

- Alexander Malmberg