Re: Progress of text system

[Fred Kiefer]

Hi Alexander,

I didn't find any time to test the text system in the past days, so I
was pretty impressed by doing it today. It now is lightning fast. This
is far more than just usable. Thank you!

There are a few layout glitches left, for example first line indentation 
gets lost while editing the next line, but most of them wont be to hard 
to resolve.
As I wrote in the previous mails, I would have prefered a glyph handling 
that was closer to the way Apple does it, but this is only my personal 
view. I still disagree on the class hierarchy though (see at end of this 
mail).

Alexander Malmberg wrote:
> 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.

In the meantime I had checked this on the internet myself. And yes,
OpenType claims to be able to do all this.


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

Just when I thought, I did understand the reason behind this class
split, I get confused again. So NSStringDrawing will be implemented via
NSLayoutManager not GSLayoutManager, but where is than the example for
the use of GSLayoutManager? Sorry, is it just me being dump? Or is it
rather that an example is hard to find?

(BTW the control view for the drawing of attachments must come from a
focusView call. Otherwise attachments wont work in non text view 
environments)