Re: [ft-devel] severe unpatented hinting problem

[David Turner]

Hi Werner,

I believe that unpatented hinting doesn't make sense if you already
have the bytecode interpreter. This is why the code has been updated
some months ago to ignore the UNPATENTED_HINTING macro when
BYTECODE_INTERPRETER is already defined. 

I just updated the documentation in ftoption.h to reflect the current
behaviour; it now looks like:

  /*************************************************************************/
  /*                                                                       */
  /* The TT_CONFIG_OPTION_UNPATENTED_HINTING macro is *ignored* if you     */
  /* have defined TT_CONFIG_OPTION_BYTECODE_INTERPRETER. If not, it will   */
  /* compile a special work-around TrueType bytecode interpreter that      */
  /* doesn't implement any of the patented opcodes/algorithms.             */
  /*                                                                       */
  /* this is only useful for a small number of font files (mostly Asian)   */
  /* that require bytecode interpretation to properly load glyphs. For all */
  /* other fonts, this will produce unpleasant results.                    */
  /*                                                                       */
  /* for this reason, the unpatented interpreter is never used by to load  */
  /* glyphs from TrueType fonts, unless one of the following happens:      */
  /*                                                                       */
  /*   - the unpatented interpreter is explicitely activated by the        */
  /*     user through the FT_PARAM_TAG_UNPATENTED_HINTING parameter tag    */
  /*     when opening the FT_Face                                          */
  /*                                                                       */
  /*   - FreeType detects that the FT_Face corresponds to one of the       */
  /*     'trick' fonts (e.g. Mingliu) it knows about. The font engine      */
  /*     contains a hard-coded list of font names and other matching       */
  /*     parameters.                                                       */
  /*                                                                       */
#define TT_CONFIG_OPTION_UNPATENTED_HINTING


Hope this helps,

- David

On Sun, 10 Jun 2007 07:45:58 +0200 (CEST), "Werner LEMBERG" <address@hidden> 
said:
> 
> Folks,
> 
> 
> the current CVS code of FreeType contains the following #if
> clause as the central part of handling unpatented hinting:
> 
>   in ttobjs.c:
> 
>     #if defined( TT_CONFIG_OPTION_UNPATENTED_HINTING    ) && \
>         !defined( TT_CONFIG_OPTION_BYTECODE_INTERPRETER )
>     ...
> 
> However, the documentation of TT_CONFIG_UNPATENTED_HINTING says:
> 
>   Define TT_CONFIG_OPTION_UNPATENTED_HINTING (in addition to
>   TT_CONFIG_OPTION_BYTECODE_INTERPRETER) to compile the unpatented
>   work-around hinting system.
> 
> Note the `in addition'.  This is exactly the opposite of what the code
> does.  Now the question: Shall we update the documentation to follow
> the code, or fix the code so that it follows the documentation?
> 
> I favour the latter (which additionally makes more sense for me
> because you have to use the bytecode interpreter even for unpatented
> hinting).
> 
> To make things even more confusing we have
> 
>   /* #define TT_CONFIG_OPTION_BYTECODE_INTERPRETER */
>   #define TT_CONFIG_OPTION_UNPATENTED_HINTING
> 
> in the default ftoption.h file -- something which shouldn't happen if
> you strictly follow the documentation...  Note that if you compile the
> CVS version of FreeType out of the box, you get the right unpatented
> hinting, but as soon as you start reading the docs you'll get slightly
> irritated :-)
> 
> Since I've never used the unpatented hinting stuff by myself (except
> for very superficial testing), I'm not sure whether the documentation
> was wrong before.
> 
> Comments, please!
> 
> 
>      Werner
> 
> 
> _______________________________________________
> Freetype-devel mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/freetype-devel