I upgraded from Ghostscript 7.07 to GS 8.14 a couple of days ago and noticed strange degradation of rendering quality when using the "x11" driver with antialiasing turned on and when the font is relatively small (I use kghostview for viewing PDFs, but I verified that the problem persists when using Ghostview, gsx or gs with -sDEVICE=x11). The glyphs are now somewhat thicker than in 7.07.1 and look as if the thickness changes a little on the glyph. Interestingly enough, 8.14's output looks very similar to 7.07's with -dNOCACHE or -dMaxBitmapSize=0 (or small value; either of these settings turns off 7.07's beatiful antialiasing for some reason). -dAlignToPixels=0 improves 8.14's output a bit (although the fonts should be hinted correctly, the document uses Times-Roman font), but it is still not as nice as 7.07's output. The fonts are same in both cases (ghostscript-fonts-std-8.11.tar.gz) and as far as I can tell, platform fonts aren't used. The settings I use are -sDEVICE=x11 -dTextAlphaBits=4 -dGraphicsAlphaBits=4 -dMaxBitmap=50000000 To be more specific about the degradation even when -dAlignToPixels=0 is used, I attached two screenshots and a sample PDF file that demonstrate it. Pay attention to three things in gs8_small screenshot (compared to gs7_small): * The title doesn't have straight baseline, t,a and c characters are little lower than the rest. * The characters have slightly smaller height in gs8 output, while the width of characters is same, so the proportions are a little bad. Interestingly, it happens only on the first two lines of the paragraph under the title, the rest of lines is same in both screenshots. * Compare "ve" substring on second line in "mluvene" with "ve" in "preveden" on 3rd line or "vektoru" on 5th. It's different: the one on 2nd line has "v" that extends under the baseline, the rest doesn't (and looks like gs7 output). Same thing in higher resolution (it's a little less visible, but same artefacts are present) attached as gs{7,8}_large. X server's DPI setting is 80x80, if that can make any difference.
Created attachment 566 [details] test file
Created attachment 567 [details] gs7_small.png
Created attachment 568 [details] gs8_small.png
Created attachment 569 [details] gs7_large.png
Created attachment 570 [details] gs8_large.png
The attached "test file" is not same as one displayed in other attachments. Please provide a consistent information to allow us to reproduce the problem, including the output resolution.
Created attachment 601 [details] gs7_small.png Recreated screenshots to match testfile
Created attachment 602 [details] gs7_large.png
Created attachment 603 [details] gs8_small.png
Created attachment 604 [details] gs8_large.png
DPI is already specificied in the original report: X11 uses 80x80dpi, the resolution used for rendering is whatever x11 driver picks. I tried the fix for bug #687385, but it makes no difference. I tried to reproduce it with PNG output with the following command (DPI is 81 instead of 80 because it makes some artefacts better visible): gs -r81x81 -sDEVICE=png256 -sPAPERSIZE=a4 -dAlignToPixels=0 -dTextAlphaBits=4 -dGraphicsAlphaBits=4 -dMaxBitmap=50000000 -sOutputFile=test.png test.pdf gs8's PNG output is much better than gs7's PNG output, but not as good as gs7's x11. The first artefact (title baseline) is not visible in gs8_png.png on the biggest lines, but you can see it on lines beginning with "1.1" and "1.1.1". Characters are rendered differently on first and third line of text body in PNG output as well -- compare the look of "e" on them.
Created attachment 605 [details] gs7_png.png
Created attachment 606 [details] gs8_png.png
Vaclav, First of all please note that with textAlphaBits=2 AlignToPixel=0 each glyph may have up to 16 different positions relatively the raster grid, so you must not expect same raster for each occurance. Second, please use an explicit specification of the page size and resolution, and a device which writes the raster to a file. Othervize I can't reproduce your results. Your command line with png256 is fine for that, but X11 device is not, because the parameters depend on your display hardware. I cannot reproduce your attechments with your command line : gs -r81x81 -sDEVICE=png256 -sPAPERSIZE=a4 -dAlignToPixels=0 -dTextAlphaBits=4 -dGraphicsAlphaBits=4 -dMaxBitmap=50000000 -sOutputFile=test.png test.pdf The latter gives a different size of the image than gs8_small.png, gs8_large.png you've attached. Please provide a consistent information. Third, please download GS_8_1X from cvs.hgostscript.com and try it. Multiple patches were recently applied to this branch, which fix many of related problems. This branch will soon be released as gs8.15, and we are interesing in testing it. We're not interesting in testing older revisions because now they become obsolete. Now back to your PNGs. Comparing gs7_png.png with gs8_png.png, I do see some overshoots near the baseline, but I do see them in both gs7_png.png and gs8_png.png . In gs7_png.png the character 'u' is overshooted down in the 2nd line, and in gs8_png.png the characters 's' and 'b' overshooted down in the 3d line. Similar overshoots can be observed with the upper alignment zone of lowercases. Thus what we observe is neither a regression nor a progression. I do see a problem with the lower alignment zone in the line 2 of your gs8_small.png, but I can't reprodiuce this result neither by the image size nor by the raster. I guess this problem was fixed within the bug #687385. Please reproduce with current GX_8_1X or with the current HEAD. After we resolve your problems with png256, we can go back to your X11 probllems. I need to know the page size and resolution, which GS uses when renders to your display. Please note that we don't maintain GSview, and this bug tracker isn't a right place for its bug reports. Therefore I'd appreciate if you reproduce your display problem with png256, maybe using a fractional value for the resolution, or with an additional shift applying command line options like this : -c "<< /Install { -100 -600 translate } bind >> setpagedevice " -f test.pdf
See also http://www.ghostscript.com/pipermail/gs-devel/2004-April/003012.html
> First of all please note that with textAlphaBits=2 AlignToPixel=0 each glyph > may have up to 16 different positions relatively the raster grid, so you must > not expect same raster for each occurance. That doesn't explain why all all occurences except the ones on first lines look same. > but X11 device is > not, because the parameters depend on your display hardware. I cannot reproduce it on other device, and I already said so. > The latter gives a different size of the image than gs8_small.png, > gs8_large.png you've attached. Please provide a consistent information. It *is* the command I used. > Please note that we don't maintain GSview, and this > bug tracker isn't a right place for its bug reports. Please carefully read the report once again -- I said very clearly that this is **NOT** GSview bug, then it happens with **ALL** ways of outputting x11, *regardless* of whether it is gsx, gsview or -sDEVICE=x11. I'm going to test CVS HEAD now.
> I'm going to test CVS HEAD now. Same regression.
> I cannot reproduce it on other device, and I already said so. At first time I assumed a bug in the character renderer, but now I guess this bug is specific to the X11 device implementation. I'll pass it to someone who can debug X11.
I took over this report since I have X11. I ran the test file with the listed resolutions, -r80, -r81 and the resolution implied by the 'matix currentmatrix ==' sequence which is -r74.9498 While 8.14, 8.1x (pre 8.15) and HEAD as of this date all are less bold than 7.0x, I don't see any instances of the bad baseline or other effects submitted by the user. Note that the HEAD version does have a slightly better (IMHO) kerning in the word "mluvene" between the m, the l and the u. The less bold characters of 8.11 and later are considered to be an improvement since the output is closer to Adobe font rendering. The 7.0x versions had an artificial boldness to prevent dropout of narrow stems (that usually worked). With 8.1x and later, that is not needed, nor desired. Prior to the recent HEAD revision, it is important to use the -dNOPLATFONTS switch with -dTextAlphaBits > 1 since the x11 rendering of fonts was not properly tuned. I suggest that the submitter retest with -dNOPLATFONTS. Since this works for me after extensive testing, and examination under xmag, this bug will be closed.
> The less bold characters of 8.11 and later are considered to > be an improvement Making it less readable in X11 output is considered an improvement? Screen output has different requirements than printing w.r.t. readibility and Acrobat Reader (especially with CoolType enabled) or freetype does much better job in it than gs8, sadly. > I suggest that the submitter retest with -dNOPLATFONTS. Makes no difference.