> > The scanning primitive was needed  to support real advances 
> > and not the width of a glyph, I think this way the text looks
> > much better. Maybe we can do away with the scanning primitive
> > all together I don't know if this is fast enough...

Very likely it is.

>   Yes, but it still could be done at the Squeak-level code by adding
> a primitive that returns the (fractional) advance width of a character
> or something.
> 
>   The reason I like the Squeak-level code is that it gives us more
> flexibility.  To compose some wierd scripts such as Japanese, you want
> to have some "programmability" in scanning.

Yup. I've often been thinking about some "completely different" character
scanning primitive which takes stuff like overhang, underhang and kerning
pairs into account. It would be really good if this could be mocked up in
Squeak first (screw the speed! ;-) and then, once we understand how it has
to work, be brought down to a primitive implementation. 

Hm ... perhaps it is even wortwhile to make the actual scanning method
depending on the font you use ... this could mean that we have different
scanning methods based on the fonts we use and would make a nice pairing
with the BitBlt support required... something along the lines of calling
aFont>>scanCharactersIn: aScanner which then double dispatches back into the
scanner (scanStrikeFont: etc). Yoshiki, what do you think? Would this make a
nice match for some of the multi-lingual stuff?

> > >> * Not Unicode
> > >
> > >   What do you mean by this?
> > The primitives go only to 256 characters as well as the 
> > font reading and converting it would'nt be too hard to support
> > more chars but this would depend on fall-back code.
> 
>   The hard part is the scanning rule implementation, I think.

Really? I wouldn't think so. For example, consider that we organize all
multi-byte character fonts into some sort of "code pages" (8 or 16 bit for
example [*]) where the primitive would only work on the set of characters
within the "current page". If it encounters any other it merely fails. Then,
we back up on the ST side by handling the failure code (in this situation:
look up the new code page for the prefix in question) and resume the
primitive. This scheme could be implemented today (just use prefix zero
which I think is the default in your multi-byte strings anyways) and would
allow us to organize fonts efficiently around the pages which are actually
used (e.g., you wouldn't even have to load parts of some TTF if you don't
use Korean or somesuch).

[*] I don't know if there are any character sets where the frequencies
justify using 16bit code pages but I think we should leave the option open.

Cheers,
  - Andreas