t1_hinter__find_best_standard_width() does some calculations but always returns 0.
Created attachment 880 [details] patch1.txt I just tried the obvious fix for that code, and got results, which cannot be qualified as a progression at 300dpi (i.e. not closer to Acrobat Reader 5). At 72dpi the difference is small, but doesn't look as a progression also. Likely at small resolution it should return always 0 to force the standard stem width (the Type 1 spec says so), but at bigger resolutions it may return other values. Maybe 300dpi isn't a big resolution. So likely ignoring StemSnapH, StemSnapV isn't a bad siolution, but the code to be simplified and commented. Unfortunately I can't recall why it was coded so. Maybe at first time it was coded with "return m", then changed for an experimenting, and then left so. In any case, the Type 1 spec isn't so clear, so maybe "return 0" is the right solution.
BTW, Maybe StemSnapH, StemSnapV are for font substitution purpose only ?
Likely FreeType 2 doesn't use StemSnapH, StemSnapV. I found a code that reads and copies them, but nothing more.
There is some processing in UFST.
I tried to return 'm' with the recent patch, but results are still not good. I guess that StemSnap* to be adjusted to the pixel grid, and then decide whether to apply it. If deltas are pretty small, then adjust all to Std*W. With bigger deltas adjust to StemSnap*. With very big deltas don't adjust. Also need to verify our algorithm. Delaying this for better times.
Adobe Technical Note #5049 defines the logic.
Created attachment 1937 [details] patch1.txt An experimental patch according to Adobe Technical Note #5049. Need to decide whether it is applicable at small resolutions.
Created attachment 1939 [details] patch2.txt A better experimental patch.
Created attachment 1943 [details] patch3.txt An improved patch - needs a visual testing with humans.
Created attachment 1945 [details] patch4.txt A better patch (Cygwin/gcc warning cleaned).
Created attachment 2000 [details] patch5.txt A more improved patch : debugged a mixing of pixel_gh, pixel_gw.
Created attachment 2026 [details] patch6.txt A better patch, includes a fix for t1_hinter__align_stem_commands start with an off-curve pole.
Created attachment 2029 [details] patch7.txt The last patch skips too many poles, causing a regression with S2_Digitalproof-Forum_x3k.pdf. Attaching a better one.
Patch to HEAD : http://ghostscript.com/pipermail/gs-cvs/2006-February/006347.html This patch also fixes the bug 688553.