Bug 691494

Summary:	Clipped glyphs on display when TextAlphaBits = 2 or 4
Product:	Ghostscript	Reporter:	SaGS <sags5495>
Component:	Color	Assignee:	Chris Liddell (chrisl) <chris.liddell>
Status:	RESOLVED FIXED
Severity:	normal	CC:	henry.stiles, henrystiles
Priority:	P4
Version:	master
Hardware:	PC
OS:	Windows XP
Customer:		Word Size:	---
Attachments:	Simple sample file. Screenshots. Suggested patch.

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.