Bug 88691 - Cannot open postscript documents - backing pixmap problem
Summary: Cannot open postscript documents - backing pixmap problem
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: gv   
(Show other bugs)
Version: 9
Hardware: i686 Linux
high
high
Target Milestone: ---
Assignee: Bill Nottingham
QA Contact: David Lawrence
URL: http://groups.google.com/groups?q=gro...
Whiteboard:
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2003-04-11 22:13 UTC by Need Real Name
Modified: 2014-03-17 02:35 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2003-04-13 17:48:56 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

Description Need Real Name 2003-04-11 22:13:17 UTC
Description of problem:

Whenever I try to open a postscript document gv, I get the following error :

Warning: Could not allocate backing pixmap in main window.

X Error of failed request:  BadMatch (invalid parameter attributes)
  Major opcode of failed request:  73 (X_GetImage)
  Serial number of failed request:  29
  Current serial number in output stream:  29

Error: PostScript interpreter failed in main window.

I am using Gnome.

When I use ggv, it returns with another error message indicating that the
document cannot be opened.

Version-Release number of selected component (if applicable):

gv-3.5.8-22
ggv-1.99.97-2

How reproducible:

Every time the above action is attempted

Steps to Reproduce:
1. gv filename.ps
2. ggv > Open > filename.ps
3.
    
Actual results:

An infoPopup window opens up with the error text, while gv shows a blank page.

Expected results:

gv ought to show the document properly.

Additional info:

None that I can think of.

Comment 1 Need Real Name 2003-04-13 17:48:56 UTC
The problem lay with misconfiguration of the X server which assumed an extremely
high value of resolution (xdpyinfo | grep "resolution"). Fixed it in
/etc/X11/XF86Config.



Note You need to log in before you can comment on or make changes to this bug.