Re: [ft-devel] various Type 1 -> CFF issues

[Ewald Hew]

> * Make the old type 1 driver optional.  The file `ftt1drv.h' is
>   talking about a `T1_CONFIG_OPTION_OLD_ENGINE' configuration macro,
>   however, this isn't implemented yet.

I had actually implemented it, but did not commit later on, c.f.
  http://lists.nongnu.org/archive/html/freetype-devel/2017-07/msg00010.html

I had decided that since the new engine incurs so much overhead it
would not be good to use it for scanning advance widths. The old
routine rightly does not initialise any of the glyph rendering
objects, but it would take considerable changes to the new engine to
do the same, which I felt was not worth it.

I could extract the advance width processing from the old interpreter
into a separate function, which gets always compiled in, with the rest
switched by the macro.

> * Implement the `hinting-engine' property for the `type1' module.
>
> * `FT_PARAM_TAG_RANDOM_SEED' is defined twice (in `ftt1drv.h' and
>   `ftcffdrv.h').  I think this should be removed – all properties for
>   the new Type 1 engine should be in `ftcffdrv.h' only, and it's not
>   worth to add random seed control to the old engine.  Do you agree?

I think so too - this is something I overlooked when copying the file
over from `ftcffdrv.h'. I had renamed the class to PS_Driver,
which all three drivers are now using.

The only property there is `hinting_engine'. I differentiated
`FT_T1_HINTING_' from `FT_CFF_HINTING_', but maybe we can just use
`FT_PS_HINTING_' for both.

Ewald