On 21/03/2008, Andreas Raab <andreas.raab at gmx.de> wrote:
> Igor Stasenko wrote:
>  > My humble 2 cents.
>  > Fonts require a complete refactoring:
>  > - in a ways how font interacts with canvas
>  > - in a ways how font interacts with primitives (if any)
>  > - use more simplified approach for rendering
>
>
> I disagree. Look at AbstractFont and tell me what is complicated about
>  it, or how it should interact differently with canvas or how it could
>  use a "more simplified" approach for rendering. Fonts in Squeak are
>  trivial - they have a tiny protocol to install, measure and display text
>  and that protocol is fundamentally sound. It is *very* easy to create a
>  new subclass of Font and have it your way. What is messed up in Squeak
>  isn't fonts, it's TextStyle, Paragraph, and CharacterScanner.
>

Of course, i didn't meant fonts alone.

What i don't like in fonts protocol in particular, is that it's main method

displayString: aString on: aDisplayContext from: startIndex to:
stopIndex at: aPoint kern: kernDelta baselineY: baselineY

assuming that DisplayContext is a BitBlt instance, which bounds us
only to one glyph rendering target/technique - rasterisation.
Which is very suboptimal in case if we want to render vector font to a
device witch capable to render vectors, not just pixels. See how
TTCFont implemented , and see that #formOf: should be used only if
device is incapable to render glyph represented by filled beizer shape
or polygon.

It's also unclear, if i'd like to have own kind of DisplayContext ,
what protocol i should implement to be sure that it will be used
correctly by fonts?
Obviously, i don't want to fully implement bitblt only because there
is a chance that future fonts will use methods from it.
So, at least we need a class DisplayContext (or like) to represent an
abstraction layer for fonts rendering. Or if not, then use canvas
instead, and let font render itself by passing commands to canvas.


-- 
Best regards,
Igor Stasenko AKA sig.