Crash in gs. The actual command is e.g. 

/usr/bin/gs -q -dSAFER -dPARANOIDSAFER -dNOPAUSE -dBATCH -sDEVICE=pdfwrite -sOutputFile=/home/llunak/print.pdf -sPAPERSIZE=a4 -c .setpdfwrite -f /tmp/kde-llunakKWY1w8/kdeprint_TTkva9pf

I'll also attach /tmp/kde-llunakKWY1w8/kdeprint_TTkva9pf .

Created attachment 63162 [details]
/tmp/kde-llunakKWY1w8/kdeprint_TTkva9pf

Explain why this bug is critical?  I can reproduce this even
for SuSE Linux 9.3.

I think is critical, because printing is really elementary feature and it is very visible feature.

Even ghostscript 8.50 shows this bug. IMHO this looks
like a application producing HUGE dict in postscript.
The crahs happens within comparision of two dicts on
the stack.

OK, I've a patch for this, build checks are running.
The fix is for the next release SL10.1 and SLES10

It is work now. But little bit strange. Preview is stretch, when printed page is normal. See attached picture.

Created attachment 72798 [details]
Print preview and same document printed to pdf

This has nothing todo with ghostscript and the bug within
this bugzilla but with Konqueror.  I've run the line

gs -q -dSAFER -dPARANOIDSAFER -dNOPAUSE -dBATCH -sDEVICE=pdfwrite -sOutputFile=print.pdf -sPAPERSIZE=a4 -c .setpdfwrite -f kdeprint_TTkva9pf

with the attachment and done a comparision with gs and xpdf and found that
the graphic results are identical.

Created attachment 72803 [details]
Coparision  between resulting print.pdf and kdeprint_TTkva9pf

Here you can see.

I am not sure, you have right. 
I did some tests.
I get postscript picture from print preview. Ghostview open it right, but kghostview (which is only parser for gv?) and evince failed and stretch picture. I tested in on Mac OS X and i was able to converted correctly to pdf. I will attach this file.

I get printed pdf file. Ghostview, AdobeReader!!, KghostView stretch page. And evince kpdf, open it correctly. I can`t open this pdf file on Mac OS X at all!! GhostView have strange behavior with zooming (see attached snapshot)

I am not sure if this have something to do with gs :( but it is terrible behavior.

Created attachment 73356 [details]
Printed page to pdf

Created attachment 73357 [details]
Printed preview, postscript

Created attachment 73358 [details]
Snapshot of various program trying to open pdf

I've just open the pdf in comment #7 with acroread and it
looke absolut normal.  Could it be that your monitor
resolution is broken?  I'm using

  /suse/werner> xdpyinfo | grep -i resolution:
    resolution:    98x98 dots per inch

which is dpi in x and y direction are the same.     

Created attachment 73361 [details]
screen shot of the acroread window.

Hmmm i use dual head (LCD+CRT)
resolution:    180x96 dots per inch

This is a aspect ratio of aproximatly 2:1 ... please try out
what happens single head (LCD or CRT).  The resultion pdf
file seems to be device dependend (binary image, no other way).
In other words if you're not printing and if the viewer is not
able to correct the resolution to fit the resolution of the
xinerama screen, the pdf file must be streched into the other
direction ... e.g. with the option -r of gs. But you can not
print this file on an printer with a normal resolution.

On single monitor all work perfectly :(

Hmmm ... do you have set the dpi values on the command line
of the Xserver(s) and what are you using for the dimension
of the two monitors in the /etc/X11/xorg.conf?  Search for
the valies of DisplaySize in the sections "Monitor".

IMHO the x and y dpi values should be the same ±2

You pointed me to right direction.
If i add 
Option        "MergedDPI" "95 96"
to xorg.conf all problems vanish.
I am not sure if i should report it as sax bug? (xorg.conf was generated using sax without any modification)

Marcus? Just read comment #21. would it make sence to use this Option
in xorg.conf for dual head configurations?

MergedDPI *hui* never heard of that and it's not documented
I think this entry will overwrite the X-Server calculated DPI
values referring to the mm values of the DisplaySize setup in
xorg.conf.

- First and foremost the question here is what are
  the DisplaySize value of your current /etc/X11/xorg.conf ?
  I still assume the error to be there

I'm using DualHead as well and my DPI values has been calculated
correctly by the server 

Section "Monitor"
DisplaySize  360 270
...
EndSection

I have ATI card, i will attach xorg.conf

I tried switch on/of IgnoreEDID option, because this helped me once with wrong monitor on nvidia card. 

Created attachment 73943 [details]
xorg conf

Created attachment 73945 [details]
Xorg log file

i find interesting this:
(II) Module theatre_detect: vendor="X.Org Foundation"
        compiled for 4.3.99.902, module version = 1.0.0
        ABI class: X.Org Video Driver, version 0.8
(II) RADEON(0): no multimedia table present, disabling Rage Theatre.
(WW) RADEON(0): Option "SaXDualHead" is not used
(WW) RADEON(0): Option "SaXDualMonitorVendor" is not used
(WW) RADEON(0): Option "SaXDualOrientation" is not used
(WW) RADEON(0): Option "SaXDualResolution" is not used
(WW) RADEON(0): Option "SaXDualMode" is not used
(WW) RADEON(0): Option "SaXDualHSync" is not used
(WW) RADEON(0): Option "SaXDualMonitorModel" is not used
(WW) RADEON(0): Option "SaXDualVSync" is not used
(==) RandR enabled

Thanks for the information, well the DisplaySize is correct for
the monitor and I see no reason why the DPI calculation gets so wrong.
I assume this is another radeon driver problem. By the way if you
set

   DisplaySize 720 270

does it fix your problem without using MergedDPI ?

Yes. DPI is 90 x 96. Pdf files are displayed correctly. 
I am using native radeon driver, not proprietal one.

ok, I added a fix to adapt the DisplaySize correctly if the secondary
monitor size could be detected. The code will be in the DualHead
profile

  /usr/share/sax/profile/Radeon_DualHead_DriverOptions.pl