Skip site navigation (1)Skip section navigation (2)

FreeBSD Manual Pages


home | help
Xprint(7)	       Miscellaneous Information Manual		     Xprint(7)

       Xprint -	The "X print service" -	a portable, network-transparent	print-
       ing system based	on the X11 protocol

       Xprint is a very	flexible, extensible, scaleable,  client/server	 print
       system  based on	ISO 10175 (and some other specs) and the X11 rendering
       protocol.  Using	Xprint an application can search, query	 and  use  de-
       vices  like  printers, FAX machines or create documents in formats like
       PDF.  In	particular, an application can seek a printer, query supported
       attributes  (like paper size, trays, fonts etc.), configure the printer
       device to match it's needs and print on it like on any other  X	device
       reusing parts of	the code which is used for the video card Xserver.

       The  "X Print Service" technology allows	X rendering to devices such as
       printers	and fax. Most of the service is	available in the X11  technol-
       ogy  stack as Xp, with the remainder in single toolkit stacks (e.g. Dt-
       Print for CDE).	Modifications have also	been made to  the  LessTif/Mo-
       tif/Qt technology stacks	to support Xprint.

       The Xp portion consists of:

       o Xp Extension for the X-Server (included in the	X-Server Xprt)

       o Xp Extension API for the client side (libXp/libXprintUtils)

       o PCL ddx driver	that converts core X to	native PCL

       o PDF ddx driver	that converts core X to	native PDF

       o PostScript ddx	driver that converts core X to native PostScript

       o Raster	 ddx  driver that generates xwd	rasters	which can be converted
	 to PCL, PDF or	PostScript rasters

       From an X clients perspective, it can attach to one of two nearly iden-
       tical  X-Servers,  a "Video" X-Server, and a "Print" X-Server which has
       the additional Xp capability but	otherwise looks	and behaves the	same.

       The X Print Service expands on the traditional X-Server and Xlib	 world
       in four ways.

       1.  Most	 obvious  is  the use of "print	ddx drivers" instead of	"video
	   ddx drivers". While a video ddx driver modifies pixels in  a	 video
	   frame  buffer,  a print ddx driver generates	"page description lan-
	   guage (PDL)"	output (such as	PCL, PDF or PostScript)	or  sends  the
	   print rendering instructions	to a platform-specific print API (like

	   Once	a print	ddx driver generates PDL output, it can	be sent	 to  a
	   spooler  such  as  lp(1)  or	 retrieved by the client (to implement
	   functionality like "print-to-file").

	   Though not currently	done, a	single X-Server	can support both print
	   and video ddx drivers.

       2.  Since  printers  support "paged" output, unlike video, a portion of
	   the Xp Extension supports APIs to delineate	printed	 output.   For
	   example, XpStartPage	and XpEndPage tell the X-Server	where a	physi-
	   cal page starts and ends in an otherwise  continuous	 stream	 of  X
	   rendering  primitives.  Likewise, XpStartJob	and XpEndJob determine
	   when	a collection of	pages starts  and  ends.   XpEndJob  typically
	   causes  the	generated  PDL	to  be submitted to a spooler, such as

       3.  Since printers have extensive capabilities, another portion of  the
	   Xp Extension	supports APIs to manipulate "print contexts".

	   Once	a printer is selected using the	Xp Extension API, a print con-
	   text	to represent it	can be created.	A print	context	 embodies  the
	   printer  selected - it contains the printer's default capabilities,
	   selectable range of capabilities, printer state, and	generated out-
	   put.	 Some "attributes" within the print context can	be modified by
	   the user, and the X-Server and print	ddx driver will	react  accord-
	   ingly.  For example,	the attribute "content-orientation" can	be set
	   to "landscape" or "portrait"	(if the	printer	supports these	values
	   - which can be queried using	the Xprint API as well).

       4.  Since  printers  can	have "built in"	fonts, the Xp Extension	in the
	   X-Server works with the print ddx drivers to	 make  available  (for
	   printing only) additional fonts on a	per print context basis.

	   When	 a print context is created and	set for	a given	printer, the X
	   font	calls may be able to access additional printer	fonts.	To  do
	   this	 (typically), the X-Server must	have access to "printer	metric
	   files" (.pmf) that describe at minimum the metrics of the built  in

       There are three tasks to	start the X Print Service:

       1.  configuring the X Print Server,

       2.  starting the	X Print	Service

       3.  configuring the user	session	so that	clients	can find the running X
	   Print Service

       The tasks are described in detail below.

       The X Print Server (Xprt) can read  a  number  of  configuration	 files
       which  control its behavior and support for printers. Each vendor plat-
       form has	a default location for this information. Xprt  can  also  read
       the  environment	variable XPCONFIGDIR to	locate alternate configuration
       directories. Common settings include:

       export XPCONFIGDIR=/X11/lib/X11/XpConfig/

       export XPCONFIGDIR=/proj/x11/xc/programs/Xserver/XpConfig/

       Xprt has	many built-in defaults,	and lacking any	 configuration	files,
       will immediately	try to support all printers visible via	lpstat(1).

       In order	of importance for configuration	by a system administrator, the
       configuration files for a "C" locale are	as follows  (see  Xprt(7)  for
       more details (including support for non-"C" locales)):

	      'Xprinters'  is  the  top	most configuration file. It tells Xprt
	      which specific printer names (e.g. mylaser) should be supported,
	      and  whether lpstat(1) or	other commands should be used to auto-
	      matically	supplement the list of printers.

	      The 'printer' file maps printer names  to	 model	configurations
	      (see  'model-config'  below).  For  example,  "mylaser" could be
	      mapped to	a "HPDJ1600C", and all other arbitrary printers	 could
	      be mapped	to a default, such as "HPLJ4SI". When depending	on lp-
	      stat(1) in the Xprinters file, setting up	defaults in  'printer'
	      becomes all the more important.

	      The  'document'  file  specifies the initial document values for
	      any print	jobs. For example, which paper tray to use,  what  de-
	      fault resolution,	etc.

	      The  'job'  file	specifies the initial job values for any print
	      jobs. For	example, "notification-profile"	can  be	 set  so  that
	      when  a  print  job is successfully sent to a printer, e-mail is
	      sent to the user.

       ${XPCONFIGDIR}/C/print/models/PSdefault/model-config,	      ${XPCON-
       FIGDIR}/C/print/models/PSdefault/fonts/fonts.dir,	      ${XPCON-
       FIGDIR}/C/print/models/PSdefault/fonts/9nb00051.pmf,	      ${XPCON-
	      The 'model-config' file has attributes that describe the printer
	      model's capabilities and default settings.  Printer model	 fonts
	      may  also	 be present. The model-config file also	identifies the
	      print ddx	driver to be used.  For	each printer model  supported,
	      a	complete hierarchy of files should exist. In most cases, these
	      files do not need	to be modified.

       ${XPCONFIGDIR}/C/print/ddx-config/raster/pcl,		      ${XPCON-
       FIGDIR}/C/print/ddx-config/raster/pdf,  ${XPCONFIGDIR}/C/print/ddx-con-
	      The print	ddx drivers can	 have  highly  specific	 configuration
	      files  to	 control their behavior. In most cases,	these files do
	      not need to be modified.

       More information	in how to configure and	customize the X	 print	server
       can be found in the Xprt(7) manual page.

       The summary checklist for starting the X	Print Service is as follows:

       1.  Choose an execution model for the X Print Service. The X Print Ser-
	   vice	can be run on a	per-user session basis,	per machine basis,  or
	   can	be  run	 on  a	few machines globally available	to a number of

       2.  If print jobs are to	be submitted to	a spooler (almost  always  the
	   case),  make	 sure all needed printers are available	to the spooler
	   subsystem (most often lp(1))	on the	same  machine  running	the  X
	   Print Service.

       3.  Configure the X Print Server. See ``X Print Server Configuration''.

       4.  Depending  on #1, start the X Print Server process "Xprt", and then
	   the toolkit-specific	Print Dialog Manager Daemon process  (such  as
	   CDEnext's  "dtpdmd")	 at  the  appropriate  times.  Note that libX-
	   printUtils-based applications/toolkits do not need a	 Print	Dialog
	   Manager Daemon process to use Xprint.

       The details are described below.

       Because	the  X	Print Service is based on X, it	can be easily distrib-
       uted.  The most significant factors in which execution model to	choose
       will be driven by:

       o how many printers will	be accessable through the printer subsystem on
	 any given machine. A  system  administrator  may  choose  to  cluster
	 printers on a few given machines, or scatter them across an organiza-
	 tion and possibly make	extensive use of remote	spoolers to make  them
	 globally available.

       o how  many  machines will need a copy of the X Print Server configura-
	 tion files. The files have been architected  so  that	one  super-set
	 version of them can be	maintained and distributed (e.g. via NFS), and
	 a per-machine or per-user version of the `Xprinters' is all  that  is
	 needed	 to  have  the appropriate information in them utilized	or ig-

       o how many users	can demand services from a given X Print Service.

       With the	above in mind, some obvious execution models include:

       o Global	- in this model, the system administrator is choosing  to  run
	 the  X	 Print	Service	 on  a	*few* select machines with appropriate
	 printers configured, and allow	clients	access to the global resource.
	 This  can centralize the administration of printers and configuration
	 files,	but may	have to	be monitored for performance loading.

	 Startup  would	 likely	 be  done  by	boot-up	  scripts   (such   as

       o Per-machine  -	 every	machine	 with  potential X Print Service users
	 would run the service.	Printer	and configuration file	administration
	 is  decentralized, and	usage would be limited to the users on the ma-

	 Startup  would	 likely	 be  done  by	boot-up	  scripts   (such   as

       o Per-user session - every user would run an entire X Print Service for
	 themselves. In	the future, the	Video X	Server	normally  started  may
	 contain  Print	 X Server capability, so this model becomes very natu-

	 Startup would likely be done at session login or by launching actions
	 or  processes manually	once the user logs in. Note: Deamons like "dt-
	 pdmd" must be started after Xprt.

       Starting	of the processes is straight forward. In strict	order (example
       is for manually starting	the X print server for CDEnext usage):


	   [machineA] %	Xprt [-XpFile <Xprinters file>]	[:dispNum] &

	   Note	 that  Xprt  will look for configuration files in either a de-
	   fault location or where XPCONFIGDIR points.

	   -XpFile specifies an	alternate `Xprinters' file,  rather  than  the
	   default one or `${XPCONFIGDIR}/C/print/Xprinters'.


	   [machineA] %	dtpdmd -d machineA[:dispNum] [-l /tmp/dtpdmd.log] &

	   The	dtpdmd	will maintain an X-Selection on	the X-Server, and will
	   start dtpdm's as required to	service	requests.

       In all but the per-user session model, the machine running  the	dtpdmd
       (thus  dtpdm's) will need display authorization to the users video dis-

       Once a X	Print Server and dtpdmd	have been started -- many of  them  in
       some  cases  --	clients	 will need to find and use them. There are two
       mechanisms that allow clients to	discover X Print Servers and printers.

       o "X Print Specifier" - assuming	usage of the DtPrint/XprintUtils-based
	 print applications, the following notation is understood:


	 For example:


	 In  the  above	example, the X Print Server running at `printhub:2' is
	 assumed to support the	printer	named `colorlj7'.

       o ${XPSERVERLIST} - assuming usage of the DtPrint  print	 dialogs,  the
	 environment  variable	${XPSERVERLIST}	 can contain a list of X Print
	 Servers. For example:

	 XPSERVERLIST="printhub:2 printhub:3 otherdept:0"

	 Then in the dialogs, only a printer name needs	to  be	entered.   The
	 dialog	 will then search the X	Print Servers in ${XPSERVERLIST} for a
	 server	than supports the printer, and then establish contact.

       From most CDEnext applications, printing	is  accomplished  by  bringing
       down  the <File>	menu and selecting <Print...>. This will result	in the
       DtPrintSetupBox dialog, which will request the name of a	 printer,  and
       offer  limited  capability  to  configure print options (e.g. number of
       copies).	If the user wishes, they can  select  <Setup...>,  which  will
       start  a	dtpdm capable of modifying additional print options.  Finally,
       the user	should select <Print>.

	      This environment variable	points	to  the	 root  of  the	Xprint
	      server  configuration  directory	hierarchy.  If the variable is
	      not defined, the default path is be assumed.  The	 default  path
	      may   be	 /usr/X11R6/lib/X11/xserver/,	/usr/lib/X11/xserver/,
	      /usr/share/Xprint/xserver/ or  /usr/openwin/server/etc/XpConfig,
	      depending	  on   the   system,   and   may   be	configured  in

	      This environment variable	selects	the locale  settings  used  by
	      the  Xprint  server.   Xprt  allows  language-specific  settings
	      (stored in ${XPCONFIGDIR}/${LANG}/print/)	 which	will  override
	      the  default  settings  (stored in ${XPCONFIGDIR}/C/print/).  If
	      ${LANG} is not set "C" is	assumed.

	      The environment variable ${XPSERVERLIST} contains	a list of dis-
	      play  identifiers	(separated by whitespace) which	tell an	appli-
	      cation  where  it	 can  find   the   Xprint   servers.   Usually
	      ${XPSERVERLIST}  is  set	by  the	 profile startup scripts (e.g.
	      /etc/profile or /etc/profile.d/	using  the  output  of
	      /etc/init.d/xprint get_xpserverlist.


			export XPSERVERLIST="`/etc/init.d/xprint get_xpserverlist`"

	      Alternatively ${XPSERVERLIST} can	be set manually. Example:

			export XPSERVERLIST="littlecat:80 bitdog:72"

	      instructs	 an application	to find	an Xprint server at display 80
	      on the machine "littlecat" and at	display	72 on the machine big-

	      The environment variable ${XPRINTER} defines the default printer
	      used by print applications. The syntax is	either printername  or


		     tells  an application to look for the first printer named
		     "ps003" on	all Xprint servers.

		     tells an application to use the  printer  "hplaser19"  on
		     the Xprint	server at display "littlecat:80".

       If  ${XPRINTER}	is not set the applications will examine the values of
       the ${PDPRINTER}, ${LPDEST}, and	${PRINTER} environment	variables  (in
       that order).

       X11(7),	 xplsprinters(7),   xprehashprinterlist(7),   xphelloworld(7),
       xpxmhelloworld(7), xpawhelloworld(7),  xpxthelloworld(7),  xpsimplehel-
       loworld(7),  Xserver(7),	 Xprt(7),  libXp(3),  libXprintUtils(3), libX-
       printAppUtils(3),   XmPrintShell(3),   XawPrintShell(3),	  Xprint   FAQ
       (,	  Xprint   main	  site

       This manual page	was written by Roland Mainz <>
       based on	the original X11R6.6 xc/programs/Xserver/XpConfig/README.

				8 October 2004			     Xprint(7)


Want to link to this manual page? Use this URL:

home | help