Bugzilla – Bug 691494
Clipped glyphs on display when TextAlphaBits = 2 or 4
Last modified: 2010-07-31 15:46:44 PDT
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]
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]
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
> 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.