OK, after a couple of weeks rewriting how Scratch draws tiles I'm back to looking at dear old scanners and fonts. 

After side-by-side comparing the old scanners  with the new 'Multi' scanners, my conclusion is that there is *very* little difference and we really ought to be able to go back to a single set of classes. Which, I claim, would be nice, since we've already visibly suffered from the obvious side-effect of having two trees as bug fixes get added to only one part.

So far as I could tell the only substantive difference relates to the use of the presentation/presentationLine ivars which seems to be not very important (ref Yoshiki's message 8 sept) and even seems to be mostly inactive (ref nice's message regarding  Multilingual-nice.116 same date). It would be really nice to get a solid decision on whether it is still wanted, or should be removed, or if it needs some fixes that can be provided.

I'm puzzled by quite a few things I've discovered. 

a) There are {language}environment classes and encoding classes. There is #isBreakableAt:in: implemented in both but seemingly unused in the encoding classes because it is just plain broken there. Should it be removed from the encoders? In the language environment classes it is implemented to return true for space and cr by default, but space, cr & lf in Latin1 and Latin2. Is that as expected?

b) MultiCharacterScanner>setConditionArray: cuts out the handling of #space - any ideas why?

c) as previously mentioned MultiCharacterScanner>addCharToPresentation: is currently unused, apparently because of issues with Unicode & #scanMultiCharactersCombiningFrom:to:in:rightX:stopConditions:kern:  - do we have any decent hope of a fix?

d) MultiCanvasCharacterScanner>setFont uses baselineY differently to its CanvasCharacterScanner equivalent; why?

e) TextComposer>composeLinesFrom:to:delta:into:…. differs minimally from MultiTextComposer>multiComposeLinesFrom:to:delta:into:…. and is the only sender of #canComputeDefaultLineHeight. What is the intent? Is this just a bug fix added in one place and not the other?

f) one of the oddest - DisplayScanner>displayLine:offset:leftInRun: passes the displayString:.. to the font (which I see as good) but MultiDisplayScanner uses the bitlblt instead which seems quite wrong.

That'll do for now. I hope we can get some information together to allow this to be improved since it should really simplify an important area of code that gets a lot of exercise and needs to be as fast as possible. I know most of you are running 128 core 75GHz machines with  42Tb of ram and so on, so it hardly matters, but there are over a million Pi's trying to run Scratch that need help. And there will almost certainly be *many* millions more trying to use Scratch and Squeak over the next year or so, scattered across parts of the world where a Pi is more computer than anyone could have imagined a year ago - Pi is probably going to be *the* platform in sub-Saharn Africa and much of Asia. Let's at least try to make it good, eh? This is what Smalltalk has always claimed to be about.

tim
--
tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
Strange OpCodes: AGO: Allow Games Only