Re: New text system implementation

[Alexander Malmberg]

Fred Kiefer wrote:
> 
> Hi Alexander,
> 
> I am quite impressed by your scrren shots from the new typesetting
> environment. This is a lot more than our current system support (and
> even this is capable of more than most GNUstepers will know).
> 
> This surely is the way to go! But your description leaves a few
> questions open:
> 
> Is the new implementation finally also taking over the string drawing
> code? All the text displayed on the screen should be done by a layout
> manager. Currently we have just the other way round, the layout manager
> uses the string drawing code.

Yes, the new system does its own drawing, and anything else that draws
strings (NSCell and subclasses, I think) should use it. I've thought
about how to solve this, but I haven't started working on it.

> Would this new type setting also work as a background process?

It could, but it would need extensions in NSRunLoop.

> You also mention that there are more methods needed for the interaction
> between text views and the layout manager, but you don't list them. What
> is missing?

Cursor handling, mostly.

Methods to get the position the cursor should be drawn at (something
like: -(NSRect)cursorPositionAtCharacter: (unsigned int)char_index 
beforeCharacter: (BOOL)b). This method would handle all the specifics
(like cursor movement within composited characters and ligatures), and
can handle the cursor even when there's no text.

Methods to move the cursor, something like: -(unsigned
int)characterPositionMoving: (int)up_down_left_right_somehow from:
(unsigned int)char_index.

(There is a - (unsigned) _charIndexForInsertionPointMovingFromY:
(float)position
                                              bestX: (float)wanted
                                                 up: (BOOL)upFlag
                                      textContainer: (NSTextContainer
*)tc;
However, it only deals with up/down (assuming left=char_index--,
right=char_index++, doesn't allow non-horizontal layouts, and is
probably false for mixed left-right/right-left text as well), and
passing in coordinates instead of character indices makes it a lot
harder to handle movement within ligatures.

These are the "more than is there now"; if you meant "more than in
OPENSTEP/apple", there are a few more things. Also, I've worked on the
behind-the-scenes classes in isolation most of the time, and only
started working on the NSTextView parts recently, so other things might
turn up.

> You also did not explain how this requires support from the backend,
> glyph generation can only be done by the backend with specific knowledge
> on the fonts. For which backends did you implement this?

back-art, the code in ftfont.m (based on freetype; should be usable in
back-xlib with client side fonts and xrender as well). There is a
default implementation in GSLayoutManager that maps unicode characters
directly to glyphs; a backend then only needs to implement
GSShowGlyphs() as accepting a unicode string.

(However, -xlib's font handling could be improved by this. Glyphs are
32-bit values, so -xlib could eg. use the top 16 bits as a "font index"
and the lower 16 bits as the glyph index in that font, and thus handle a
font being available in many encodings (like
"adobe-helvetica-...-iso8859-1" and "adobe-helvetica-...-iso8859-2").)

> I also don't understand the proposed class hierarchie for layout
> managers. Why should NSLayoutManager be the sub class that is restricted
> to horizontal layout. I rather would expect this to be the more general
> super class, whereas there is a GSHorizontalLayoutManager that does the
> more specific things.

I think this is more logical as well, but OPENSTEP (and apple, at least
currently) has a horizontal-only layout manager called NSLayoutManager.
Renaming it makes sense, but breaks compatibility. This is a minor
issue, so I think it's better not to break compatibility, but it isn't
horribly important to me.

> Could you also provide some details about the difference from your
> typesetter classes to the Apple ones?

I'd be happy to, once I've actually figured out what they are :).

There are two problems here:

I haven't figured out exactly what the interface should be like. You can
see the current interface at:
http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/core/gui/Headers/gnustep/gui/Attic/GSTypesetter.h?rev=1.1.2.1&only_with_tag=text-system-branch&content-type=text/vnd.viewcvs-markup
and I have a working but incomplete GSHorizontalTypesetter based on
this. This is still just a first try, and "plan to throw one away...".

The second problem is that apple's docs aren't very clear.

For example, GSHorizontalTypesetter has a
-breakLineByWordWrappingBefore: (called with the glyph index of the
first glyph not to fit on the line; glyphs cached and layout information
filled in up to and including this glyph; should return the index of the
first glyph not to be laid out in this line frag rect; can be any glyph,
but the index might be adjusted (eg. to make sure no line frag rect is
empty), and if the index is beyond the passed in index, it must fill in
layout information for the glyphs up to the index it returns; not
decided yet whether this method needs to deal with trailing whitespace
on a line, currently it doesn't).

NSSimpleHorizontalTypesetter has
-glyphIndexToBreakLineByWordWrappingAtIndex:, which probably does
something similar, but there's no way of telling exactly what it does
from apple's docs:
http://developer.apple.com/techpubs/macosx/Cocoa/Reference/ApplicationKit/ObjC_classic/Classes/NSSimpleHorTypesetter.html#//apple_ref/occ/instm/NSSimpleHorizontalTypesetter/glyphIndexToBreakLineByWordWrappingAtIndex:

> I am looking forward to the time, where I can use this code myself!
> 
> Keep this good work up
> Fred

- Alexander Malmberg