RE: [ft] Patent issues

[Andrew Magill]

  If anybody on the list is interested in an easy workaround to this
bug, I've just figured out that if the transformation offset is null
when the *first* autohinted glyph is loaded, the problem never seems to
show itself.  So just paste these lines in right after loading your
face:

  FT_Set_Transform(face, 0, 0);
  FT_Load_Char(face, 'a', FT_LOAD_FORCE_AUTOHINT);

  You might want to be cleverer than I about choosing a glyph that's
guaranteed to be present and to invoke the hinter.  I tried just loading
glyph 0, but it didn't do the trick.

  -Andrew


-----Original Message-----
From: address@hidden
[mailto:address@hidden On Behalf Of
Andrew Magill
Sent: Wednesday, April 30, 2008 6:44 PM
To: Werner LEMBERG
Cc: address@hidden
Subject: RE: [ft] Patent issues


  It seems my predecessor on this project was a bit too hasty in
completely rejecting the autohinter, and I in agreeing with him.  Having
independently reproduced the ugliness that led to that decision, I just
assumed what I was observing was a fundamental limitation.
  It does seem we've stumbled across a bug, after all, and I've tested a
workaround that produces beautiful text.  If you can just briefly
confirm that I'm not doing something stupid, I'll go ahead and file a
bug report in the morning.
  Here's a code snippet you can reproduce it with:

/* BEGIN demonstrate autohinter bug
 * It seems that applying any transformation where the pen's
y-coordinate
 *  is nonzero causes the autohinter to produce characters of
distractingly
 *  inconsistent height.  Insert this code snippet in ftdiff.c line 420,
 *  just after the variable declarations of render_state_draw().
 */
FT_Matrix   matrix;
FT_Vector   offsetPen;
matrix.xx = matrix.yy = (FT_Fixed)0x10000L;   /* Identity matrix */
matrix.xy = matrix.yx = (FT_Fixed)0x00000L; 
offsetPen.x = 0;
offsetPen.y = 1<<6;
FT_Set_Transform(face, &matrix, &offsetPen);
/* Enable the bytecode interpreter, to show how it has no such problem
*/
FT_Face_SetUnpatentedHinting(face, 1);
/* END demonstrate autohinter bug */

  I hope it's rather self-explanatory.  This isn't an example of how I
was using the transformation in my code, merely the simplest reproduce
case I could devise.  My code actually used the transformation technique
described in section 7c of the tutorial.  Avoiding FT_Set_Transform()
altogether (as in 7b) works around the problem.  I've been testing with
Arial.ttf on my Windows machine.
  Thanks for the nudge in the right direction!

  -Andrew


-----Original Message-----
From: Werner LEMBERG [mailto:address@hidden 
Sent: Tuesday, April 29, 2008 11:54 PM
To: Andrew Magill
Cc: address@hidden
Subject: Re: [ft] Patent issues


> The autohinter has been previously rejected because it produces
> distractingly inconsistent character heights below 18px tall (but only
> with even pixel heights?).

Hmm.  This is a bug then.  Can you prepare something and put it into
the bug tracker?

> I've tried Arial from my Vista machine and from an XP machine, as
> well as a dozen other fonts, scaled them up and down, and they all
> look great with the native hinter.. just as Windows rasterizes them.

Good :-)

>   So why does the unpatented native hinter look so much better for
> me than the web site says it should?  Are there specific situations
> I'm missing that reproduce the rendering artifacts?

There is just a very small set of instructions related to diagonal
lines which are affected by the Apple patent.

>   Just to confirm, using the binaries from sourceforge,

We do provide binaries?  You probably mean archives, do you?

> it is impossible to activate the patented hinter at runtime, right?

Yes.

> I'd have to alter ftoption.h and recompile in order to violate the
> patents.

Yes, but please read the comment for
TT_CONFIG_OPTION_UNPATENTED_HINTING how to actually activate the
native bytecode interpreter for fonts which are not in our compiled-in
`whitelist' of CJK fonts which need this option unconditionally.

It's probably easiest to compare the different hinting modes with
either ftdiff or ftview.  Additionally, you might compare a normal
FreeType build (make; make) with a developer's build (make devel;
make) -- the latter activates the patented bytecode interpreter
automatically.


    Werner


_______________________________________________
Freetype mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/freetype