Bug 687376

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.