| Summary: | t1_hinter__find_best_standard_width() always returns 0 | ||
|---|---|---|---|
| Product: | Ghostscript | Reporter: | Alex Cherepanov <alex> |
| Component: | General | Assignee: | leonardo <leonardo> |
| Status: | NOTIFIED FIXED | ||
| Severity: | minor | ||
| Priority: | P4 | ||
| Version: | master | ||
| Hardware: | All | ||
| OS: | All | ||
| Customer: | Word Size: | --- | |
| Attachments: |
patch1.txt
patch1.txt patch2.txt patch3.txt patch4.txt patch5.txt patch6.txt patch7.txt |
||
|
Description
Alex Cherepanov
2004-09-03 05:18:47 UTC
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. |