[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:36:57 UTC 2011


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
>



More information about the Squeak-dev mailing list