[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [ft] Patent issues
RE: [ft] Patent issues
Wed, 30 Apr 2008 18:43:37 -0600
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
* is nonzero causes the autohinter to produce characters of
* inconsistent height. Insert this code snippet in ftdiff.c line 420,
* just after the variable declarations of render_state_draw().
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
/* 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!
From: Werner LEMBERG [mailto:address@hidden
Sent: Tuesday, April 29, 2008 11:54 PM
To: Andrew Magill
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.
> 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?
> I'd have to alter ftoption.h and recompile in order to violate the
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