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

[Graham Asher]

David,

I have finally got the first version of the unpatented hinting system
working, and I'd like to reveal the design and talk about the architecture,
which is based on a spec from Raph Levien of Artifex, Inc., because I think
you might have some reasonable objections; and if so, we can possibly find
alternatives.

INTRODUCTION

TrueType fonts from Dynalab and possibly other suppliers use hinting recipes
executed by the TrueType bytecode interpreter to form the characters, which
are unusable otherwise. The hinting here is not just for cosmetic purposes
but puts strokes in their correct positions. With such typefaces, the
rendered characters when hinting is disabled using the FT_LOAD_NO_HINTING
flag are completely unreadable.

Artifex commissioned me to implement a work-around for this problem, based
on the idea that if the projection and freedom vectors are not stored, the
patents are not infringed.

HOW TO ENABLE UNPATENTED HINTING

For unpatented hinting to work, the full bytecode interpreter must be
compiled, so you have to define TT_CONFIG_OPTION_BYTECODE_INTERPRETER in
ftoption.h. There are then two ways of using the unpatented hinting system:

(i) Define TT_CONFIG_OPTION_UNPATENTED_HINTING in ftoption.h. This forces
the hinting system to work in the unpatented way, whatever load flags are
passed, when hinting is enabled.

(ii) Use the new load flag FT_LOAD_UNPATENTED_HINTING when loading a glyph.

COMPILING THE UNPATENTED HINTING CODE

Here is a quotation from Raph Levien's specification document:

<<<<<<
At compile time, there should be three choices: no hinting, simplified
hinting only, and full hinting (with the simplified hinting available
as a run-time option).
>>>>>>

To get the first choice, undefine TT_CONFIG_OPTION_BYTECODE_INTERPRETER. To
get the second, define both TT_CONFIG_OPTION_BYTECODE_INTERPRETER and
TT_CONFIG_OPTION_UNPATENTED_HINTING. To get the third, define
TT_CONFIG_OPTION_BYTECODE_INTERPRETER but not
TT_CONFIG_OPTION_UNPATENTED_HINTING, and optionally use
FT_LOAD_UNPATENTED_HINTING at run-time when loading a glyph.

Thus the unpatented hinting code is always compiled when the ordinary
hinting code is compiled. This leads us to the first possible objection,
that this means that ordinary hinting always carries the overhead of
checking for unpatented hinting routines. I suspect that it might be better
to introduce yet another TT_CONFIG_OPTION_ macro to allow the unpatented
hinting system to be compiled only when needed. This makes it a little more
complicated for the user, but I guess it is the way to go. It would give us
a fourth compile-time option on top of Raph's three, allowing full hinting
but not unpatented hinting.  Opinions welcome.

ARCHITECTURE AND METHODS

When unpatented hinting is selected, a new boolean member of
TT_ExecContextRec_, "unpatented_hinting", is set by load_truetype_glyph in
ttgload.c. Everything else happens in ttinterp.c, which uses this value to
decide whether to use the ordinary or unpatented routines. This is where the
overhead occurs: in testing "CUR.unpatented_hinting" frequently.

The way it works is this: instructions that set the projection or freedom
vector call Compute_Funcs to choose function pointers for performing
projection and movement. If unpatented hinting is selected, Compute_Funcs
sets a new boolean value "both_x_axis" in TT_GraphicsState_ to true if both
the freedom and projection vectors point right, or false if not, then throws
away (sets to zero) the x and y values of both these vectors - and that is
the crucial step that avoids the patent, which protects only against methods
that store the vectors. All movement and projection is then along the x axis
or y axis, and involves no computations forbidden by the patents. When only
one of the two vectors is set, the other one is guessed for the purposes of
Compute_Funcs, using the value of both_x_axis, then thrown away again.

TESTING

I have tested the system with the font mingliu.ttc, and text from the 'What
is Unicode' section in the Unicode web site, in both traditional and
simplified Chinese. It seems to work perfectly - because this font uses only
trivial projection and freedom vectors - but I am still delving into the
running code to satisfy myself of that.

SOURCE CODE

Naturally I haven't checked this into FreeType CVS yet, because of my
unwillingness to commit without comments, particularly from you, David, and
particularly to commit something that imposes a run-time speed overhead,
however small, on ordinary hinting. So I enclose the relevant source files
for your information. To find just about everything, search for the string
'unpatented_hinting' in these files.

Best regards,

Graham Asher

unpatented_hinting.zip
Description: Zip compressed data