X(1)							     X(1)


NNAAMMEE
       X - a portable, network-transparent window system

SSYYNNOOPPSSIISS
       The X Window System is a network transparent window system
       which runs on a	wide  range  of	 computing  and	 graphics
       machines.   It  should  be  relatively  straightforward to
       build the X Consortium software distribution on most  ANSI
       C and POSIX compliant systems.  Commercial implementations
       are also available for a wide range of platforms.

       The X Consortium requests that the following names be used
       when referring to this software:

				   X
			    X Window System
			      X Version 11
		      X Window System, Version 11
				  X11

       _X _W_i_n_d_o_w _S_y_s_t_e_m is a trademark of X Consortium, Inc.

DDEESSCCRRIIPPTTIIOONN
       X  Window System servers run on computers with bitmap dis-
       plays.  The server distributes user input to  and  accepts
       output  requests	 from  various	client programs through a
       variety of different interprocess communication	channels.
       Although	 the  most common case is for the client programs
       to be running on the same machine as the	 server,  clients
       can  be	run  transparently from other machines (including
       machines with different architectures and  operating  sys-
       tems) as well.

       X  supports  overlapping	 hierarchical subwindows and text
       and graphics operations, on both monochrome and color dis-
       plays.	For  a full explanation of the functions that are
       available, see the _X_l_i_b _- _C _L_a_n_g_u_a_g_e _X  _I_n_t_e_r_f_a_c_e  manual,
       the  _X _W_i_n_d_o_w _S_y_s_t_e_m _P_r_o_t_o_c_o_l specification, the _X _T_o_o_l_k_i_t
       _I_n_t_r_i_n_s_i_c_s _- _C  _L_a_n_g_u_a_g_e	 _I_n_t_e_r_f_a_c_e  manual,  and  various
       toolkit documents.

       The  number  of	programs that use _X is quite large.  Pro-
       grams provided  in  the	core  X	 Consortium  distribution
       include:	 a  terminal  emulator	(_x_t_e_r_m), a window manager
       (_t_w_m), a display manager (_x_d_m), a console redirect program
       (_x_c_o_n_s_o_l_e),  a  mail  interface	(_x_m_h),	a  bitmap  editor
       (_b_i_t_m_a_p),  resource  listing/manipulation  tools	 (_a_p_p_r_e_s,
       _e_d_i_t_r_e_s),  access  control  programs  (_x_a_u_t_h,  _x_h_o_s_t,  and
       _i_c_e_a_u_t_h), user preference setting programs (_x_r_d_b,  _x_c_m_s_d_b,
       _x_s_e_t, _x_s_e_t_r_o_o_t, _x_s_t_d_c_m_a_p, and _x_m_o_d_m_a_p), clocks (_x_c_l_o_c_k and
       _o_c_l_o_c_k), a font displayer  (_x_f_d),  utilities  for  listing
       information  about fonts, windows, and displays (_x_l_s_f_o_n_t_s,
       _x_w_i_n_i_n_f_o,  _x_l_s_c_l_i_e_n_t_s,  _x_d_p_y_i_n_f_o,  _x_l_s_a_t_o_m_s,  and  _x_p_r_o_p),
       screen image manipulation utilities (_x_w_d, _x_w_u_d, and _x_m_a_g),



X Version 11		    Release 6				1





X(1)							     X(1)


       a performance measurement utility (_x_1_1_p_e_r_f), a  font  com-
       piler  (_b_d_f_t_o_p_c_f),  a  font  server  and related utilities
       (_x_f_s, _f_s_i_n_f_o, _f_s_l_s_f_o_n_t_s, _f_s_t_o_b_d_f), an  X	 Image	Extension
       exerciser  (_x_i_e_p_e_r_f),  a display server and related utili-
       ties (_X_s_e_r_v_e_r, _r_g_b, _m_k_f_o_n_t_d_i_r), remote execution utilities
       (_r_s_t_a_r_t and _x_o_n), a clipboard manager (_x_c_l_i_p_b_o_a_r_d), a key-
       board description compiler (_x_k_b_c_o_m_p), a utility to  termi-
       nate  clients  (_x_k_i_l_l), and a utility to cause part or all
       of the screen to be redrawn (_x_r_e_f_r_e_s_h).

       Many other utilities, window  managers,	games,	toolkits,
       etc.  are  included  as user-contributed software in the X
       Consortium distribution, or are available using	anonymous
       ftp  on	the  Internet.	 See  your site administrator for
       details.

SSTTAARRTTIINNGG UUPP
       There are two main ways of getting the  X  server  and  an
       initial	set of client applications started.  The particu-
       lar method used depends on what operating system	 you  are
       running and whether or not you use other window systems in
       addition to X.

       _x_d_m ((tthhee XX DDiissppllaayy MMaannaaggeerr))
	       If you want to always have X running on your  dis-
	       play, your site administrator can set your machine
	       up to use the X Display Manager _x_d_m.  This program
	       is  typically  started  by the system at boot time
	       and takes care of keeping the server  running  and
	       getting	users logged in.  If you are running _x_d_m,
	       you will see a window on the screen welcoming  you
	       to  the	system	and  asking for your username and
	       password.  Simply type them in as you would  at	a
	       normal  terminal,  pressing  the	 Return key after
	       each.  If you make a mistake, _x_d_m will display  an
	       error message and ask you to try again.	After you
	       have successfully logged in,  _x_d_m  will	start  up
	       your  X	environment.   By default, if you have an
	       executable  file	 named	_._x_s_e_s_s_i_o_n  in  your  home
	       directory,  _x_d_m	will  treat  it	 as a program (or
	       shell script) to run  to	 start	up  your  initial
	       clients	(such  as  terminal  emulators, clocks, a
	       window manager, user settings for things like  the
	       background, the speed of the pointer, etc.).  Your
	       site administrator can provide details.

       _x_i_n_i_t ((rruunn mmaannuuaallllyy ffrroomm tthhee sshheellll))
	       Sites that support more	than  one  window  system
	       might choose to use the _x_i_n_i_t program for starting
	       X manually.  If this is	true  for  your	 machine,
	       your  site  administrator  will probably have pro-
	       vided a program named "x11", "startx", or "xstart"
	       that will do site-specific initialization (such as
	       loading convenient default  resources,  running	a



X Version 11		    Release 6				2





X(1)							     X(1)


	       window  manager,	 displaying a clock, and starting
	       several terminal emulators) in  a  nice	way.   If
	       not,  you  can build such a script using the _x_i_n_i_t
	       program.	  This	utility	 simply	 runs  one  user-
	       specified   program  to	start  the  server,  runs
	       another to start up any desired clients, and  then
	       waits  for either to finish.  Since either or both
	       of the user-specified  programs	may  be	 a  shell
	       script,	this gives substantial flexibility at the
	       expense of a nice  interface.   For  this  reason,
	       _x_i_n_i_t is not intended for end users.

DDIISSPPLLAAYY NNAAMMEESS
       From  the user's prospective, every X server has a _d_i_s_p_l_a_y
       _n_a_m_e of the form:

		  _h_o_s_t_n_a_m_e_:_d_i_s_p_l_a_y_n_u_m_b_e_r_._s_c_r_e_e_n_n_u_m_b_e_r

       This information is used by the application  to	determine
       how  it	should	connect to the server and which screen it
       should use by default (on  displays  with  multiple  moni-
       tors):

       _h_o_s_t_n_a_m_e
	       The  _h_o_s_t_n_a_m_e specifies the name of the machine to
	       which the display is physically connected.  If the
	       hostname	 is  not given, the most efficient way of
	       communicating to a server on the same machine will
	       be used.

       _d_i_s_p_l_a_y_n_u_m_b_e_r
	       The  phrase  "display" is usually used to refer to
	       collection of monitors that share  a  common  key-
	       board  and  pointer  (mouse,  tablet, etc.).  Most
	       workstations tend to only have one  keyboard,  and
	       therefore,  only	 one display.  Larger, multi-user
	       systems, however, frequently have several displays
	       so that more than one person can be doing graphics
	       work at once.  To avoid confusion, each display on
	       a  machine is assigned a _d_i_s_p_l_a_y _n_u_m_b_e_r (beginning
	       at 0) when  the	X  server  for	that  display  is
	       started.	  The display number must always be given
	       in a display name.

       _s_c_r_e_e_n_n_u_m_b_e_r
	       Some displays share a single keyboard and  pointer
	       among  two  or  more monitors.  Since each monitor
	       has  its	 own  set  of  windows,	 each  screen  is
	       assigned a _s_c_r_e_e_n _n_u_m_b_e_r (beginning at 0) when the
	       X server for that  display  is  started.	  If  the
	       screen number is not given, screen 0 will be used.

       On POSIX systems, the default display name  is  stored  in
       your  DISPLAY  environment variable.  This variable is set



X Version 11		    Release 6				3





X(1)							     X(1)


       automatically by the _x_t_e_r_m  terminal  emulator.	 However,
       when  you  log into another machine on a network, you will
       need to set DISPLAY by hand to point to your display.  For
       example,

	   % setenv DISPLAY myws:0
	   $ DISPLAY=myws:0; export DISPLAY
       The  _x_o_n	 script	 can  be  used to start an X program on a
       remote machine; it automatically sets the DISPLAY variable
       correctly.

       Finally,	 most  X programs accept a command line option of
       --ddiissppllaayy _d_i_s_p_l_a_y_n_a_m_e to temporarily override the	 contents
       of  DISPLAY.  This is most commonly used to pop windows on
       another person's screen or as part  of  a  "remote  shell"
       command	to  start an xterm pointing back to your display.
       For example,

	   % xeyes -display joesws:0 -geometry 1000x1000+0+0
	   % rsh big xterm -display myws:0 -ls </dev/null &

       X servers listen for connections on a variety of different
       communications channels (network byte streams, shared mem-
       ory, etc.).  Since there can be more than one way of  con-
       tacting	a  given server, The _h_o_s_t_n_a_m_e part of the display
       name is used to determine the type of channel (also called
       a  transport  layer) to be used.	 X servers generally sup-
       port the following types of connections:

       _l_o_c_a_l
	       The hostname part of the display	 name  should  be
	       the empty string.  For example:	_:_0, _:_1, and _:_0_._1.
	       The most efficient local transport will be chosen.

       _T_C_P_I_P
	       The  hostname  part  of the display name should be
	       the server machine's IP address name.  Full Inter-
	       net names, abbreviated names, and IP addresses are
	       all  allowed.   For  example:   _x_._o_r_g_:_0,	  _e_x_p_o_:_0,
	       _1_9_8_._1_1_2_._4_5_._1_1_:_0, _b_i_g_m_a_c_h_i_n_e_:_1, and _h_y_d_r_a_:_0_._1.

       _D_E_C_n_e_t
	       The  hostname  part  of the display name should be
	       the server machine's  nodename,	followed  by  two
	       colons  instead	of  one.   For example:	 _m_y_w_s_:_:_0,
	       _b_i_g_:_:_1, and _h_y_d_r_a_:_:_0_._1.


AACCCCEESSSS CCOONNTTRROOLL
       An X server can	use  several  types  of	 access	 control.
       Mechanisms provided in Release 6 are:
	   Host Access			 Simple host-based access control.
	   MIT-MAGIC-COOKIE-1		 Shared plain-text "cookies".
	   XDM-AUTHORIZATION-1		 Secure DES based private-keys.



X Version 11		    Release 6				4





X(1)							     X(1)


	   SUN-DES-1			 Based on Sun's secure rpc system.
	   MIT-KERBEROS-5		 Kerberos Version 5 user-to-user.

       _X_d_m  initializes	 access	 control  for the server and also
       places authorization information in a file  accessible  to
       the  user.  Normally, the list of hosts from which connec-
       tions are always accepted should be empty,  so  that  only
       clients	with are explicitly authorized can connect to the
       display.	 When you add entries  to  the	host  list  (with
       _x_h_o_s_t), the server no longer performs any authorization on
       connections from those machines.	 Be careful with this.

       The file from which _X_l_i_b extracts authorization	data  can
       be specified with the environment variable XXAAUUTTHHOORRIITTYY, and
       defaults to the file ..XXaauutthhoorriittyy in  the	 home  directory.
       _X_d_m  uses $$HHOOMMEE//..XXaauutthhoorriittyy and will create it or merge in
       authorization records if it already  exists  when  a  user
       logs in.

       If you use several machines and share a common home direc-
       tory across all of the machines by means of a network file
       system, you never really have to worry about authorization
       files, the system should work correctly by default.   Oth-
       erwise,	 as   the   authorization   files   are	 machine-
       independent, you can simply copy the files to share  them.
       To  manage  authorization  files, use _x_a_u_t_h.  This program
       allows you to extract records and insert them  into  other
       files.	Using  this, you can send authorization to remote
       machines when you login, if the remote  machine	does  not
       share  a	 common	 home  directory with your local machine.
       Note that authorization information transmitted	``in  the
       clear''	through a network file system or using _f_t_p or _r_c_p
       can be ``stolen'' by a network eavesdropper, and	 as  such
       may  enable  unauthorized  access.   In many environments,
       this level of security is not a concern, but if it is, you
       need  to know the exact semantics of the particular autho-
       rization data to know if this is actually a problem.

       For more information on access control, see the	_X_s_e_c_u_r_i_t_y
       manual page.

GGEEOOMMEETTRRYY SSPPEECCIIFFIICCAATTIIOONNSS
       One  of	the advantages of using window systems instead of
       hardwired terminals is that applications don't have to  be
       restricted to a particular size or location on the screen.
       Although the layout of windows on a display is  controlled
       by  the window manager that the user is running (described
       below), most X programs accept a command line argument  of
       the  form  --ggeeoommeettrryy  _W_I_D_T_H_x_H_E_I_G_H_T_+_X_O_F_F_+_Y_O_F_F (where _W_I_D_T_H,
       _H_E_I_G_H_T, _X_O_F_F, and _Y_O_F_F are numbers) for specifying a  pre-
       ferred  size and location for this application's main win-
       dow.

       The _W_I_D_T_H and _H_E_I_G_H_T parts of the  geometry  specification



X Version 11		    Release 6				5





X(1)							     X(1)


       are  usually  measured  in  either  pixels  or characters,
       depending on the application.  The _X_O_F_F and _Y_O_F_F parts are
       measured in pixels and are used to specify the distance of
       the window from the left or right and top and bottom edges
       of  the	screen,	 respectively.	Both types of offsets are
       measured from the indicated edge of the screen to the cor-
       responding edge of the window.  The X offset may be speci-
       fied in the following ways:

       _+_X_O_F_F   The left edge of the window is to be  placed  _X_O_F_F
	       pixels  in from the left edge of the screen (i.e.,
	       the X coordinate of the window's	 origin	 will  be
	       _X_O_F_F).	_X_O_F_F  may  be negative, in which case the
	       window's left edge will be off the screen.

       _-_X_O_F_F   The right edge of the window is to be placed  _X_O_F_F
	       pixels in from the right edge of the screen.  _X_O_F_F
	       may be negative, in which case the window's  right
	       edge will be off the screen.

       The Y offset has similar meanings:

       _+_Y_O_F_F   The  top	 edge  of the window is to be _Y_O_F_F pixels
	       below the top edge of  the  screen  (i.e.,  the	Y
	       coordinate  of  the window's origin will be _Y_O_F_F).
	       _Y_O_F_F may be negative, in which case  the	 window's
	       top edge will be off the screen.

       _-_Y_O_F_F   The bottom edge of the window is to be _Y_O_F_F pixels
	       above the bottom edge of the screen.  _Y_O_F_F may  be
	       negative,  in  which case the window's bottom edge
	       will be off the screen.

       Offsets must be given as pairs; in other words,	in  order
       to specify either _X_O_F_F or _Y_O_F_F both must be present.  Win-
       dows can be placed in the four corners of the screen using
       the following specifications:

       _+_0_+_0    upper left hand corner.

       _-_0_+_0    upper right hand corner.

       _-_0_-_0    lower right hand corner.

       _+_0_-_0    lower left hand corner.

       In  the	following examples, a terminal emulator is placed
       in roughly the center of the screen  and	 a  load  average
       monitor,	 mailbox, and clock are placed in the upper right
       hand corner:

	   xterm -fn 6x10 -geometry 80x24+30+200 &
	   xclock -geometry 48x48-0+0 &
	   xload -geometry 48x48-96+0 &



X Version 11		    Release 6				6





X(1)							     X(1)


	   xbiff -geometry 48x48-48+0 &


WWIINNDDOOWW MMAANNAAGGEERRSS
       The layout of windows on the screen is controlled by  spe-
       cial  programs called _w_i_n_d_o_w _m_a_n_a_g_e_r_s.  Although many win-
       dow managers will honor geometry specifications as  given,
       others  may  choose  to ignore them (requiring the user to
       explicitly draw the window's region on the screen with the
       pointer, for example).

       Since  window managers are regular (albeit complex) client
       programs, a variety of different user  interfaces  can  be
       built.	The X Consortium distribution comes with a window
       manager named  _t_w_m  which  supports  overlapping	 windows,
       popup  menus,  point-and-click or click-to-type input mod-
       els, title bars, nice icons (and an icon manager for those
       who don't like separate icon windows).

       See the user-contributed software in the X Consortium dis-
       tribution for other popular window managers.

FFOONNTT NNAAMMEESS
       Collections of characters for displaying text and  symbols
       in X are known as _f_o_n_t_s.	 A font typically contains images
       that share a common appearance and look nice together (for
       example,	 a  single  size,  boldness, slant, and character
       set).  Similarly, collections of fonts that are based on a
       common type face (the variations are usually called roman,
       bold, italic, bold italic, oblique, and bold oblique)  are
       called _f_a_m_i_l_i_e_s.

       Fonts  come in various sizes.  The X server supports _s_c_a_l_-
       _a_b_l_e fonts, meaning it is possible to  create  a	 font  of
       arbitrary  size	from  a	 single source for the font.  The
       server supports scaling	from  _o_u_t_l_i_n_e  fonts  and  _b_i_t_m_a_p
       fonts.	Scaling	 from outline fonts usually produces sig-
       nificantly better results than scaling from bitmap  fonts.

       An  X server can obtain fonts from individual files stored
       in directories in the file system, or  from  one	 or  more
       font  servers,  or from a mixtures of directories and font
       servers.	 The list of places the server looks when  trying
       to  find	 a font is controlled by its _f_o_n_t _p_a_t_h.	 Although
       most installations will choose to have the server start up
       with all of the commonly used font directories in the font
       path, the font path can be changed at any  time	with  the
       _x_s_e_t  program.	However, it is important to remember that
       the directory names are on the sseerrvveerr's	machine,  not  on
       the application's.

       Bitmap  font files are usually created by compiling a tex-
       tual font description into binary  form,	 using	_b_d_f_t_o_p_c_f.
       Font  databases	are  created  by  running  the	_m_k_f_o_n_t_d_i_r



X Version 11		    Release 6				7





X(1)							     X(1)


       program in the directory containing the source or compiled
       versions	 of  the  fonts.   Whenever  fonts are added to a
       directory, _m_k_f_o_n_t_d_i_r should be rerun so	that  the  server
       can  find  the  new  fonts.  To make the server reread the
       font database, reset the font path with the _x_s_e_t	 program.
       For  example,  to  add  a font to a private directory, the
       following commands could be used:

	   % cp newfont.pcf ~/myfonts
	   % mkfontdir ~/myfonts
	   % xset fp rehash

       The _x_f_o_n_t_s_e_l and _x_l_s_f_o_n_t_s programs can be used  to  browse
       through	the fonts available on a server.  Font names tend
       to be fairly long as they contain all of	 the  information
       needed  to  uniquely  identify individual fonts.	 However,
       the X server supports wildcarding of font  names,  so  the
       full specification

	   _-_a_d_o_b_e_-_c_o_u_r_i_e_r_-_m_e_d_i_u_m_-_r_-_n_o_r_m_a_l_-_-_1_0_-_1_0_0_-_7_5_-_7_5_-_m_-_6_0_-_i_s_o_8_8_5_9_-_1

       might be abbreviated as:

	   _-_*_-_c_o_u_r_i_e_r_-_m_e_d_i_u_m_-_r_-_n_o_r_m_a_l_-_-_*_-_1_0_0_-_*_-_*_-_*_-_*_-_i_s_o_8_8_5_9_-_1

       Because	the  shell also has special meanings for _* and _?,
       wildcarded font names should be quoted:

	   % xlsfonts -fn '-*-courier-medium-r-normal--*-100-*-*-*-*-*-*'

       The _x_l_s_f_o_n_t_s program can be used to list all of the  fonts
       that  match  a given pattern.  With no arguments, it lists
       all available fonts.  This will usually list the same font
       at  many	 different  sizes.  To see just the base scalable
       font names, try using one of the following patterns:

	   _-_*_-_*_-_*_-_*_-_*_-_*_-_0_-_0_-_0_-_0_-_*_-_0_-_*_-_*
	   _-_*_-_*_-_*_-_*_-_*_-_*_-_0_-_0_-_7_5_-_7_5_-_*_-_0_-_*_-_*
	   _-_*_-_*_-_*_-_*_-_*_-_*_-_0_-_0_-_1_0_0_-_1_0_0_-_*_-_0_-_*_-_*

       To convert one of the resulting names into  a  font  at	a
       specific	 size,	replace one of the first two zeros with a
       nonzero value.  The field containing the first zero is for
       the  pixel size; replace it with a specific height in pix-
       els to name a font at that size.	 Alternatively, the field
       containing  the second zero is for the point size; replace
       it with a specific size in  decipoints  (there  are  722.7
       decipoints  to the inch) to name a font at that size.  The
       last zero is an average width field, measured in tenths of
       pixels;	some  servers  will  anamorphically scale if this
       value is specified.

FFOONNTT SSEERRVVEERR NNAAMMEESS
       One of the following forms can be  used	to  name  a  font



X Version 11		    Release 6				8





X(1)							     X(1)


       server that accepts TCP connections:

	   tcp/_h_o_s_t_n_a_m_e:_p_o_r_t
	   tcp/_h_o_s_t_n_a_m_e:_p_o_r_t/_c_a_t_a_l_o_g_u_e_l_i_s_t

       The  _h_o_s_t_n_a_m_e  specifies	 the  name  (or	 decimal  numeric
       address) of the machine on which the font server	 is  run-
       ning.   The _p_o_r_t is the decimal TCP port on which the font
       server is listening for	connections.   The  _c_a_t_a_l_o_g_u_e_l_i_s_t
       specifies a list of catalogue names, with '+' as a separa-
       tor.

       Examples: _t_c_p_/_x_._o_r_g_:_7_1_0_0, _t_c_p_/_1_9_8_._1_1_2_._4_5_._1_1_:_7_1_0_0_/_a_l_l.

       One of the following forms can be  used	to  name  a  font
       server that accepts DECnet connections:

	   decnet/_n_o_d_e_n_a_m_e::font$_o_b_j_n_a_m_e
	   decnet/_n_o_d_e_n_a_m_e::font$_o_b_j_n_a_m_e/_c_a_t_a_l_o_g_u_e_l_i_s_t

       The  _n_o_d_e_n_a_m_e  specifies	 the  name  (or	 decimal  numeric
       address) of the machine on which the font server	 is  run-
       ning.   The  _o_b_j_n_a_m_e  is a normal, case-insensitive DECnet
       object name.  The _c_a_t_a_l_o_g_u_e_l_i_s_t specifies a list of  cata-
       logue names, with '+' as a separator.

       Examples:	 _D_E_C_n_e_t_/_S_R_V_N_O_D_:_:_F_O_N_T_$_D_E_F_A_U_L_T,	     _d_e_c_-
       _n_e_t_/_4_4_._7_0_:_:_f_o_n_t_$_s_p_e_c_i_a_l_/_s_y_m_b_o_l_s.

CCOOLLOORR NNAAMMEESS
       Most  applications  provide  ways  of  tailoring	 (usually
       through resources or command line arguments) the colors of
       various elements in the text and graphics they display.	A
       color  can  be specified either by an abstract color name,
       or by a	numerical  color  specification.   The	numerical
       specification  can  identify  a	color  in  either device-
       dependent  (RGB)	 or  device-independent	  terms.    Color
       strings are case-insensitive.

       X  supports  the use of abstract color names, for example,
       "red", "blue".  A value for this abstract name is obtained
       by searching one or more color name databases.  _X_l_i_b first
       searches zero or more client-side databases;  the  number,
       location, and content of these databases is implementation
       dependent.  If the name is not found, the color is  looked
       up  in  the  X  server's	 database.  The text form of this
       database	   is	 commonly    stored    in    the     file
       _<_X_R_o_o_t_>_/_l_i_b_/_X_1_1_/_r_g_b_._t_x_t,	 where <XRoot> is replaced by the
       root of the X11 install tree.

       A numerical color specification consists of a color  space
       name and a set of values in the following syntax:

	   _<_c_o_l_o_r___s_p_a_c_e___n_a_m_e_>:_<_v_a_l_u_e_>_/_._._._/_<_v_a_l_u_e_>



X Version 11		    Release 6				9





X(1)							     X(1)


       An  RGB	Device	specification is identified by the prefix
       "rgb:" and has the following syntax:

	   rgb:_<_r_e_d_>_/_<_g_r_e_e_n_>_/_<_b_l_u_e_>

	       _<_r_e_d_>, _<_g_r_e_e_n_>, _<_b_l_u_e_> := _h | _h_h | _h_h_h | _h_h_h_h
	       _h := single hexadecimal digits
       Note that _h indicates the value scaled in 4 bits,  _h_h  the
       value  scaled  in 8 bits, _h_h_h the value scaled in 12 bits,
       and _h_h_h_h the value scaled in 16 bits, respectively.  These
       values  are  passed  directly  to  the  X  server, and are
       assumed to be gamma corrected.

       The eight primary colors can be represented as:

	   black		rgb:0/0/0
	   red			rgb:ffff/0/0
	   green		rgb:0/ffff/0
	   blue			rgb:0/0/ffff
	   yellow		rgb:ffff/ffff/0
	   magenta		rgb:ffff/0/ffff
	   cyan			rgb:0/ffff/ffff
	   white		rgb:ffff/ffff/ffff

       For backward compatibility, an older syntax for RGB Device
       is  supported,  but  its	 continued use is not encouraged.
       The syntax is an initial sharp sign character followed  by
       a numeric specification, in one of the following formats:

	   #RGB			     (4 bits each)
	   #RRGGBB		     (8 bits each)
	   #RRRGGGBBB		     (12 bits each)
	   #RRRRGGGGBBBB	     (16 bits each)

       The R, G, and B represent single hexadecimal digits.  When
       fewer than 16 bits each are specified, they represent  the
       most-significant bits of the value (unlike the "rgb:" syn-
       tax, in which values are scaled).  For  example,	 #3a7  is
       the same as #3000a0007000.

       An RGB intensity specification is identified by the prefix
       "rgbi:" and has the following syntax:

	   rgbi:_<_r_e_d_>_/_<_g_r_e_e_n_>_/_<_b_l_u_e_>

       The red, green, and blue are floating point values between
       0.0  and	 1.0, inclusive.  They represent linear intensity
       values, with  1.0  indicating  full  intensity,	0.5  half
       intensity,  and	so  on.	  These values will be gamma cor-
       rected by _X_l_i_b before being sent to  the	 X  server.   The
       input  format  for  these  values  is  an optional sign, a
       string of numbers possibly containing a decimal point, and
       an  optional  exponent field containing an E or e followed
       by a possibly signed integer string.



X Version 11		    Release 6			       10





X(1)							     X(1)


       The standard device-independent string specifications have
       the following syntax:

	   CIEXYZ:_<_X_>_/_<_Y_>_/_<_Z_>		  (_n_o_n_e, 1, _n_o_n_e)
	   CIEuvY:_<_u_>_/_<_v_>_/_<_Y_>		  (~.6, ~.6, 1)
	   CIExyY:_<_x_>_/_<_y_>_/_<_Y_>		  (~.75, ~.85, 1)
	   CIELab:_<_L_>_/_<_a_>_/_<_b_>		  (100, _n_o_n_e, _n_o_n_e)
	   CIELuv:_<_L_>_/_<_u_>_/_<_v_>		  (100, _n_o_n_e, _n_o_n_e)
	   TekHVC:_<_H_>_/_<_V_>_/_<_C_>		  (360, 100, 100)

       All of the values (C, H, V, X, Y, Z, a, b, u, v, y, x) are
       floating point values.  Some of the values are constrained
       to  be between zero and some upper bound; the upper bounds
       are given in parentheses above.	The syntax for these val-
       ues  is	an  optional  '+' or '-' sign, a string of digits
       possibly containing a decimal point, and an optional expo-
       nent  field  consisting	of  an	'E' or 'e' followed by an
       optional '+' or '-' followed by a string of digits.

       For more information on device independent color, see  the
       _X_l_i_b reference manual.

KKEEYYBBOOAARRDDSS
       The  X  keyboard model is broken into two layers:  server-
       specific codes (called _k_e_y_c_o_d_e_s) which represent the phys-
       ical keys, and server-independent symbols (called _k_e_y_s_y_m_s)
       which represent the letters or words that  appear  on  the
       keys.   Two  tables  are kept in the server for converting
       keycodes to keysyms:

       _m_o_d_i_f_i_e_r _l_i_s_t
	       Some keys (such as Shift, Control, and Caps  Lock)
	       are  known as _m_o_d_i_f_i_e_r and are used to select dif-
	       ferent symbols that are attached to a  single  key
	       (such  as  Shift-a generates a capital A, and Con-
	       trol-l generates a  control  character  ^L).   The
	       server  keeps  a list of keycodes corresponding to
	       the various modifier  keys.   Whenever  a  key  is
	       pressed or released, the server generates an _e_v_e_n_t
	       that contains the keycode of the indicated key  as
	       well  as	 a mask that specifies which of the modi-
	       fier keys are currently pressed.	 Most servers set
	       up  this	 list  to  initially  contain the various
	       shift, control, and shift lock keys  on	the  key-
	       board.

       _k_e_y_m_a_p _t_a_b_l_e
	       Applications translate event keycodes and modifier
	       masks into keysyms using a _k_e_y_s_y_m _t_a_b_l_e which con-
	       tains  one row for each keycode and one column for
	       various modifier states.	 This table  is	 initial-
	       ized  by	 the server to correspond to normal type-
	       writer conventions.  The exact  semantics  of  how
	       the   table  is	interpreted  to	 produce  keysyms



X Version 11		    Release 6			       11





X(1)							     X(1)


	       depends on the particular program, libraries,  and
	       language input method used, but the following con-
	       ventions for the first four keysyms  in	each  row
	       are generally adhered to:

       The  first  four	 elements  of the list are split into two
       groups of keysyms.  Group 1 contains the first and  second
       keysyms;	 Group	2  contains the third and fourth keysyms.
       Within each group, if the first element is alphabetic  and
       the  the	 second	 element  is the special keysym _N_o_S_y_m_b_o_l,
       then the group is treated as  equivalent	 to  a	group  in
       which  the  first  element is the lowercase letter and the
       second element is the uppercase letter.

       Switching between groups is controlled by the keysym named
       MODE  SWITCH,  by  attaching  that  keysym to some key and
       attaching that key  to  any  one	 of  the  modifiers  Mod1
       through	Mod5.	This modifier is called the ``group modi-
       fier.''	Group 1 is used when the group modifier	 is  off,
       and Group 2 is used when the group modifier is on.

       Within a group, the modifier state determines which keysym
       to use.	The first keysym is used when the Shift and  Lock
       modifiers  are  off.   The  second keysym is used when the
       Shift modifier is on, when the Lock modifier is on and the
       second  keysym  is  uppercase alphabetic, or when the Lock
       modifier is on and is interpreted  as  ShiftLock.   Other-
       wise,  when  the Lock modifier is on and is interpreted as
       CapsLock, the state of the Shift modifier is applied first
       to select a keysym; but if that keysym is lowercase alpha-
       betic, then the corresponding  uppercase	 keysym	 is  used
       instead.

OOPPTTIIOONNSS
       Most  X programs attempt to use the same names for command
       line options and arguments.  All applications written with
       the  X Toolkit Intrinsics automatically accept the follow-
       ing options:

       --ddiissppllaayy _d_i_s_p_l_a_y
	       This option specifies the name of the X server  to
	       use.

       --ggeeoommeettrryy _g_e_o_m_e_t_r_y
	       This  option  specifies the initial size and loca-
	       tion of the window.

       --bbgg _c_o_l_o_r,, --bbaacckkggrroouunndd _c_o_l_o_r
	       Either option specifies the color to use	 for  the
	       window background.

       --bbdd _c_o_l_o_r,, --bboorrddeerrccoolloorr _c_o_l_o_r
	       Either  option  specifies the color to use for the
	       window border.



X Version 11		    Release 6			       12





X(1)							     X(1)


       --bbww _n_u_m_b_e_r,, --bboorrddeerrwwiiddtthh _n_u_m_b_e_r
	       Either option specifies the width in pixels of the
	       window border.

       --ffgg _c_o_l_o_r,, --ffoorreeggrroouunndd _c_o_l_o_r
	       Either  option specifies the color to use for text
	       or graphics.

       --ffnn _f_o_n_t,, --ffoonntt _f_o_n_t
	       Either option specifies the font to use	for  dis-
	       playing text.

       --iiccoonniicc
	       This  option  indicates that the user would prefer
	       that the application's windows  initially  not  be
	       visible	as  if	the  windows  had  be immediately
	       iconified by the user.  Window managers may choose
	       not to honor the application's request.

       --nnaammee
	       This   option   specifies  the  name  under  which
	       resources for the  application  should  be  found.
	       This  option is useful in shell aliases to distin-
	       guish between invocations of an application, with-
	       out  resorting to creating links to alter the exe-
	       cutable file name.

       --rrvv, --rreevveerrssee
	       Either option indicates that  the  program  should
	       simulate reverse video if possible, often by swap-
	       ping the foreground and	background  colors.   Not
	       all programs honor this or implement it correctly.
	       It is usually only used on monochrome displays.

       ++rrvv
	       This option indicates that the program should  not
	       simulate	 reverse video.	 This is used to override
	       any defaults since reverse  video  doesn't  always
	       work properly.

       --sseelleeccttiioonnTTiimmeeoouutt
	       This  option specifies the timeout in milliseconds
	       within which two communicating  applications  must
	       respond to one another for a selection request.

       --ssyynncchhrroonnoouuss
	       This  option  indicates	that  requests	to  the X
	       server should be sent  synchronously,  instead  of
	       asynchronously.	  Since	  _X_l_i_b	normally  buffers
	       requests to the server, errors do not  necessarily
	       get  reported  immediately after they occur.  This
	       option turns off the buffering so that the  appli-
	       cation  can  be debugged.  It should never be used
	       with a working program.



X Version 11		    Release 6			       13





X(1)							     X(1)


       --ttiittllee _s_t_r_i_n_g
	       This option specifies the title	to  be	used  for
	       this  window.   This information is sometimes used
	       by a window manager to provide some sort of header
	       identifying the window.

       --xxnnllllaanngguuaaggee _l_a_n_g_u_a_g_e_[___t_e_r_r_i_t_o_r_y_]_[_._c_o_d_e_s_e_t_]
	       This option specifies the language, territory, and
	       codeset for use in resolving  resource  and  other
	       filenames.

       --xxrrmm _r_e_s_o_u_r_c_e_s_t_r_i_n_g
	       This option specifies a resource name and value to
	       override any defaults.  It is also very useful for
	       setting resources that don't have explicit command
	       line arguments.

RREESSOOUURRCCEESS
       To make the tailoring of applications to personal  prefer-
       ences  easier,  X provides a mechanism for storing default
       values for program resources (e.g. background color,  win-
       dow  title, etc.)  Resources are specified as strings that
       are read in from various places	when  an  application  is
       run.  Program components are named in a hierarchical fash-
       ion, with each node in the hierarchy identified by a class
       and  an	instance name.	At the top level is the class and
       instance name of the application itself.	  By  convention,
       the  class name of the application is the same as the pro-
       gram name, but with  the first  letter  capitalized  (e.g.
       _B_i_t_m_a_p  or  _E_m_a_c_s)  although some programs that begin with
       the letter ``x'' also capitalize	 the  second  letter  for
       historical reasons.

       The precise syntax for resources is:

       ResourceLine	 = Comment | IncludeFile | ResourceSpec | <empty line>
       Comment		 = "!" {<any character except null or newline>}
       IncludeFile	 = "#" WhiteSpace "include" WhiteSpace FileName WhiteSpace
       FileName		 = <valid filename for operating system>
       ResourceSpec	 = WhiteSpace ResourceName WhiteSpace ":" WhiteSpace Value
       ResourceName	 = [Binding] {Component Binding} ComponentName
       Binding		 = "." | "*"
       WhiteSpace	 = {<space> | <horizontal tab>}
       Component	 = "?" | ComponentName
       ComponentName	 = NameChar {NameChar}
       NameChar		 = "a"-"z" | "A"-"Z" | "0"-"9" | "_" | "-"
       Value		 = {<any character except null or unescaped newline>}

       Elements	 separated  by vertical bar (|) are alternatives.
       Curly braces ({...}) indicate zero or more repetitions  of
       the  enclosed  elements.	 Square brackets ([...]) indicate
       that the enclosed element is optional.  Quotes ("...") are
       used around literal characters.




X Version 11		    Release 6			       14





X(1)							     X(1)


       IncludeFile  lines  are	interpreted by replacing the line
       with  the  contents  of	the  specified	file.	The  word
       "include"  must	be  in lowercase.  The filename is inter-
       preted relative to the directory of the file in which  the
       line  occurs  (for  example,  if	 the filename contains no
       directory or contains a relative directory specification).

       If a ResourceName contains a contiguous sequence of two or
       more Binding characters, the  sequence  will  be	 replaced
       with  single  "."  character if the sequence contains only
       "." characters, otherwise the sequence  will  be	 replaced
       with a single "*" character.

       A resource database never contains more than one entry for
       a given ResourceName.  If a resource file contains  multi-
       ple lines with the same ResourceName, the last line in the
       file is used.

       Any whitespace character before or after the name or colon
       in  a ResourceSpec are ignored.	To allow a Value to begin
       with whitespace,	 the  two-character  sequence  ``\_s_p_a_c_e''
       (backslash  followed  by space) is recognized and replaced
       by a  space  character,	and  the  two-character	 sequence
       ``\_t_a_b''	 (backslash followed by horizontal tab) is recog-
       nized and replaced by  a	 horizontal  tab  character.   To
       allow  a Value to contain embedded newline characters, the
       two-character sequence ``\n'' is recognized  and	 replaced
       by  a  newline  character.   To allow a Value to be broken
       across multiple lines in a text	file,  the  two-character
       sequence	 ``\_n_e_w_l_i_n_e''  (backslash followed by newline) is
       recognized and removed from the value.  To allow	 a  Value
       to  contain  arbitrary character codes, the four-character
       sequence ``\_n_n_n'', where each _n is a  digit  character  in
       the  range of ``0''-``7'', is recognized and replaced with
       a single byte that contains the octal value  specified  by
       the  sequence.  Finally, the two-character sequence ``\\''
       is recognized and replaced with a single backslash.

       When an application looks for the value of a resource,  it
       specifies  a  complete  path  in	 the hierarchy, with both
       class and instance names.  However,  resource  values  are
       usually	given  with  only  partially  specified names and
       classes, using pattern matching constructs.   An	 asterisk
       (*) is a loose binding and is used to represent any number
       of intervening components, including none.  A  period  (.)
       is  a  tight  binding  and is used to separate immediately
       adjacent components.  A question mark (?) is used to match
       any single component name or class.  A database entry can-
       not end in a loose binding;  the	 final	component  (which
       cannot  be  "?")	 must be specified.  The lookup algorithm
       searches the resource database for  the	entry  that  most
       closely	matches	 (is most specific for) the full name and
       class being queried.  When more than  one  database  entry
       matches the full name and class, precedence rules are used



X Version 11		    Release 6			       15





X(1)							     X(1)


       to select just one.

       The full name and class are scanned  from  left	to  right
       (from  highest level in the hierarchy to lowest), one com-
       ponent at a time.  At each level, the corresponding compo-
       nent  and/or binding of each matching entry is determined,
       and these matching components and  bindings  are	 compared
       according  to  precedence  rules.   Each	 of  the rules is
       applied at each level, before moving to	the  next  level,
       until  a rule selects a single entry over all others.  The
       rules (in order of precedence) are:

       1.   An entry that contains a matching component	 (whether
	    name,  class,  or "?")  takes precedence over entries
	    that elide the level (that is, entries that match the
	    level in a loose binding).

       2.   An	entry  with a matching name takes precedence over
	    both entries with a matching class and  entries  that
	    match  using  "?".	 An  entry  with a matching class
	    takes precedence over entries that match using "?".

       3.   An entry preceded by a tight binding takes precedence
	    over entries preceded by a loose binding.

       Programs based on the X Tookit Intrinsics obtain resources
       from the following sources (other programs usually support
       some subset of these sources):

       RREESSOOUURRCCEE__MMAANNAAGGEERR rroooott wwiinnddooww pprrooppeerrttyy
	       Any  global  resources that should be available to
	       clients on all machines should be  stored  in  the
	       RESOURCE_MANAGER	 property  on  the root window of
	       the first screen using the _x_r_d_b program.	 This  is
	       frequently taken care of when the user starts up X
	       through the display manager or _x_i_n_i_t.

       SSCCRREEEENN__RREESSOOUURRCCEESS rroooott wwiinnddooww pprrooppeerrttyy
	       Any resources specific to  a  given  screen  (e.g.
	       colors) that should be available to clients on all
	       machines should be stored in the	 SCREEN_RESOURCES
	       property	 on  the root window of that screen.  The
	       _x_r_d_b program will sort resources automatically and
	       place	  them	   in	  RESOURCE_MANAGER     or
	       SCREEN_RESOURCES, as appropriate.

       aapppplliiccaattiioonn--ssppeecciiffiicc ffiilleess
	       Directories  named  by  the  environment	 variable
	       XUSERFILESEARCHPATH  or	the  environment variable
	       XAPPLRESDIR (which names a  single  directory  and
	       should  end  with  a  '/'  on POSIX systems), plus
	       directories in a	 standard  place  (usually  under
	       <XRoot>/lib/X11/,  but this can be overridden with
	       the  XFILESEARCHPATH  environment  variable)   are



X Version 11		    Release 6			       16





X(1)							     X(1)


	       searched	 for  for application-specific resources.
	       For example,  application  default  resources  are
	       usually	 kept  in  <XRoot>/lib/X11/app-defaults/.
	       See the _X _T_o_o_l_k_i_t _I_n_t_r_i_n_s_i_c_s _- _C	 _L_a_n_g_u_a_g_e  _I_n_t_e_r_-
	       _f_a_c_e manual for details.

       XXEENNVVIIRROONNMMEENNTT
	       Any  user-  and	machine-specific resources may be
	       specified by setting the XENVIRONMENT  environment
	       variable	 to  the  name	of  a resource file to be
	       loaded by all applications.  If this  variable  is
	       not   defined,	a  file	 named	_$_H_O_M_E/.Xdefaults-
	       _h_o_s_t_n_a_m_e is looked for instead, where _h_o_s_t_n_a_m_e  is
	       the name of the host where the application is exe-
	       cuting.

       --xxrrmm _r_e_s_o_u_r_c_e_s_t_r_i_n_g
	       Resources can also be specified from  the  command
	       line.   The  _r_e_s_o_u_r_c_e_s_t_r_i_n_g  is	a single resource
	       name and value as shown above.  Note that  if  the
	       string  contains	 characters  interpreted  by  the
	       shell (e.g., asterisk), they must be quoted.   Any
	       number  of --xxrrmm arguments may be given on the com-
	       mand line.

       Program	resources  are	organized  into	  groups   called
       _c_l_a_s_s_e_s, so that collections of individual resources (each
       of which are called _i_n_s_t_a_n_c_e_s) can be set all at once.  By
       convention,  the instance name of a resource begins with a
       lowercase letter and class name with an upper case letter.
       Multiple	 word  resources  are concatenated with the first
       letter of the succeeding words capitalized.   Applications
       written	with  the X Toolkit Intrinsics will have at least
       the following resources:


       bbaacckkggrroouunndd ((class BBaacckkggrroouunndd))
	       This resource specifies the color to use	 for  the
	       window background.


       bboorrddeerrWWiiddtthh ((class BBoorrddeerrWWiiddtthh))
	       This resource specifies the width in pixels of the
	       window border.


       bboorrddeerrCCoolloorr ((class BBoorrddeerrCCoolloorr))
	       This resource specifies the color to use	 for  the
	       window border.

       Most applications using the X Toolkit Intrinsics also have
       the resource ffoorreeggrroouunndd (class FFoorreeggrroouunndd), specifying the
       color to use for text and graphics within the window.




X Version 11		    Release 6			       17





X(1)							     X(1)


       By  combining  class and instance specifications, applica-
       tion preferences can be set quickly and easily.	Users  of
       color  displays will frequently want to set Background and
       Foreground classes to particular defaults.  Specific color
       instances  such	as  text  cursors  can then be overridden
       without having to define all  of	 the  related  resources.
       For example,

	   bitmap*Dashed:  off
	   XTerm*cursorColor:  gold
	   XTerm*multiScroll:  on
	   XTerm*jumpScroll:  on
	   XTerm*reverseWrap:  on
	   XTerm*curses:  on
	   XTerm*Font:	6x10
	   XTerm*scrollBar: on
	   XTerm*scrollbar*thickness: 5
	   XTerm*multiClickTime: 500
	   XTerm*charClass:  33:48,37:48,45-47:48,64:48
	   XTerm*cutNewline: off
	   XTerm*cutToBeginningOfLine: off
	   XTerm*titeInhibit:  on
	   XTerm*ttyModes:  intr ^c erase ^? kill ^u
	   XLoad*Background: gold
	   XLoad*Foreground: red
	   XLoad*highlight: black
	   XLoad*borderWidth: 0
	   emacs*Geometry:  80x65-0-0
	   emacs*Background:  rgb:5b/76/86
	   emacs*Foreground:  white
	   emacs*Cursor:  white
	   emacs*BorderColor:  white
	   emacs*Font:	6x10
	   xmag*geometry: -0-0
	   xmag*borderColor:  white

       If  these  resources  were  stored  in a file called _._X_r_e_-
       _s_o_u_r_c_e_s in your home directory, they could be added to any
       existing	 resources  in the server with the following com-
       mand:

	   % xrdb -merge $HOME/.Xresources

       This is frequently how user-friendly startup scripts merge
       user-specific  defaults	into any site-wide defaults.  All
       sites are encouraged to set up convenient ways of automat-
       ically  loading	resources.  See	 the  _X_l_i_b manual section
       _R_e_s_o_u_r_c_e _M_a_n_a_g_e_r _F_u_n_c_t_i_o_n_s for more information.

EEXXAAMMPPLLEESS
       The following is a collection of sample command lines  for
       some  of	 the  more  frequently	used  commands.	 For more
       information on a particular command, please refer to  that
       command's manual page.



X Version 11		    Release 6			       18





X(1)							     X(1)


	   %  xrdb $HOME/.Xresources
	   %  xmodmap -e "keysym BackSpace = Delete"
	   %  mkfontdir /usr/local/lib/X11/otherfonts
	   %  xset fp+ /usr/local/lib/X11/otherfonts
	   %  xmodmap $HOME/.keymap.km
	   %  xsetroot -solid 'rgbi:.8/.8/.8'
	   %  xset b 100 400 c 50 s 1800 r on
	   %  xset q
	   %  twm
	   %  xmag
	   %  xclock -geometry 48x48-0+0 -bg blue -fg white
	   %  xeyes -geometry 48x48-48+0
	   %  xbiff -update 20
	   %  xlsfonts '*helvetica*'
	   %  xwininfo -root
	   %  xdpyinfo -display joesworkstation:0
	   %  xhost -joesworkstation
	   %  xrefresh
	   %  xwd | xwud
	   %  bitmap companylogo.bm 32x32
	   %  xcalc -bg blue -fg magenta
	   %  xterm -geometry 80x66-0-0 -name myxterm $*
	   %  xon filesysmachine xload

DDIIAAGGNNOOSSTTIICCSS
       A  wide variety of error messages are generated from vari-
       ous programs.  The default error	 handler  in  _X_l_i_b  (also
       used  by	 many  toolkits)  uses standard resources to con-
       struct  diagnostic  messages  when  errors   occur.    The
       defaults	  for	these  messages	 are  usually  stored  in
       _<_X_R_o_o_t_>_/_l_i_b_/_X_1_1_/_X_E_r_r_o_r_D_B.  If this file	is  not	 present,
       error messages will be rather terse and cryptic.

       When  the X Toolkit Intrinsics encounter errors converting
       resource strings to the appropriate  internal  format,  no
       error  messages	are  usually printed.  This is convenient
       when it is desirable to have one set of resources across a
       variety	of  displays  (e.g. color vs. monochrome, lots of
       fonts vs. very few, etc.), although it can  pose	 problems
       for  trying to determine why an application might be fail-
       ing.  This behavior can be overridden by the  setting  the
       _S_t_r_i_n_g_C_o_n_v_e_r_s_i_o_n_s_W_a_r_n_i_n_g resource.

       To  force  the X Toolkit Intrinsics to always print string
       conversion error messages, the following	 resource  should
       be   placed   in	 the  file  that  gets	loaded	onto  the
       RESOURCE_MANAGER property using	the  _x_r_d_b  program  (fre-
       quently	called	_._X_r_e_s_o_u_r_c_e_s  or	 _._X_r_e_s in the user's home
       directory):

	   *StringConversionWarnings: on

       To have conversion messages printed for just a  particular
       application,  the  appropriate instance name can be placed



X Version 11		    Release 6			       19





X(1)							     X(1)


       before the asterisk:

	   xterm*StringConversionWarnings: on

SSEEEE AALLSSOO
       XConsortium(1), XStandards(1), Xsecurity(1),

       appres(1), bdftopcf(1), bitmap(1), editres(1),  fsinfo(1),
       fslsfonts(1),  fstobdf(1),  iceauth(1),	imake(1), makede-
       pend(1),	 mkfontdir(1),	oclock(1),   rgb(1),   resize(1),
       rstart(1),  twm(1),  x11perf(1), x11perfcomp(1), xauth(1),
       xclipboard(1), xclock(1), xcmsdb(1), xconsole(1),  xdm(1),
       xdpyinfo(1),   xfd(1),	xfs(1),	  xhost(1),   xieperf(1),
       xinit(1),  xkbcomp(1),  xkill(1),  xlogo(1),  xlsatoms(1),
       xlsclients(1),  xlsfonts(1),  xmag(1), xmh(1), xmodmap(1),
       xon(1), xprop(1),  xrdb(1),  xrefresh(1),  xset(1),  xset-
       root(1),	  xstdcmap(1),	 xterm(1),  xwd(1),  xwininfo(1),
       xwud(1),	  Xserver(1),	Xdec(1),   XmacII(1),	 Xsun(1),
       Xnest(1),      Xvfb(1),	   XF86_Acc(1),	    XF86_Mono(1),
       XF86_SVGA(1), XF86_VGA16(1), XFree86(1), kbd_mode(1), _X_l_i_b
       _-  _C  _L_a_n_g_u_a_g_e  _X  _I_n_t_e_r_f_a_c_e, and _X _T_o_o_l_k_i_t _I_n_t_r_i_n_s_i_c_s _- _C
       _L_a_n_g_u_a_g_e _I_n_t_e_r_f_a_c_e

TTRRAADDEEMMAARRKKSS
       X Window System is  a  trademark	 of  X	Consortium,  Inc.
       Fresco is a registered trademark of X Consortium, Inc.

AAUUTTHHOORRSS
       A  cast	of thousands, literally.  The Release 6 distribu-
       tion is brought to you by X Consortium, Inc.  The names of
       all  people  who	 made  it  a reality will be found in the
       individual documents and source files.  The staff  members
       at  the	X  Consortium  responsible  for this release are:
       Donna Converse, Gary Cutbill, Stephen Gildea,  Jay  Hersh,
       Kaleb  Keithley, Matt Landau, Ralph Mor, Janet O'Halloran,
       Bob Scheifler, Ralph Swick, and Dave Wiggins.

       The X Window System standard was originally  developed  at
       the  Laboratory	for Computer Science at the Massachusetts
       Institute of  Technology,  and  all  rights  thereto  were
       assigned to the X Consortium on January 1, 1994.
















X Version 11		    Release 6			       20