Xprint Frequently Asked Questions

In short, "Xprint" is an advanced printing system which enables X11 applications to use devices like printers, FAX or create documents in formats like PostScript, PDF or SVGprint.

In long, "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 devices like printers, FAX machines or create documents in formats like PDF or SVGprint. 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...

Xprint is client-server based, therefore two answers:

Xprt is the server-side of Xprint. It's just like any other Xserver - it uses only an other kind of output device (printer instead of framebuffer) and implements an extra X11 extension ("XpExtension") to handle the special features/requirements of a "paged device"(=printer etc.).

The current main site for the Xprint development is http://xprint.mozdev.org/ which hosts various resources including a mailinglist (please subscribe before posting) for end-users, admin and developers.

There are a few common misconceptions about Xprint. Let's take a look some of these "myths", some background - and the facts:

Question back: When do we need anti-aliased fonts ? Anti-aliasing is a "hack" to work around the limitations caused by the low resolution of monitors - they usually operate between 72 DPI and 150 DPI.

But Xprint operates on printers where the usual minimum resolution is 300 DPI (today's normal office printers support resolutions ranging from 300 DPI up to 2400 DPI depending on the model; most common is 600 DPI). Anti-aliasing at those resolutions is not required anymore. Additionally many printers support their own font anti-aliasing at lower resolutions which is far better and faster than it could be "done" on the client side.

Check whether the ${XPSERVERLIST} env var is set or not. If ${XPSERVERLIST} is set then Xprint is available and should be used.

XXX - xprint.mozdev.org bug 2261 has been filed for that issue.

Lookup-rule for Xprt's PostScript DDX to find fonts:

"DDX" is a short term for "Device Dependent X" - the device-specific layer of a Xserver ("DIX"(="Device Independent X") is the counterpart).

"DIX" is a short term for "Device Independent X" - the non-device specific code of a Xserver ("DDX"(="Device Dependent X") is the counterpart).

"PDL" is a short term for "Page Description Language". Examples for PDLs are PostScript, PCL, PDF and SVGprint.

A Xprt screen does not represent a single printer. A Xprt screen represents a single DDX (currently supported are PostScript, PCL3/5 color, PCL mono and "raster" output(=1bit deep bitmap).

All platforms which support X11 >= R6.4 can use Xprint. The client side (libXp.so) is available on Linux/FreeBSD(=Xfree86), Solaris, HP-UX and AIX and the Xprt server side is available by default on Solaris and HP-UX (Xfree86 shipps with a Xprt binary - but that is broken and unuseable). The client-side extension library (libXp.so) can be compiled on any platform, the Xprt server needs minor adjustments for the specific platforms... If your platform does not have Xprint (client-side and/or server-side) you can get the sources from http://xprint.mozdev.org/.

No, the libXp.so shared library shipped with Xfree86 or build from Xfree86 sources is not broken, only the server side ("Xprt") is buggy. There is no need to replace the library.

"Xprint" is the correct one - "XPrint" is just a typo, "Xprinter" is a complety different product not related to X11/Xprint and "Xprt" is only the "X11 print server"(=the server side of Xprint).

There are various applications which support Xprint:

No, Xprint is a general-purpose print API based on X11 used by many applications - mozdev.org is just one of the hosting places (others are http://xprint.freedesktop.org/ (bugzilla, CVS) and http://www.sourceforge.net/projects/xprint/ (download area)) hosting the development area, documentation and mailinglist. :).

That's the plain "MIT" license, the same as used by Xfree86.org < V4.4.0 and X.org:

Copyright (c) <year> <copyright holders>

Permission is hereby granted, free of charge, to any person obtaining a copy of this software
and associated documentation files (the "Software"), to deal in the Software without
restriction, including without limitation the rights to use, copy, modify, merge, publish,
distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the
Software is furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all copies or
substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM,
DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

Xprint supports multiple "page description languages (PDL)" including PostScript, PDF, PCL, etc. Therefore Xprint uses a different configuration file format which works with all these PDLs and not only PostScript (PPD files are PostScript-specific and cannot be used for other PDLs).

There is currently a converter in development to convert a Adobe PPD file into Xprint's model-config format. See xprint.freedesktop.org bug 636 ("RFE: Add an Adobe PPD to model-config converter / xpppdtomodelconfig") for further information.

There are two env vars which control Xprint on the client side:

The tool "xplsprinters" is designed for that purpose. It can deliver both list of printers and attributes supported for a specific list of printers. Use % xplsprinters -h # to obtain usage information. Example:

"xc/programs/Xserver/Xprint/etc/init.d/xprint" is a script for SystemV and Linux to start/stop/restart Xprt at system startup (e.g. per-machine) or for a single user (e.g. per-user). The script includes installation and usage details.

"xc/programs/Xserver/Xprint/etc/init.d/xprint" is a script for SystemV and Linux to start/stop/restart Xprt at system startup (e.g. per-machine) or for a single user (e.g. per-user). The script includes installation and usage details.

Create your own version/copy of /etc/init.d/xprint and modify it to fit your requirements and then make sure that you issue a "my_xprint_startscript start" before starting the application and a "my_xprint_startscript stop" after leaving the application.

XXX

Access control to Xprt is not differently as to any other Xserver and can be handled in various ways - like per-cookie (using MIT-MAGIC-COOKIE-1 authentification), per-user (using SUN-DES-1 or MIT-KERBEROS-5 auth., see (see xhost(1x))) and/or per-machine (using "xhost" (see xhost(1x)) and/or /etc/X<dpy>.hosts (<dpy> == display number, e.g. /etc/X0.hosts for display 0) (see Xserver(1x))) Consult manual pages Xsecurity(7), xhost(1x), Xserver(1x) etc. for further details.

Logging access to Xprt can be done using the standard Xserver auditing, see the Xserver(1x) manual page, option "-audit"

No, both Xprint clients and Xprint server(s) do not require root rights to work.

Xprint clients are handled like any other X11 application and the Xprt servers can run without any special requirements. Solaris is an exception here since it requires to start any Xserver (incl. Xprt) setgid "root" (set-group-id "root", this is not set-user-id "root") since the sockets/pipe files in /tmp/.X11-pipe/ and /tmp/.X11-unix/ are only accessible for the group "root". The workaround is to start Xprt with the option "-pn"; therefore even Xprt server binaries which are not setgid "root" can run without problems).

"xplsprinters -printer myprinter004 -l" will do the job for printer "myprinter004".

See xplsprinters(1x) for futher usage and a description of the output.

Figure out the display id of the server which should be queried (we are using "foobar:98" in this example) and then try this:

% (DISPLAY=foobar:98 xset q | \
awk "/Font Path:/ { i=1 ; next } i==1 { print \$0 ; i=0 }" | \
tr "," "[\n]")
# Output may look like:
PRINTER:/usr/openwin/server/etc/XpConfig/C/print/models/HPDJ1600C/fonts/
PRINTER:/usr/openwin/server/etc/XpConfig/C/print/models/SPSPARC2/fonts/
PRINTER:/usr/openwin/server/etc/XpConfig/C/print/models/HPLJ3Si-PS/fonts/
/usr/openwin/lib/X11/fonts/F3/
/usr/openwin/lib/X11/fonts/F3bitmaps/
/usr/openwin/lib/X11/fonts/Type1/
/usr/openwin/lib/X11/fonts/Speedo/
/usr/openwin/lib/X11/fonts/misc/
/usr/openwin/lib/X11/fonts/75dpi/
/usr/openwin/lib/X11/fonts/100dpi/

No, this is normal. Xprt will add all fonts of all printer models to the font path - but font path items starting with "PRINTER:" are only available for an application after the matching printer has been selected and configured (for developers: After XpSetContext has been called), before that point fonts in these dirs are not available for an application.

"xp_ps_spooldir_tmp_Xprintjobs" and "xp_pdf_spooldir_tmp_Xprintjobs" ("spooldir_tmp_Xprintjobs" was the old, pre-009 name for "xp_ps_spooldir_tmp_Xprintjobs") are special Xprint printer targets which uses the "PSspooldir" / "PS2PDFspooldir-GS" printer models. These model config sends PostScript or PDF jobs to the /tmp/Xprintjobs/ directory instead to a physical printer (quite usefull for people who want to get the PostScript or PDF files as output instead of printed pages).

References: 

You have to forward the X11 connection for the Xprint server(s) to the remote system and set the XPSERVERLIST variable to direct the Xprint clients to the forwarded ports.

% echo $XPSERVERLIST

west:33

% slogin -R6033:west:6033 -l nrubsig puzzle

nrubsig's password: 
Last login: Fri Jan 23 04:05:06 2004 from west.informatik.med.uni-giessen.de
Have a lot of fun...

% export XPSERVERLIST="localhost:33 ${XPSERVERLIST}"

#!/bin/ksh
# xp_print_slogin_args.ksh
# Small example which parses $XPSERVERLIST and prints out how slogin/ssh
# should be used to forward all local Xprint servers

PORTARGS=""
REMOTE_XPSERVERLIST=""
spacer="" # seperator
remoteport=6100
remotedisplaynum=100

echo "${XPSERVERLIST}" | tr " " "\n" | 
    while read i ; do 
        [ "$i" = "" ] && continue
        displaynum="${i##*:}"
        port="$(( ${displaynum} + 6000 ))"
        hostname="${i%:*}"
        PORTARGS="${PORTARGS}${spacer}-R${remoteport}:${hostname}:${port}"
        REMOTE_XPSERVERLIST="${REMOTE_XPSERVERLIST}${spacer}localhost:${remotedisplaynum}"

        spacer=" "
        remoteport=$((${remoteport} + 1))
        remotedisplaynum=$((${remotedisplaynum} + 1))
    done
echo "Log in with: % slogin ${PORTARGS} -l myloginname myremotehost"
echo "Set remote XPSERVERLIST with % export XPSERVERLIST=\"${REMOTE_XPSERVERLIST} \${XPSERVERLIST}\""
# EOF.

% xp_print_slogin_args.ksh

Log in with: % slogin -R6100:west:6033 -R6101:north:6033 -l myloginname myremotehost
Set remote XPSERVERLIST with % export XPSERVERLIST="localhost:100 localhost:101 ${XPSERVERLIST}"

The env variable ${XPRINTER} defines the default printer used by print applications. The syntax is either <printername> or <printername>@<display>

This is controlled via the "plex" attribute in the document attribute pool (${XPCONFIGDIR}/${LANG}/print/attributes/document and/or ${XPCONFIGDIR}/C/print/attributes/document). Examples:

This is controlled via the "default-medium" attribute in the document attribute pool (${XPCONFIGDIR}/${LANG}/print/attributes/document and/or ${XPCONFIGDIR}/C/print/attributes/document). Examples:

This is controlled via the "default-printer-resolution" attribute in the document attribute pool (${XPCONFIGDIR}/${LANG}/print/attributes/document and/or ${XPCONFIGDIR}/C/print/attributes/document). Examples:

This is controlled via the "content-orientation" attribute in the document attribute pool (${XPCONFIGDIR}/${LANG}/print/attributes/document and/or ${XPCONFIGDIR}/C/print/attributes/document). Examples:

Do not pass any bitmap fonts with the "-fp" (=font path) argument. However you have to provide a 'fixed' and a 'cursor' font, a Xserver can't start without having these fonts.

Add a line with "Augment_Printer_List %none%" to ${XPCONFIGDIR}/C/print/Xprinters (or ${XPCONFIGDIR}/${LANG}/print/Xprinters) and add lines with "Printer <name>" for each printer <name>. Example:

Augment_Printer_List %none%
Printer ps001
Printer ps003
Printer hplaser6

will add only the printers "ps001", ps003" and "hplaser6".

Add "Augment_Printer_List my_script" to ${XPCONFIGDIR}/C/print/Xprinters (or ${XPCONFIGDIR}/${LANG}/print/Xprinters). The script must return the printer names - one per line, ASCII-only - to stdout.

This depends on the OS:

Some sources:

PMF "fonts" are "printer metric files" (.pmf) that describe the metrics of the fonts (which means they do not contain any data to render the fonts - they contain only the plain metrics of a font) which are built into the printer (ROM or via font catridge etc.). The file format is identical to the PCF ("Portable Compiled Format") font format except that the bitmap data is not provided.

You can use Xprt with the font server ("xfs") like with any other Xserver - but it is not recommded since the font server protocol does not allow access to the native font format and therefore disables font download, e.g. both PS Type1 and TrueType fonts cannot be downloaded anymore and Xprt will fall-back to embed them as bitmap glyphs in the print job (e.g. the fonts will still appear correctly in the printout, but the quality may be reduced since downloaded fonts are always better than bitmap glyphs). (users of xprint.mozdev.org-release <= 006 may see xprint.mozdev.org bug 2092 if they use "xfs"; this has been fixed in the 007 release!)

The term "model-config" refers to the subdirs in ${XPCONFIGDIR}/${LANG}/print/models/. There subdirs contain information about the attributes for a specific printer model or family/class of printer models. In particular there are two kinds of information:

XXX

XXX

XXX - no solution yet, but xprint.mozdev.org bug 2430 ("RFE: Need tool to create PMF (printer metrics file) fonts") has been filed to create a freeware tool to create such fonts.

If you miss a model-config for your printer please open a bug/RFE at http://xprint.freedesktop.org/bugzilla/enter_bug.cgi?product=xprint&component=Server%3A%20Config%3A%20model-configs (e.g. http://xprint.freedesktop.org/bugzilla/enter_bug.cgi, product "Xprint", component "Server: Config: model-configs").

This is platform-specific, based on the "XPrintDir" Imake variable set at build time. Default location for plain X11R6.x is "${XProjectRoot}/lib/X11/xserver" (set at build time), but some platforms modify "XPrintDir" to alternate locations:

  strings -a /usr/openwin/bin/Xprt | grep XPRINTDIR

The PMF fonts are a variant of the PCF font format, they are (like the PCF format) architecture-independent. These fonts must be kept together with the other model config data since they depend on the printer model (de facto ${XPCONFIGDIR}/C/print/models/ (and/or ${XPCONFIGDIR}/${LANG}/print/models/) should be supplied by the printer vendors (but most people will create their own models on demand since I doubt that any vendor except HP, Sun and xprint.mozdev.org staff ever looked at that stuff)). Per definition they are read-only data supplied by the vendor, but modifying them may be usefull, too. I would say it is recommended to put treat all Xprint files in ${XPCONFIGDIR} as read-only vendor data; admins should create copies of this tree on demand (and/or (soft-)link some files) and set ${XPCONFIGDIR} to the modified config data.

Yes, Xprt supports localisation ("l10n") by default. Default values for all locales are stored in ${XPCONFIGDIR}/C/print/, locale-specific settings can be set in ${XPCONFIGDIR}/${LANG}/print/ Rules: