Bug 691494 - Clipped glyphs on display when TextAlphaBits = 2 or 4
Clipped glyphs on display when TextAlphaBits = 2 or 4
Status: RESOLVED FIXED
Product: Ghostscript
Classification: Unclassified
Component: Color
master
PC Windows XP
: P4 normal
Assigned To: Chris Liddell (chrisl)
Bug traffic
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2010-07-24 12:52 UTC by SaGS
Modified: 2010-07-31 15:46 UTC (History)
2 users (show)

See Also:
Customer:
Word Size: ---


Attachments
Simple sample file. (71.75 KB, application/postscript)
2010-07-24 12:55 UTC, SaGS
Details
Screenshots. (28.76 KB, image/png)
2010-07-24 12:56 UTC, SaGS
Details
Suggested patch. (467 bytes, patch)
2010-07-24 12:57 UTC, SaGS
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description SaGS 2010-07-24 12:52:52 UTC
When running GS to display a PostScript file on screen with antialiased 
text (-dTextAlphaBits=2 or 4), glyphs are clipped so that only their 
leftmost part is shown. The resolution used makes a difference. I used a 
debug build of the current HEAD (rev 11540); COMPILE_INITS=0, FT_BRIDGE=0 
or 1; physical display set to 32bpp.

when using Ghostscript via GSView things are even worse, in that glyph 
fragments are show with some reddish/ yellowish pixels at their right.

I’ll attach a sample file, screenshots, commandline, and a suggested patch.

I found the first revision to exhibit this bug to be 11362 
<http://svn.ghostscript.com/viewvc?view=rev&revision=11362>. While I do 
consider that patch to be wrong (bug #691328 comment #2), it does not seem 
to be the root cause of the problem, it merely uncovered a very old bug.

As I see it, the root cause is in gdevdbit.c::gx_default_copy_alpha(). The 
depth of the source bitmap does not necessarily equal the one of the target 
device. The function handles this case, but when outputting a scanline it 
passes ‘raster’ as the scanline width in bytes. This value is correct for 
the source colour depth, but not for the same number of pixels at the 
device’s/ scanline’s colour depth.
Comment 1 SaGS 2010-07-24 12:55:23 UTC
Created attachment 6537 [details]
Simple sample file.
Comment 2 SaGS 2010-07-24 12:56:29 UTC
Created attachment 6538 [details]
Screenshots.

Command line used:

    gswin32c -r96 -dTextAlphaBits=n "Bug999088-[clipalpha]-sample.ps"

with ‘n’ = 1, 2, 4. ‘n’ = 1 is OK, the other two are KO.
Comment 3 SaGS 2010-07-24 12:57:56 UTC
Created attachment 6539 [details]
Suggested patch.

Fix: When outputting a scanline, the default copy_alpha() was passing the 
byte width as appropriate for the source bitmap, not for the modified 
scanline. While they have the same width in pixels, their width in bytes 
may differ because of different colour depths. Bug 691494.

Note: My tests were not extensive.
Comment 4 SaGS 2010-07-24 12:59:59 UTC
In comment #2 substitute ‘Bug691494’ for ‘Bug999088’, sorry.
Comment 5 Chris Liddell (chrisl) 2010-07-30 14:09:26 UTC
I concur with SaGS analysis, patch committed in r11570.

Thanks for the effort!
Comment 6 SaGS 2010-07-30 19:02:07 UTC
Note: revision 11572 reinstated (by mistake, I guess) the incorrect code <http://svn.ghostscript.com/viewvc/trunk/gs/base/gdevdbit.c?r1=11572&r2=11571&pathrev=11572>; the fix needs to be committed again.
Comment 7 henrystiles 2010-07-30 19:18:07 UTC
(In reply to comment #6)
> Note: revision 11572 reinstated (by mistake, I guess) the incorrect code
> <http://svn.ghostscript.com/viewvc/trunk/gs/base/gdevdbit.c?r1=11572&r2=11571&pathrev=11572>;
> the fix needs to be committed again.

Right in our regression testing system once a build breaks we revert back to the breaking revision - 1 and all later commits have to be resubmitted.  Chris will recommit when he returns.  Sorry for the inconvenience.
Comment 8 Henry Stiles 2010-07-30 19:23:14 UTC
Reopen until the fix can be resubmitted.
Comment 9 Chris Liddell (chrisl) 2010-07-31 15:46:44 UTC
Patch reapplied as r11581.