Very Computer

I can control some widgets like the scrollbars:
    Ghostview.form.pageview.horizontal.background: red1
works, but
    Ghostview.form.pageview.page.background: red1
does not. Instead, I get the color defined by the general
    *background
resource, which is the default terminal window color, as set by
VUE. I can change this color in my resource property, and
ghostview does get the new color; but I cannot analogously set the
foreground color via "*foreground".

(I have xterms with white characters on dark background. I
would like to have light grey ghostview background with black letters.)

I can control all ghostview colors easily in fvwm/linux on my PC.
The widget hierarchy looks the same to me.

Is this therefore a VUE problem? If this is a basic exercise
please just point me to where to look.

Rajmund Krivec

|Is this therefore a VUE problem? If this is a basic exercise
|please just point me to where to look.

From the comp.sys.hp.hpux FAQ-

6.16 How can I get HP-VUE to not override colors?

The Motif library on HP-UX has extra code added to make the default
colors follow the color schemes that the user selects with the vuestyle
controls.  This extra code makes trouble for some applications which
don't want this unique and unexpected behavior.

You can prevent the entire color scheme mechanism from being used in an
application by setting "*useColorObj:  False" for the application before
creating the first widget.  This can be done by adding the resource to
the application defaults, the fallback resources, or as an extra "-xrm"
"*useColorObj:  False" args pair in the argv and argc parameters passed
to XtAppInitialize.  If you set the resource in xrdb it would be best to
set it for only specific applications like "MyApp*useColorObj:  False".

Setting the useColorObj resource could make programs core dump on some
8.0* systems.  There is a patch that corrects the core dump.

You can use the vue colors and prevent the specific difference between
dialog colors vs.  non-dialog colors by setting a resource that
specifies the behavoir of the color scheme mechanism.  To force the
dialogs to use the same colors as the other windows set the following
resources in your app_defaults file or fallback settings-

*primaryColorSetId: 3
*secondaryColorSetId: 3

This sets the dialog or "secondary" colors to the same set as the primary
colors.  This is discussed in the "HP VUE 3.0 User's Guide" in chapter 26.

--

I also tried to do the coloring in fvwm on my HP station, and I
couldn't do it. Since I could do it in fvwm at home, I guess the
problem may be in ghostview after all.

Rajmund Krivec

i added the following entries to the /usr/lib/X11/app-defaults/Ghostview file:
*page*foreground: black
*page*background: white

not an official statement of hp.
--

                          San Diego Division      
                          Hewlett-Packard Company  
                          http://www.webcom.com/fratkin/allyn/

: > |I would like to know how to set the colors of the display
: > |page in ghostview (HP-UX 9.05, VUE 3.0).
: >
: > |Is this therefore a VUE problem? If this is a basic exercise
: > |please just point me to where to look.
: >
: > From the comp.sys.hp.hpux FAQ-
: >
: >
: > 6.16 How can I get HP-VUE to not override colors?
: >
: > The Motif library on HP-UX has extra code added to make the default
: > colors follow the color schemes that the user selects with the vuestyle
: > controls.  This extra code makes trouble for some applications which
: > don't want this unique and unexpected behavior.
: >
<snip>
: I tried all of the above and ghostview didn't budge. I could
: still color the scrollbars which are on the same widget tree,
: but not the background. All behavior was indpendent of the above
: resource settings.

: I also tried to do the coloring in fvwm on my HP station, and I
: couldn't do it. Since I could do it in fvwm at home, I guess the
: problem may be in ghostview after all.

Ghostview does not use the Motif widgets (they look like the Athena ones
to me) so I would doubt if HPs Motif hacks would affect it (unless the
hacks have been done in the X toolkit rather than Motif?).

--

Philips Semiconductors Ltd
Southampton                                 My views are my own.
United Kingdom
 Are you using ISO8859-1? Do you see ? as copyright, as division and ? as 1/2?

Whichever version of ghostview I try (recently: 3.50 and 3.51)
it does not show any graphics but displays an error:

X Error of failed request:  BadValue (integer parameter out of range for operation)
  Major opcode of failed request:  91 (X_QueryColors)
  Value in failed request:  0xff
  Serial number of failed request:  403
  Current serial number in output stream:  403

or
  ...
  Serial number of failed request:  401
  Current serial number in output stream:  401

Any remedies ?

TIA,

        Zenon

Quote:> Whichever version of ghostview I try (recently: 3.50 and 3.51)
> it does not show any graphics but displays an error:

> X Error of failed request:  BadValue (integer parameter out of range for operation)
>   Major opcode of failed request:  91 (X_QueryColors)
>   Value in failed request:  0xff
>   Serial number of failed request:  403
>   Current serial number in output stream:  403

> or
>   ...
>   Serial number of failed request:  401
>   Current serial number in output stream:  401

> Any remedies ?

> TIA,

>    Zenon

KK

|Whichever version of ghostview I try (recently: 3.50 and 3.51)
|it does not show any graphics but displays an error:

|X Error of failed request:  BadValue (integer parameter out of range for operation)
|  Major opcode of failed request:  91 (X_QueryColors)
|  Value in failed request:  0xff
|  Serial number of failed request:  403
|  Current serial number in output stream:  403

  The trouble is coming from the overlay vs. image visuals of the
CRX48.  The default visual is in overlay planes.  Color 255 of the
default visual is transparent to the image planes.  Ghostscript is
trying to read the color of index 255 and getting in error because the
color of that index can't be read or set.  You can work around the
problem by setting an option in /usr/lib/X11/X0screens.  If you look in
that file you will find a description of how to set the
CountTransparentInOverlayVisual screen option which make the X server
pretend that index 255 of the default visual can be read and set.
(The index will still be transparent, but the X_QueryColors request will
succeed.

--