Bug 687667 - Line width in a Type 1 stroked font
Summary: Line width in a Type 1 stroked font
Status: NOTIFIED FIXED
Alias: None
Product: Ghostscript
Classification: Unclassified
Component: Graphics Library (show other bugs)
Version: master
Hardware: All All
: P3 normal
Assignee: Igor Melichev
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2004-09-09 14:08 UTC by Igor Melichev
Modified: 2008-12-19 08:31 UTC (History)
1 user (show)

See Also:
Customer:
Word Size: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Igor Melichev 2004-09-09 14:08:01 UTC
ppmraw -r300 CAT_LOGO.ps - a line width is bigger in a Type 1 stroked 
Reported by Julia as a regression from Dec 09, 2003.
Reproduced by Igor with today's CVS HEAD

This is moved from bug 687582, which inaccurately grouped 2 different problems.
Comment 1 Igor Melichev 2004-09-15 02:24:18 UTC
Created attachment 897 [details]
Altona-Testsuite_p2_S_x3-.pdf

A reduced test file with a single JPEG inage.
Comment 2 Igor Melichev 2004-09-15 02:26:54 UTC
Comment on attachment 897 [details]
Altona-Testsuite_p2_S_x3-.pdf

Oops, I've attached it to a wrong bug. Please ignore.
Comment 3 Igor Melichev 2004-09-23 09:20:51 UTC
By my computation, the line width must be StrokeWidth * FontMatrix * CTM * 
HWResolution / 72 = 20.48 * 0.052734375 * 0.24 * 300 / 72 = 1.08 pixels. GS 
renders it with 2 pixels width.
Comment 4 Igor Melichev 2004-09-23 10:06:17 UTC
It applies fill adjustment to the stroked path, but the stroked path is 
a 'linewidth' wide area. Likely fill adjustemnt must be zero. With GS_7_0X it 
is zero.
Comment 5 Igor Melichev 2004-09-23 10:15:48 UTC
Well, in GS_7_0X, igs->fill_adjust is set by gs_type1_endchar as a hack agains 
the emboldness. Later we dropped that hack, and now fill adjustment uses the 
default value, which is "any part of pixel inside" emulaton.

We definitely should set it to 0 when stroking a character. The question is 
whether to set it to 0 for any stroking, and whether to do it before or after 
8.50 release.
Comment 6 Igor Melichev 2004-09-27 01:17:34 UTC
With regular "stroke" operation, GS_7_0X sets fill_adjust equal to 0.5 pixels. 
We beliebe it should be zero since the path accounts the line width precisely.
Comment 7 Igor Melichev 2004-09-29 03:33:43 UTC
We did some experimenting with CPSI about stroking lines, which are not within 
a font character. 

With "false setstrokeadjust" it rounds the width to pixels, then applies 
the "any part of pixel inside" rule.

With "true setstrokeadjust" it rounds the width to pixels, then applies 
the "pixel center inside" rule.

In any case, likely it never paints a fractional width, but need to test more 
for sure.

For now, I'll fix the line width in fonts. I'll open an enhancement for 
tracking the rest of the issue.
Comment 8 Igor Melichev 2004-09-29 03:50:50 UTC
See bug 687715 about non-character strokes.