>> A misunderstanding. I believe that Alexei meant
>>
>> #define TT_CONFIG_OPTION_SUBPIXEL_HINTING 1 /* infinality */
>> #define TT_CONFIG_OPTION_SUBPIXEL_HINTING 40 /* new code */
>> #define TT_CONFIG_OPTION_SUBPIXEL_HINTING 41 /* both */
>>
>> or something similar.
>
> I.. don't get it. How is that a practical improvement over splitting
> TT_CONFIG_OPTION_SUBPIXEL_HINTING into
>
> #define TT_CONFIG_OPTION_SUBPIXEL_HINTING_V38
> #define TT_CONFIG_OPTION_SUBPIXEL_HINTING_V40
>
> ? That would remove the currently used macro and more accurately
> describe what it's doing. Or does the current macro have to stay?
I think we would have the following benefits.
. There is a lot of code that is identical to the Infinality and lean
code, which could be then simply tested with
#ifdef TT_CONFIG_OPTION_SUBPIXEL_HINTING
. In the future, if we are going to remove the Infinality code, we
could again have a simple
#define TT_CONFIG_OPTION_SUBPIXEL_HINTING
in the configuration file, ignoring the macro's actual value.
Werner
_______________________________________________
Freetype-devel mailing list
[email protected]
https://lists.nongnu.org/mailman/listinfo/freetype-devel
