Bug 687385 - fonts different heights with 75 dpi
Summary: fonts different heights with 75 dpi
Status: NOTIFIED FIXED
Alias: None
Product: Ghostscript
Classification: Unclassified
Component: PS Interpreter (show other bugs)
Version: master
Hardware: All All
: P2 normal
Assignee: Igor Melichev
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2004-03-23 14:18 UTC by Jack Moffitt
Modified: 2008-12-19 08:31 UTC (History)
0 users

See Also:
Customer:
Word Size: ---


Attachments
gs-test.tar.gz (12.25 KB, application/octet-stream)
2004-03-23 14:22 UTC, Jack Moffitt
Details
y.bmp (34.10 KB, application/octet-stream)
2004-03-24 05:44 UTC, Igor Melichev
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Jack Moffitt 2004-03-23 14:18:18 UTC
User reports that fonts are different heights when rendering at 75 dpi (instead
of default 72) as well as some nearby values such as 73-76.  This was reported
using the x11alpha driver, but I have reproduced with png16m as well.  Sample
files plus screenshots attached.
Comment 1 Jack Moffitt 2004-03-23 14:22:09 UTC
Created attachment 584 [details]
gs-test.tar.gz
Comment 2 Igor Melichev 2004-03-24 05:44:55 UTC
Created attachment 586 [details]
y.bmp

Attaching a draft about grid-fitting the character y at 72 dpi with no
antialiasing. The pole 4 is the right upper corner. The next pole 5 has an Y
coordinate greater than the Y coordinate of the pole 4, and the difference is 2
times greater than BlueFuzz. Therefore the segment doesn't recognize as a
horizontal one, and the horizontal alignment zone isn't applicable. The failed
condition is gxhintn.c (in rev.1.44) ln 1571.

IMO the font is buggy. We could work around with increasing the threshold, but
not sure that we should.

With GS_7_0X same problem happens at different resolutions.
Comment 3 Igor Melichev 2004-03-24 05:54:54 UTC
Oops, in the comment #2 I've meant 75 dpi. 
Comment 4 Igor Melichev 2004-03-25 06:49:54 UTC
Fixed with gxhintn.c 1.45.