[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Infinality
Subject: Re: [ft-devel] severe problems with subpixel hinting
Date: Mon, 14 Jan 2013 21:55:10 -0600
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0

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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]