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
_______________________________________________
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel