/* gvcbugs.doc */
Known problems with GSview  1995-05-23

ALL
===

Zoom doesn't work in anything but Portrait orientation with
Ghostscript 3.12.  Works correctly with Ghostscript 2.6.1.
This is a problem with Ghostscript 3.12, not GSview.
Works correctly with Ghostscript 3.33


MS-WINDOWS
==========


MS-WINDOWS Win32s
=================
For a display size of 1024x768x64k, the image window will appear blank
if it is taller than 576 pixels.  This is a bug in Windows/Win32s 1.2,
and is not a bug in GSview or Ghostscript.

MS-WINDOWS NT
=============

Occasionally gives "pipe handle is zero" errors.
This will be fixed when I rewrite the GSview/Ghostscript interface.


MS-WINDOWS 95
=============

If you grab the new resize square at the bottom right of the 
window and you are using an unpatched version of Ghostscript 3.33,
GSview will lock up.  The patched version of Ghostscript
(gs333w32.exe dated after 23 May 1995) ignores the resize square.

Orientation for Windows 95 produced postscript won't change.

Ghostscript 3.33 under Windows 95 will not print to a printer port 
except with the device mswinpr2.
You may need to use the GSview "Print to File" and then "Print File".
A patched version (gs333w32.exe dated after 23 May 1995) will print
direct to print ports.


OS/2
====


List of known or suspected display driver bugs for PM.
Russell Lang  1994-05-19

Drawing from a BMP to an internal bitmap or the display appears to
be the responsibility of the display driver.  It has been extremely
frustrating trying to write code that will work on all displays.

Known display driver bugs are:

- GpiDrawBits won't draw to a standard VGA display (OS/2 2.1 and 2.11)

- WinDrawBitmap won't draw to an ATI GUP with 8514 drivers (OS/2 2.1).
  Consequently GSview uses a different method for writing to a 4 bit/pixel 
  display than for an 8 bit/pixel color display.  The 4bit/pixel method
  involves double handling (use GpiDrawBits to draw into a memory bitmap
  then WinDrawBitmap to copy it to the display).  This is very slow.

- On the STB X24, 1 bit/pixel displays incorrectly if the bitmap 
  is > 64kbytes.  Looks like buggy 16 bit code. (rjl)
  This card is an absolute dog.  The display drivers wouldn't install
  on anything but a newly installed OS/2.  The MS-Windows drivers
  for this card had files in different directories to those listed 
  in the setup.inf file, and even if the correct paths were used, 
  the drivers wouldn't install at all.

- On ATI GU in 8514, OS/2 2.11, GpiDrawBits stretches bitmaps vertically
  when drawing from a 1bit/pixel bitmap to the 8bit/pixel display.
  This occurrs when painting into a presentation space obtained using
  WinGetPS immediately after WinScrollWindow.  Also incorrect when
  region invalidated by WinScrollWindow and redrawn with later WM_PAINT.
  8bit/pixel bitmap works fine.
  Same occurred on Diamond Stealth Pro VESA with 2Mbytes.
  Works correctly on standard VGA.  (Rommel).
  Same occurred on Diamond Stealth VL24.  (rjl)
  This is due to an OS/2 (or driver) bug since the correct arguments
  *are* being passed to the GpiDrawBits() function.
  The workaround is to double buffer the bitmap as for 4bit/pixel displays.
  Double buffering doesn't work for 8bit/pixel bitmaps so GSview code
  only double buffers when OS/2 2.11, 8bit/pixel display with 1bit/pixel
  bitmap,  or any version of OS/2 and 4bit/pixel display.