Yes, Inbox/Graphics-nice.181 fixes the problem. I'm afraid that I
have very little understanding of BitBlt so if someone with better
background can comment, that would be great. Otherwise I'd say please
do include it in trunk.

Thanks,
Dave


On Fri, Apr 29, 2011 at 02:36:57AM +0200, Nicolas Cellier wrote:
> You might want to test Inbox/Graphics-nice.181
> 
> Nicolas
> 
> 2011/4/29 Nicolas Cellier <nicolas.cellier.aka.nice at gmail.com>:
> > 2011/4/29 David T. Lewis <lewis at mail.msen.com>:
> >> On Thu, Apr 28, 2011 at 11:24:43PM +0200, Nicolas Cellier wrote:
> >>>
> >>> 2011/4/28 Chris Wright <cawright.99 at gmail.com>:
> >>> >
> >>> > running the example from the Pen class
> >>> > Display restoreAfter:
> >>> > [Pen new squareNib: 2; color: Color red; turn: 45;
> >>> > ? ? ? ?print: 'The owl and the pussycat went to sea in a beautiful pea green
> >>> > boat.' withFont: TextStyle defaultFont]
> >>> >
> >>> > draws a patterned red line at the correct angle, but with no recognisable text.
> >>> >
> >>> > same problem with the "Terse guide to squeak" Pen example.
> >>> >
> >>> > I'm not sure where to look to see if this is a known problem... and if
> >>> > there's a fix :?
> >>> >
> >>> > and received the following reply from Jerome Peace (thanks!)
> >>> >
> >>> > I tried your code in a 4.3 squeak and got your described results. Went
> >>> > back to a 3.9 squeak and got the results expected with the printing
> >>> > actually working. So I suspect there is a problem. I suspect it is not
> >>> > known. I wonder if the problem is that color is now setting both
> >>> > foreground and background.
> >>> >
> >>> > I am not actively doing bug tracking in squeak right now. So hopefully
> >>> > someone else will look to see what changed. Anyway you have found a
> >>> > real bug. A good place to note it would be on the squeak-dev list and
> >>> > the mantis bug tracker.
> >>> > http://bugs.squeak.org/view_all_bug_page.php
> >>> >
> >>> > So, I'm posting, as instructed!
> >>> >
> >>> One way to understand what is going on is to debugIt
> >>> It seems that Pen>>print:withFont: assumes that the background pixel
> >>> code of the character form is zero.
> >>> This does not happen to be true, is it an effect of anti-aliasing ?
> >>> I join the
> >>> ? ? (form magnifyBy: 16) asMorph openInWorld
> >>> of the first letter T.
> >>>
> >>> The character form is currently of depth 16.
> >>> In my 4.3 updated trunk image, background code seems to be 32767
> >>> (I don't know why 15 bits when form depth is 16, maybe 5 bits per
> >>> color channel...).
> >>>
> >>> I guess the code was written for depth 1 forms (0 = pen up = white, 1
> >>> = pen down = black).
> >>>
> >>> Maybe we can try using this snippet:
> >>> ? ? backgroundColorCode := 1 << (form depth // 3 * 3) - 1.
> >>> This would work both for depth 16 and 1...
> >>>
> >>> Then use:
> >>> ? ? value = backgroundColorCode
> >>> instead of:
> >>> ? ? value = 0
> >>>
> >>> But I'm not sure this hack is general enough...
> >>>
> >>> Anyway, the result still looks ugly.
> >>> Again this is probably related to anti-aliasing.
> >>
> >> The problem is also related to the font being used.
> >>
> >> In 3.8, we have TextStyle defaultFont ==> a StrikeFontSet(Accuny12 12)
> >> In Squeak trunk we are using TextStyle defaultFont ==> a StrikeFont(Bitmap DejaVu Sans 9 14)
> >> And if we use the same font as was used in Squeak 3.8, the example works:
> >>
> >> ?sq38Font := StrikeFont familyName: 'Accuny' size: 12. " ==> a StrikeFontSet(Accuny12 12)"
> >> ?Display restoreAfter: [Pen new squareNib: 2; color: Color red; turn: 45;
> >> ? ? ? ?print: 'The owl and the pussycat went to sea in a beautiful pea green boat.'
> >> ? ? ? ?withFont: sq38Font]
> >>
> >> I think it is somehow related to the bit peeker in Pen>>print:withFont:
> >> which seems to be created incorrectly when using the DejaVu Sans font,
> >> but I'm not sure why.
> >>
> >> Dave
> >>
> >
> > Of course,
> >
> > ((StrikeFont familyName: 'Accuny' size: 12) characterFormAt: $T) depth.
> > -> 1
> >
> > (TextStyle defaultFont characterFormAt: $T) depth.
> > -> 16
> >
> > So I think I explained it above, 0 as hardcoded backgroundColor code
> > just won't work for such depth...
> >
> > Nicolas
> >