Re: typesetting text

[Nicola Pero]

Hi Fred, 

first let me compliment with you on your work - I'm reading the NSText*
source now and I see really much good has been done from the last time
(nearly an year) I seriously tried reading NSText.

> (The difference is that there may be different fonts used in one word)

That's a very good point !  I suppose a font change would be considered
sort of an additional `word' (/`box') separator.

> Your comment on the NSLayoutManager methods is a bit hard, perhaps some
> of the methods really look as if the where very internal. After trying
> to understand how a layout manager could work I had to admit that most
> of those methods would be rather useful to implement one. Methods like
> setLocation:forStartOfGlyphRange: are just what you proposed for
> defining the length of a "word" and placing it inside of a line (here
> called a line fragment).

I thought about it in the meanwhile and I quite relaxed my criticism.

Basically - correct me if I am wrong - as far as I understand, when you
draw a string using postscript, you first set a font, then call a show
operator, passing as argument a set of `characters' to show.  Postscript
calls these `characters', but they really are indexes in the font table of
symbols - each of these `character's is looked up in the table and
rendered with a single symbol.  In the NSLayoutManager documentation,
these `characters' are called `glyphs' - I will call them glyphs too to
stop confusion.  Usually, if the font is in a certain encoding, these
`glyphs' can be simply computed by converting the string in that encoding.
To get ligatures, this is not enough - certain special glyphs need to be
used to render some aggregates of characters. 

Which means that, if you are using a postscript backend to render the
text, you must always go through the following path to render text: 

* from the unicode string, get the indexes in the font table (the
`glpyhs').  This simply involves converting the string to the encoding of
the font if you are typesetting Western languages without ligatures; it
requires a simple algorithm to compute ligatures in the same case with
ligatures; it involves a potentially extremely complex algorithm for
languages with complex ligatures;

* Then, you get the bounding box of each glyph using postscript operators,
and using some algorithm of your choice, you compute the layout (ie, where
to draw each glyph). 

* You draw the glyphs by calling the postscript operators.

If this description is correct, then *any* way of laying out text which
draws using the postscript operators will need to compute the glyphs
before and independently from laying out or drawing.

In this order of ideas, any respectable layout manager will have to
compute glyphs - whatever the way it lays out text - and can be expected
to cache all the computed glyphs.

So - in this order of ideas, I must shut up about being inappropriate for
NSLayoutManager to expose glyphs (but not about methods concerning the
internals of text layout which should be private because - as Ovidiu
pointed out - there are extremely good layout algorithms which are quite
complex and refined and which we could try to implement - even if they
are not the ones which were used by Apple when they implemented
NSLayoutManager originally). 

Still - still while these considerations make me think doing glyphs more
or less the way documented in NSLayoutManager is a good idea (if not the
only possibility), still there are reasons not to expose the glyphs in the
API (reasons in order of increasing importance):

 * it is possible to imagine situations or algorithms so complex or
   refined that the choice of glyphs may depend on the layout.
   For example - it is possible to imagine an algorithm to layout which 
   will make the ligature 'fi' only if the spacing between letters 
   is little or normal, while avoid it if the letters are very spaced
   between them as a consequence of a difficult layout.
   
 * we are not sure we are going to always have a postscript based backend.
   Future drawing environment could provide simple string drawing primitives 
   which just draw unicode.  In this case, glyph generation is done in the
   string drawing primitives, so there is no reason why we should bother
   with glyphs in our own library.

 * the glyph information is not useful outside the layout manager
   internals.  Why making it part of the public API then ? 

At this point, my objections to the doc are really very little.  I am for
implementing the doc more or less how it is, but separating
NSLayoutManager into an abstract class - containing the methods we are
sure we will always support in NSLayoutManager - and a concrete class -
where we put all the glyphs and layout and private methods.  Most of these
methods will actually be the same as in the NSLayoutManager doc, but we
would reserve the rights to completely revise our layout
engine/algorithms/backend interface removing/modifying all these private
methods.  The other NSText* classes would access NSLayoutManager only
through the public API.  The class cluster organization could also be used
to make clear which methods need to be implemented in the concrete class
to get a new working layout manager reusing the abstract class public
code. 

> When pasting or when setting any text attributes there are big bunches 
> of characters that must be handled at once. In the old NSText code there 
> was a lot of very specific "optimization" of single characters, that in the 
> end turned out to be slower than doing it right for all changes. 
> So please, spare up those optimization until the very end.

OK - thanks for the suggestion.

> What is missing in your paper is a discussion on how layout could be
> processed in the background. This will make everything a lot more
> complex, but will speed up things from the users point of view.

Uhm - this is actually very interesting stuff.  It shouldn't be difficult
to do something in the background - the problem is how to do little bits
of it - probably glyph generation - which is localized - can be more
easily done in very little chunks in the background.  

Layout could also be done in the background if it is possible to separate
little chunks/steps in the algorithm which do not leave the data
structures in inconsistent state - that probably depends on how we do it.