[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [ft] CFF outline rendering problem
From: |
Werner LEMBERG |
Subject: |
Re: [ft] CFF outline rendering problem |
Date: |
Tue, 07 Dec 2010 08:08:58 +0100 (CET) |
In October I wrote:
>> I have tested it and it works. All the glyphs rendered with
>> FT_RASTER_FLAG_DIRECT flag look the same as if they were rendered
>> onto a bitmap.
>
> Unfortunately, this isn't true. Compiling the attached example4.cpp
> and comparing
>
> ./example4 /windows/C/WINDOWS/Fonts/pala.ttf y 200 0
>
> (image `not-direct.png') with
>
> ./example4 /windows/C/WINDOWS/Fonts/pala.ttf y 200 1
>
> (image `direct.png') you can easily see rendering differences. In
> particular, the direct rendering is not correct, producing too wide
> images.
Fortunately, this my suspicion:
> Reason for the mismatch are negative x and y coordinate values in
> the data fed to the smooth renderer, I believe, causing rounding
> errors. In non-direct `mode', the outline is first shifted to have
> no negative coordinates so the problem is not seen.
was incorrect. Comparing the debugging output (using FT2_DEBUG=any:7)
shows that only the colours differ minimally but not the coordinates.
The real problem is that a Qt line consists of at least two pixels!
Doing
painter->drawLine(0, 0, 0, 0);
draws nothing. Consequently, this code in example4.cpp
if (span.len > 0)
painter->drawLine(span.x, y, span.x + span.len, y);
must be replaced with
if (span.len > 1)
painter->drawLine(span.x, y, span.x + span.len - 1, y);
else
painter->drawPoint(span.x, y);
and the shapes become identical. Finally, I've added
painter.setPen(Qt::black);
so that the direct rendering becomes really black also.
I've now added the files to
http://www.freetype.org/freetype2/docs/tutorial/step3.html
Werner
- Re: [ft] CFF outline rendering problem,
Werner LEMBERG <=