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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Andrew Magill Sent: Wednesday, April 30, 2008 6:44 PM To: Werner LEMBERG Cc: [email protected] 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:[EMAIL PROTECTED] Sent: Tuesday, April 29, 2008 11:54 PM To: Andrew Magill Cc: [email protected] 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 [email protected] http://lists.nongnu.org/mailman/listinfo/freetype _______________________________________________ Freetype mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/freetype
