[squeak-dev] [Squeak 0007694]: Buggy drawing of text by Pen class
nicolas.cellier.aka.nice at gmail.com
Mon Jul 16 18:39:31 UTC 2012
An also remember that if current font is rendered with anti-aliasing,
then there will be way to much red ink in the reproduction...
So Pen>>print:withFont: is definitely not modern-font-rendering-proof.
2012/7/16 Nicolas Cellier <nicolas.cellier.aka.nice at gmail.com>:
> 2012/7/13 David T. Lewis <lewis at mail.msen.com>:
>> On Fri, Jul 13, 2012 at 08:39:17AM +1000, Chris Wright wrote:
>>> Hi folks
>>> I posted this bug on the Mantis system
>>> and Ken Causey helpfully suggested that I might post it here:
>>> OSX 10.7.4
>>> Squeak 3.4 update#11860 <http://bugs.squeak.org/view.php?id=11860>
>>> 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 text at the correct angle, but the text is patterned
>>> same for defaultNib:1
>>> screen shot at
>>> any help appreciated!
>> I added a note to the Mantis issue:
>> I tried this on Linux and get the same results, so it is not platform
>> dependent. I also tried on an old Squeak 3.6 image (also on Linux),
>> and got similar results except that the default font is different, with
>> Squeak 3.6 using a StrikeFont(NewYork10 12) and Squeak trunk using a
>> StrikeFont(Bitmap DejaVu Sans 9 14). So I suspect that this is not so
>> much a bug as an existing limitation of the Pen class when drawing
>> these fonts.
> Yes, take a look at Pen>>print:withFont: , it naively iterate on the
> rows of the source form and plot pen down each batch of pixels set to
> 1, up each batch of pixels set to 0.
> This chance of producing artefact free drawing with an oblique angle
> and such an algorithm is near to zero.
> This is an intrinsic limitation of the method.
> I don't see how the Pen could access the path defining the letter, as
> long as Font architecture rely on simple and dumb bitmaps. So the
> chances of seeing this method corrected in short term are also close
> to zero.
> Of course, we could use a third party renderer instead of trying to
> fill the gap.
More information about the Squeak-dev