freetype
[Top][All Lists]
Advanced

[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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]