Re: [Devel] unpatented hinting system for Dynalab fonts, etc

[David Turner]

Hello Graham, and happy new year to everyone,

Graham Asher wrote:

> David,
>
> I have been asked by Artifex to implement a simple workaround for Dynalab
> fonts and others that use hinting to form their characters, and for which
> hinting is thus essential. The idea is to avoid infringing the patents by
> not a storing free vector or a projection vector in the graphics state, but
> simply an indication of whether they are both in the x axis or the y axis,
> which (Raph Levien believes) is good enough for these fonts. Obviously the
> move instructions won't work properly when the free and projection vectors
> are not identical and do not both point right or left.
>
> Last time I suggested changes to FreeType you were very keen on not changing
> freetype.h and other core header files. This time I think it is necessary to
> change them, but I hope you'll agree that the changes are not obtrusive or
> undesirable. I want to add a new glyph loading flag,
> FT_LOAD_UNPATENTED_HINTING, to freetype.h. I shall also need fttypes.h to
> add a new enumeration for unit vector types, where unit vectors themselves
> are not stored in the graphics state. Although these things are specific to
> TrueType hinting, the present unit vector type is in fttypes.h, so it would
> be confusing to put any equivalent or replacement elsewhere. And I'll have
> to change ttobjs.h, because that contains the definition of the hinting
> graphics state TT_Graphics_State. And lastly I need to add a new
> configuration macro, TT_CONFIG_OPTION_UNPATENTED_HINTING, to ftoption.h. The
> unpatented hinting system needs to be selectable both at compile time and
> (if it is available by being compiled) at run time.
>
> If you would prefer a different arrangement please tell me; but, as I said,
> these changes have a very light and small footprint and don't disturb the
> current way of working.
>  
Introducing a special "mode" to allow a restricted bytecode interpreter 
to run when the user
explicitely ask it shouldn't be a problem at all :-)

I'm however surprised that this change would require a significant 
change in freetype.h (apart
from the definition of a new FT_LOAD_XXX flag or an additional API).

Have you experimented with the NO_APPLE_PATENT macro in "ttinterp.c" ?
If you toggle the #undef to #define on line 46 of this source file, the 
resulting interpreter
will not infringe the Apple patents because, while it still manages both 
a freedom and
projection vector, it never uses them together (even indirectly) to 
compute a distance
to displace points along diagonals. Of course, the result isn't pretty 
for most fonts
(see http://www.freetype.org/patents.html)

Of course, there is still a little work in other parts of the library to 
make this truly usable
by users of the library, but nothing really difficult though.

Isn't this an equivalent, but simpler alternative to what you're 
proposing ? Or maybe
you're thinking about something else. Could you provide an example of 
the new public
types you're expecting and relative changes ??

Best Regards,

- David Turner
- The FreeType Project  (www.freetype.org)

PS: sorry if I seem so snotty sometimes :-)