Maybe this one...

2011/4/28 Nicolas Cellier nicolas.cellier.aka.nice@gmail.com:

Oh, I just posted the T.bmp because T.png was bogus, but message is too big and require some kind of approval...

2011/4/28 Nicolas Cellier nicolas.cellier.aka.nice@gmail.com:

...

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.

Nicolas

2011/4/28 Chris Wright cawright.99@gmail.com:

...

Hi folks

I posted this to the beginners' list OSX 10.6.7 Intel Squeak 4.2 update #10977

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!

cheers

Chris

2011/4/29 David T. Lewis lewis@mail.msen.com:

On Thu, Apr 28, 2011 at 11:24:43PM +0200, Nicolas Cellier wrote:

...

2011/4/28 Chris Wright cawright.99@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

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@gmail.com:

...

2011/4/29 David T. Lewis lewis@mail.msen.com:

...

On Thu, Apr 28, 2011 at 11:24:43PM +0200, Nicolas Cellier wrote:

...

2011/4/28 Chris Wright cawright.99@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