Igor Stasenko wrote:
> 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.

Yes, that is an unfortunate side effect of some of the (unfinished) m17n 
work. If you look at the origins of it (which can be found in 
StrikeFont) the original implementation double-dispatched into the 
display context for precisely this reason:

displayString: aString on: aBitBlt from: startIndex to: stopIndex at: 
aPoint kern: kernDelta baselineY: baselineY
	"Draw the given string from startIndex to stopIndex
	at aPoint on the (already prepared) BitBlt."
	
	^aBitBlt displayString: aString
			from: startIndex
			to: stopIndex
			at: aPoint
			strikeFont: self
			kern: kernDelta.

The idea was exactly not to have assumptions about the backend rendering 
in the font itself.

> 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?

I think the correct way to dispatch it is in Tweak/Croquet where 
DisplayScanner dispatches into the canvas and the canvas can do 
additional transformations. This was needed precisely for the reasons 
you outline above (it allows font substitution for the canvas which is 
extremely handy if you don't like the implementations by the fonts).

For example, check out CTransformCanvas>>displayString: aString from: 
startIndex to: stopIndex at: aPoint font: aFont kern: kernDelta which 
deals properly (but inefficiently ;-) with rotated 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.

See above. The only piece that's *really* missing in the protocol is a 
select operation, e.g., a way to ask a canvas for the closest matching 
font to a given spec.

Cheers,
   - Andreas