[squeak-dev] Problem with Pen class Squeak 4.2 update #10977 on OSX

Nicolas Cellier nicolas.cellier.aka.nice at gmail.com
Fri Apr 29 00:26:58 UTC 2011


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



More information about the Squeak-dev mailing list