Re: [ft-devel] severe problems with subpixel hinting

[Infinality]

Hi Werner,

> > As far as this specific Verdana issue goes, I've narrowed it down
> > (strangely enough) to the NO_DELTAP_AFTER_IUP_Rules tweak.
> Interesting.  In case you can nail down a precise example, I can
> contact Greg, asking for clarification.
Don't worry about bothering him, especially given that the reason it was 
failing is based on a tweak I made that isn't something he ever 
mentioned in the whitepaper....  unless I'm misunderstanding your reason.


> > I'm also looking at creating a variable inside TT_DefRecord called:
> > FT_ULong sph_fdef_flags [...]
> This looks like a good idea.  Given that I want to control
> `properties' of the bytecode renderer, this is, setting the emulated
> renderer version, moving away from compile-time configuration only is
> certainly a step into the right direction.

So, I think I have something that's roughly working on my system, and 
still maintaining similar performance to native TT rendering.  I have 
created "sph_fdef_flags" inside of the TT_DefRecord, and 
"sph_in_func_flags" and "sph_found_func_flags" inside of 
TT_ExecContextRec.  It seemed a bit overkill at first, but I think there 
is a need to differentiate between  1) A FDEF that matches a signature, 
2) Knowing that you are currently in the context of that function, and 
3) Knowing that a signature has been found.  The latter two seem to fit 
the execution context most of all.  If you think they belong somewhere 
else, let me know.

They all use the same binary flags for simplicity:
#define SPH_FDEF_INLINE_DELTA_1                   0x0000001
#define SPH_FDEF_INLINE_DELTA_2                   0x0000002
#define SPH_FDEF_DIAGONAL_STROKE                  0x0000004
#define SPH_FDEF_VACUFORM_ROUND_1                 0x0000008
#define SPH_FDEF_TTFAUTOHINT_1                    0x0000010
#define SPH_FDEF_SPACING_1                        0x0000020
#define SPH_FDEF_SPACING_2                        0x0000040

I've restricted (most of) the opcode pattern recognition down to the 
function ranges (for each type of function) that Greg specified in the 
whitepaper.  For example, the diagonal stroke function signature should 
only be checked on function 58.  So, there is now a switch/case to only 
look for that signature in that numbered function, and then the flag is 
set accordingly.  Similarly, I've done that for the spacing functions 
too.  Then at runtime, DO_RS() will return a 0 only when the certain RS 
location is requested for respective functions.  This should reduce / 
eliminate any false positives, and is the way I should have approached 
it to begin with.  There's still more to do, because some parts of the 
paper are vague.  Maybe I'll make a list of things that are unclear and 
we can send it to Greg.

I still haven't replicated the issue you mentioned about B/W text being 
rendered all crappy (but, I haven't tried it yet either). However, I 
have found spots where I should have checked the condition 
"ignore_x_mode" and didn't.  I know for sure that this could cause 
problems with B/W rendering if subpixel hinting was enabled at compile 
time.  In most cases, ignore_x_mode should be checked whenever 
TT_CONFIG_OPTION_SUBPIXEL_HINTING is defined, because it's essentially 
doing the same thing, just at runtime instead of compile time.  Within 
the next few days hopefully I will test this out and verify whether this 
fixes that problem.

There haven't been many breakthroughs yet as far as eliminating tweak 
rules goes (although some rules may be able to go away soon). But I'm 
hoping that better approximating what is in the whitepaper can lead me 
there.

Regards,
Erik