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.
Created attachment 6537 [details] Simple sample file.
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.
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.
In comment #2 substitute ‘Bug691494’ for ‘Bug999088’, sorry.
I concur with SaGS analysis, patch committed in r11570. Thanks for the effort!
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.
(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.
Reopen until the fix can be resubmitted.
Patch reapplied as r11581.