] >
Xprint Frequently Asked Questions About this FAQ Archive-name: Xprint/FAQ Version: 0.9.1 Last-Modified: 2004/06/14 08:15:16 Maintained-by: Roland Mainz roland.mainz@nrubsig.org The following is a list of questions that are frequently asked about Xprint. You can help make it an even better-quality FAQ by writing a short contribution or update and sending it BY EMAIL ONLY to me. A contribution should consist of a question and an answer, and increasing number of people sends me contributions of the form "I don't know the answer to this, but it must be a FAQ, please answer it for me". Please read the FAQ first (including the item "Getting Help") and then feel free to ask me if it is not in the FAQ. Thanks! The latest Xprint FAQ and some other goodies can be obtained through http from http://xprint.freedesktop.org/cgi-bin/viewcvs.cgi/*checkout*/xorg/xc/doc/hardcopy/XPRINT/Xprint_FAQ.html or http://xprint.freedesktop.org/cgi-bin/viewcvs.cgi/*checkout*/xorg/xc/doc/hardcopy/XPRINT/Xprint_FAQ.txt (the DocBook/XML master source file is http://xprint.freedesktop.org/cgi-bin/viewcvs.cgi/xorg/xc/doc/hardcopy/XPRINT/Xprint_FAQ.xml ). Note that the FAQ has not been finished yet (nor is it half-finished...), many items marked with "XXX" as the answer have still to be written (or have to be copy&pasted from my item collection... :) Frequently Asked Questions with Answers General What is "Xprint" ? 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... Where can I get Xprint/Xprt from ? Xprint is client-server based, therefore two answers: The server side is available by default on Solaris (see Note below) and HP-UX (Xfree86 ships a "Xprt" binary, but that is broken and the server config files are missing, too). For those platforms who do not have a (working) Xprt server the you can get source, binary tarballs and Linux RPMs from http://xprint.mozdev.org/, Debian Linux has a package based on the same sources (see http://packages.qa.debian.org/x/xprint-xprintorg.html). For Solaris >= 2.7 http://xprint.mozdev.org/ provides the "GISWxprintglue" and "GISWxprint" packages (available from http://xprint.mozdev.org/download.html) which provides a single-step drop-in way to configure and start Xprint at system startup and/or per-user for all applications and users (the package provides only startup scripts and some config data and uses the Xprt binary provided with Solaris (/usr/openwin/bin/Xprt)). The client-side Xprint support library (libXp.so) is available on all X11 platforms >=R6.4, including Linux, Solaris, HP-UX, AIX, FreeBSD, NetBSD, etc. If you do not have it you can build it from the sources available at http://xprint.mozdev.org/. What is "Xprt" ? 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.). Where can I get help for problems with Xprint ? 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. "Why do some people like Xprint ?" / "What are the advantages of Xprint ?" Xprint allows an application to query what features (paper size, trays, orientation, resolutions, plexes, fonts and much more) a printer supports. For example it is avoidable that a user accidently prints DIN-A4 on a DIN-A0 poster printer (the print dialog would only offer DIN-A0 as paper size, e.g. offers only choices which are valid for this printer). Server-side, localizeable configuration - changes to the server config apply to all users without the need to change/updating anything on the user side (the user may still start his/her own Xprt instance using his/her preferred configuration). Small footprint - ideal for for mobile devices (client side does not need to process any fonts - that's the job of the server side). API not restriced to PostScript (X11R6.5.1 comes with PCL and Raster implementations - and PDF/G3-FAX/SVG would be possible without problems). Scaleable - Xprint can use as many Xprt servers as the user/admin wants. "Xprint is designed for the enterprise", e.g. Xprint was designed to match the needs of large company networks. Automatic font handling - font download or the existence of printer-builtin fonts is automagically handled by Xprt - the application does not need to know/handle any details (but the application can optionally get information and control the usage of printer builtin fonts). You can print anything what you can render on the framebuffer(=video card) Xserver. Existing code can be reused 1:1 for printing - which means reduced development costs. Easy support for I18N (internationalization) - you simply render any fonts in any language with Xprint. Network-transparent design - Client can use local or remote Xprt servers like any other Xserver. Uses the X11 protocol - easy adoption of existing code to implement printer support. And all the network goodies like firewall proxies, compressors etc. can be used for Xprint without modifications. Security: Xprint can use all authentification schemes available in X11 (like Kerberos5, SecureRPC, MIT-MAGIC-COOKIE or host-based authentification). Enhachements on the server side (Xprt) to not require the change of client-side code. Optimized job output (like the PostScript created by the PostScript DDX) is usually a lot smaller than the PS code created by other PostScript engines. Why do some people dislike Xprint ? There are a few common misconceptions about Xprint. Let's take a look some of these "myths", some background - and the facts:
Xprint prints just a XWD dump of the Xserver bitmap Whoever says Xprint simply does an "xwd"-like dump is wrong. In short, Xprint currently (X11R6.5.1) supports *four* drivers: X to native Postscript X to native PCL5 X to native PCL3 X to a raster which is then feed to something like xpr to create PS or PCL5 wrapped rasters. In long, the original X Print Service ("XPS") was attempted during CDE 1.0, and they only got so far as the "raster" driver. As CDE 2.0 came around, Bob Schiefler and others at the X Consortium agreed that the X Consortium would work on a X to native PS Level 2 driver and HP would work on a X to native PCL5 driver. It was probably the CDE 1.0 effect that left many people with the impression that Xprint is all about xwd-like window dumps. NO! Xprint has native PostScript and PCL5 printing and more drivers (like PDF and SVGprint DDXs etc.) are in the development. Xprint cannot handle non-'ISO Latin 1' chars Xprint can print any chars incl. those required for MathML, Hebrew, Arabic, Japanese etc. etc. For example - the Xprint module for Mozilla5 is the only print module which can proprtly print MathML. Xprint uses a 1024x768 screen resolution to render the stuff on the paper - therefore it will never be able to do high-resolution stuff Xprt uses the screen resolution requested by the application or the printers default resolution. For example a 300 DPI printer which supports paper sizes up to DIN-A4 will get a screen with 3300x3300 pixels (screen width and height are usually equal to support per-page changes in the orientation (potrait/landscape etc.), the window size would be 2400x3149 for "portrait" orientation) - and larger resolutions will result in larger screens. Xprint prints only graphics(=bitmap/gfx) fonts In short, Xprt supports printer-builtin fonts and can download fonts to the printer if they do not exist on the printer. In long, this myth seems to have it's root in a feature of Xprt which can - if Xprt gets misconfigured - disable the use of printer-builtin fonts and the ability to download fonts. Xprt's PostScript and PCL DDX have the unique feature to create font glyphs from bitmap fonts if they are not available as printer-builtin fonts nor as outline fonts (OpenType, TrueType, PS Type1, etc.). However this is the fallback - the last option used by Xprt. Used if everything else fails. But when someone does not pass any outline fonts (such as OpenType, TrueType or PS Type1) fonts with the font path nor configures a printer model-config (which contains a description of the features&fonts supported by the printer) Xprt will never have a chance to use them. And if everything else fails it has no other option than using what has been left - the bitmap fonts... Xprint does not support pages sizes larger than DIN-A4 There is no such limitation. The only limit is the 16bit coordinate system of the X11 protocol - which is large enougth that Xprint can support paper sizes larger than DIN-A0 oversize papers. There is no problem with creating your own monster-size DIN-A0 posters using Xprint-based applications. Xprint does not support rotated text Xprint and all it's drivers support the X11 matrix XLFD enhancement introduced in X11R6 (and future versions of Xprint will support the STSF font API which supports matrix transformations as well). Fonts can be rotated at any angle. Take a look at the SOFTWARE DEVELOPMENT section in this FAQ for examples... The X11 rendering model is not good enougth for printers The default Xprint rendering model uses the X11 rendering model - which is "limited"... but only when compared with PostScript. But the attempt to compare Xprint with PostScript is like comparing apples and eggs - they have been designed with different goals in mind - PostScript as plain rendering language for printers and Xprint as integrated all-in-one solution to allow applications to print without having special knowledge about the OS, spooler, PDL or printer. Around 95% of the applications which have print support do not use any of the special features provided by rendering models like PostScript. Xprint does not require that an application uses the X11 rendering model - they are free to generate their own PostScript code or PostScript fragments and pass it to the printer via the Xprint API or use the OpenGL rendering model via the GLX extension available in newer versions of the Xprint server. Printing from Mozilla, Motif or the Qt toolkit using Xprint results in a much better quality than using the "native" PostScript generation code in those applications. Xprint supports more PDLs than PostScript - having a PostScript-specific rendering model would be limiting, and make it difficult to support other PDLs.
Does Xprint support anti-aliased fonts ? 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. How can I check if Xprint is working and should be used ? Check whether the ${XPSERVERLIST} env var is set or not. If ${XPSERVERLIST} is set then Xprint is available and should be used. How can I view PS(=PostScript) files ? On Unix/Linux (general): GhostScript ("gs") and GhostView ("gv" and it's KDE- and Gnome-specific versions "kghostview" and "ggv") Solaris: /usr/dt/bin/sdtimage (DPS-based image viewer for CDE) /usr/openwin/bin/pageview (DPS-based image viewer for OpenWindows) How can I view PCL files ? XXX - xprint.mozdev.org bug 2261 has been filed for that issue. How does Xprt find fonts ? Lookup-rule for Xprt's PostScript DDX to find fonts: Printer-builtin fonts (defined by the fonts/-dir in the model-config) PostScript fonts (will be downloaded via generated print job) GFX-fonts build from X11 scaleable fonts GFX-fonts build from X11 bitmap fonts How can I print TrueType fonts with Xprint ? Linux Xprt build from http://xprint.mozdev.org/'s source supports TrueType fonts out-of-the-box (starting with the 008 development tree; xprint.mozdev.org's releases <= 007 do not support TrueType fonts) and and does not require any special actions. Sun's Xprt on Solaris (/usr/openwin/bin/Xprt) has TrueType font support out-of-the-box and does not require any special actions. You can setup a TTF-aware X font server ("xfs", see xfs__mansuffix__) with the matching TrueType fonts and add the font server location to Xprt's font path. Sourceforge has a TrueType to PostScript Type 1 converter project, see http://ttf2pt1.sourceforge.net/download.html. You may convert the TTF files into PT1 files that Xprt can download them to the printer on demand... What does "DDX" mean ? "DDX" is a short term for "Device Dependent X" - the device-specific layer of a Xserver ("DIX"(="Device Independent X") is the counterpart). What does "DIX" mean ? "DIX" is a short term for "Device Independent X" - the non-device specific code of a Xserver ("DDX"(="Device Dependent X") is the counterpart). What does "PDL" mean ? "PDL" is a short term for "Page Description Language". Examples for PDLs are PostScript, PCL, PDF and SVGprint. I have twenty printers installed on my system - but Xprt only shows two screens. Where are all the other printers ? 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). Which platforms support Xprint ? 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/. I have the broken Xfree86 Xprt binary on my system. Do I need a new version of libXp.so (the client side X11 extension library for Xprint), too ? 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. Which spelling is correct - "Xprint", "XPrint", "Xprinter" or Xprt" ? "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). Which applications support Xprint ? There are various applications which support Xprint: Motif/LessTif toolkits (full framework incl. special widgets like XmPrintShell) Athena toolkit (full framework incl. special widgets like XawPrintShell, starting with X.org release 6.7.1) Xedit, Xman, Xmore, etc. (starting with X.org release 6.7.1) Common Desktop Environment (CDE) 2.x Mozilla, FireFox, ThunderBird, etc. Eclipse KDE/Qt support is planned for Q3/2004 StarOffice 5.x etc. Is "Xprint" "mozilla"-only (I saw that it's hosted by mozdev.org) ? 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. :). Under which license is the source code from xprint.mozdev.org distributed under ? 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. Why does Xprint not use PPDs for configuration ? 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. Usage How do I configure Xprint on the client side ? There are two env vars which control Xprint on the client side: The env variable ${XPSERVERLIST} contains a list of display identifiers (seperated by whitespace) to tell the application where it can find the Xprt servers. Usually ${XPSERVERLIST} is set by the profile startup scripts (e.g. /etc/profile or /etc/profile.d/xprint.sh) using the output of "/etc/init.d/xprint get_xpserverlist". Example: % export XPSERVERLIST="`/etc/init.d/xprint get_xpserverlist`" Alternativly ${XPSERVERLIST} can be set manually: Example: % export XPSERVERLIST="littlecat:80 bitdog:72" instructs an application to look at the displays 80 on the machine "littlecat" and display 72 on the machine bigdog to look for Xprt servers. The env variable ${XPRINTER} defines the default printer used by print applications. The details can be found in the FAQ item How do I change the default printer used by Xprint applications ? ... How do I start Xprt ? Linux RPM installations on Mandrake/RedHat/SuSE Linux: Binary RPM packages provided by xprint.mozdev.org (or based on the same source :) will install /etc/init.d/xprint and related glue (see [4]) automatically; after a reboot a Xprt instance will be started at system startup and ${XPSERVERLIST} should be populated for all users. Note that you can start/stop per-user instances using /etc/init.d/xprint (see [4]), too... Debian Linux: Same as [1], however Debian does not support /etc/profile.d/ - you have to add the following line to /etc/profile (for sh/ksh/bash) to populate ${XPSERVERLIST}: export XPSERVERLIST="`/bin/sh /etc/init.d/xprint get_xpserverlist`" See bugs.debian.org bug 171174 ('"xprint-xprintorg" should automatically populate $XPSERVERLIST') for further details on this issue... Solaris using the "GISWxprintglue" package: http://xprint.mozdev.org/ provides a Solaris package called "GISWxprintglue" which contains all the neccesary configuration files and startup scripts to use Xprint; after a reboot a Xprt instance will be started at system startup and ${XPSERVERLIST} should be populated for all users. Note that you can start/stop per-user instances using /etc/init.d/xprint (see [4]), too... Solaris using the "GISWxprint" package: http://xprint.mozdev.org/ provides a Solaris package called "GISWxprint" which is technically identical to the "GISWxprintglue" (see [3a]) but provides a Xprt binary build from the xprint.mozdve.org sources ("GISWxprintglue" uses the /usr/openwin/bin/Xprt binary provided by Solaris). General: Using /etc/init.d/xprint and related glue: There are startup/shutdown scripts in xc/programs/Xserver/Xprint/etc/ to start/stop/restart Xprt per-machine and/or per-user and to populate the ${XPSERVERLIST} env var: "xc/programs/Xserver/Xprint/etc/init.d/xprint" is a script for SystemV and Linux to start/stop/restart Xprt. The script includes installation and usage details and can be used by both "root" (to start Xprt for all users) or by a single (non-priviledged, plain) user (to start Xprt instances only for his/her own use) "xc/programs/Xserver/Xprint/etc/profile.d/xprint.csh" and "xc/programs/Xserver/Xprint/etc/profile.d/xprint.sh" are scripts for Linux (which support /etc/profile.d/ ; note that this does not include Debian) to populate the ${XPSERVERLIST} env var for each user. Starting Xprt "manually" (without using /etc/init.d/xprint): Set the ${XPCONFIGDIR} env variable to the directory where Xprt can find it's configuration data. WARNING If Xprt cannot find it's configuration data it will not be able to use printer-builtin fonts (which are defined by the model-config in the configuration dir). Without printer-builtin fonts Xprt may fall back to generate font glyphs from bitmap fonts (this resulted in the MYTH that "Xprt can only print gfx fonts". This is not TRUE - this only happens if Xprt is either misconfigured or no matching builtin or PS Type1 font is available). You may want to make a copy of the default configuration directory and modify it to match your needs. Starting Xprt is just as easy as starting any other Xserver: % Xprt :12 will start Xprt on display 12 (e.g. set ${XPSERVERLIST} to ":12" or "myhostname:12". You may want to copy your framebuffer Xserver's font path to be able to print all fonts which can be displayed on that Xserver. % Xprt -fp $(xset q | awk "/Font Path:/ { i=1 ; next } i==1 { print \$0 ; i=0 }") :12 Notes: The /etc/init.d/xprint has a more advanched filtering scheme based on regex patters to "accept" and/or "reject" font paths 'xset q | awk "/Font Path:/ { i=1 ; next } i==1 { print \$0 ; i=0 }"' may be too simple-minded if your Xserver does not support TrueType fonts. The following statemement is better in this case since it filters the font path and removes all path elements which have TrueType fonts (*.ttf, *.TTF) or TrueType font collections (*.ttc, *.TTC) in fonts.dir: % xset q | awk "/Font Path:/ { i=1 ; next } i==1 { print \$0 ; i=0 }" | tr "," "\n" | while read i ; do \ if [ "$(cat ${i}/fonts.dir | egrep -i "ttf|ttc" 2>/dev/null)" == "" ] \ ; then echo $i ; fi ; done | (fontpath="" ; fpdelim=""; while read i ; \ do fontpath=${fontpath}${fpdelim}${i} ; fpdelim="," ; done ; echo \ $fontpath) It may be easier to just feed all available font paths to Xprt (BTW: mozilla 1.0 had a bug in that case which resulted in the problem that it used many many bitmap fonts in that case - this has been fixed for 1.0.1 and Netscape 7 (that's the reason why the quickguides for hebrew/cyrillic use the "Xp_dummyfonts" fonts instead of /usr/openwin/lib/X11/fonts/misc/ - to avoid that Mozilla finds bitmap fonts for the same locale). The following "small" one-liner finds all fonts (except printer builtin fonts): % find /usr/openwin -name fonts.dir | while read i ; do echo ${i%/fonts.dir} ; done | fgrep -v "models/" Plug it into the filter above to remove the Truetype fonts and you are "done"... :) See TROUBLESHOOTING if you run into problems... How can I get a list of printers managed by Xprint ? 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: Get list of available printers: % xplsprinters printer: hplaserjet001@castor:19 printer: hpcolor001@castor:19 printer: laser1@jason:5 printer: david_dj01@jason:5 Get information about the supported attrbites of printer "ps002": % xplsprinters -printer ps002 -l printer: ps002@castor:18 description= model-identifier=HPDJ1600C default-medium=iso-a4 default-input-tray= medium-source-sizes-supported=iso-a4 false 6.35 203.65 6.35 290.65 medium-source-sizes-supported=na-letter false 6.35 209.55 6.35 273.05 default-printer-resolution=300 resolution=300 default_orientation= orientation=portrait orientation=landscape default_plex= plex=simplex How can I start Xprt at boot time ? "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. How can I start Xprt per-user ? "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. How can I start Xprt only for one application ? 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. How can I filter the font path which should be passed to Xprt for certain fonts ? XXX How can I manage access control to the Xprt server ? 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__mansuffix__)) and/or per-machine (using "xhost" (see xhost__mansuffix__) and/or /etc/X<dpy>.hosts (<dpy> == display number, e.g. /etc/X0.hosts for display 0) (see Xserver__mansuffix__)) Consult manual pages Xsecurity__miscmansuffix__, xhost__mansuffix__, Xserver__mansuffix__ etc. for further details. How can I log access to the Xprt server ? Logging access to Xprt can be done using the standard Xserver auditing, see the Xserver__mansuffix__ manual page, option "-audit" Does it require "root" permissions to use Xprt/Xprint ? 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). How can I see the attributes of a printer managed by Xprint ? "xplsprinters -printer myprinter004 -l" will do the job for printer "myprinter004". See xplsprinters__mansuffix__ for futher usage and a description of the output. How can I list the font path used by a Xprt server ? 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/ Note: Note that the font path items which start with "PRINTER:" are only be sourced after the matching printer has been selected and configured (for developers: After XpSetContext has been called). "xset q" lists all model-specific font dirs (like PRINTER:/myxpcfg/C/print/models/SPSPARC2/fonts/") - is that a bug ? 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. My application lists a printer called "xp_ps_spooldir_tmp_Xprintjobs" / "xp_pdf_spooldir_tmp_Xprintjobs" / "spooldir_tmp_Xprintjobs" / in the print dialog but I do not have such a print queue installed anywhere. What is that for a thing ?! "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: xprint.mozdev.org bug 5092 ("[PS2PDFspooldir-GS] RFE: Add printer model which sends PDF jobs to /tmp/Xprintjobs/") How can I forward Xprint services when logging-in via ssh to another machine ? 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. Login to a remote host using slogin (assuming there is only one Xprint server listed in <envar>XPSERVERLIST</envar>) % echo $XPSERVERLIST west:33 Add 6000 to the display number ("33" in this example) to get the port number (X11 port numbers start at port 6000. 6000 is display number "0", 6001 is display number 6001 and so on) and then ask slogin to forward the port: % 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... Then set the XPSERVERLIST env var on the remote host to the forwarded ports and you are done: % export XPSERVERLIST="localhost:33 ${XPSERVERLIST}" Login to a remote host using slogin (assuming there are multiple Xprint servers listed in <envar>XPSERVERLIST</envar>) The following small shell script will process the XPSERVERLIST env var and output the parameters for calling slogin/ssh with all Xprint server ports forwarded: #!/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. Example usage: % xp_print_slogin_args.ksh will print Log in with: % slogin -R6100:west:6033 -R6101:north:6033 -l myloginname myremotehost Set remote XPSERVERLIST with % export XPSERVERLIST="localhost:100 localhost:101 ${XPSERVERLIST}" Configuration How do I change the default printer used by Xprint applications ? The env variable ${XPRINTER} defines the default printer used by print applications. The syntax is either <printername> or <printername>@<display> Examples: % export XPRINTER=ps003 tells an application to look for the first printer named "ps003" on all Xprt servers. % export XPRINTER="hplaser19@littlecat:80" tells an application to look for the printer "hplaser19" on the Xprt display "littlecat:80". Note: If ${XPRINTER} is not set the applications will examine the values of the ${PDPRINTER}, ${LPDEST}, and ${PRINTER} env vars (in that order). How do I change the defaults for double-sided/single-sided/etc. printing ? 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: Adding/modifying the following line to/in ${XPCONFIGDIR}/C/print/attributes/document sets the default plex for all printers to "duplex": *plex: duplex Adding/modifying the following two lines to/in ${XPCONFIGDIR}/C/print/attributes/document sets the default plex for all printers to "duplex" except for printer "ps003" which should default to "simplex": *plex: duplex ps003.plex: simplex Notes: Not all printers support all plex modes. The model-config may restrict the available plex modes. Setting a plex mode which is not supported by either the DDX(=driver) or not specified in the model-config will cause Xprt to not set a default plex. The PostScript DDX supports plex modes "simplex", "duplex" and "tumble". Verification: Use xplsprinters -l | egrep "^printer:|default_plex=|plex=" to view the plex settings for all printers. I am in America and I don't have any ISO A4 paper. How do I change the default paper size to 8.5 inch x 11 inch (US-Letter) ? 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: Adding/modifying the following line to/in ${XPCONFIGDIR}/C/print/attributes/document sets the default paper size for all printers to "na-letter": *default-medium: na-letter Adding/modifying the following two lines to/in ${XPCONFIGDIR}/C/print/attributes/document sets the default paper size for all printers to "na-letter" except for printer "ps003" which should default to "iso-a4": *default-medium: na-letter ps003.default-medium: iso-a4 Notes: xprint.mozdev.org releases >= 007 provides a seperate "document" attribute pool for en_US(-like) locales (see ${XPCONFIGDIR}/en_US/print/attributes/document) which will override the default ISO-A4 with US-Letter (this feature assumes that ${LANG} is set to "en_US" (or a locale which has similar defaults as "en_US", those are currently linked to "en_US" in ${XPCONFIGDIR}/)) Not all printers support all paper sizes. The model-config may restrict the available paper sizes. Setting a paper size which is not supported by either the DDX(=driver) or not specified in the model-config will cause Xprt to not set a default paper size. The PostScript DDX supports the following paper sizes: X.org release 6.6 (X116.6): "iso-a4" "na-letter" "na-legal" "executive" "iso-designated-long" "na-number-10-envelope" xprint.mozdev.org release >= 006: "na-letter" "na-legal" "executive" "folio" "invoice" "ledger" "quarto" "a" "b" "c" "d" "e" "na-6x9-envelope" "na-10x15-envelope" "monarch-envelope" "na-10x13-envelope" "na-9x12-envelope" "na-number-10-envelope" "na-7x9-envelope" "na-9x11-envelope" "na-10x14-envelope" "na-number-9-envelope" "iso-a0" "iso-a1" "iso-a2" "iso-a3" "iso-a4" "iso-a5" "iso-a6" "iso-a7" "iso-a8" "iso-a9" "iso-a10" "iso-b1" "iso-b2" "iso-b3" "iso-b4" "iso-b5" "iso-b6" "iso-b7" "iso-b8" "iso-b9" "iso-b10" "jis-b1" "jis-b2" "jis-b3" "jis-b4" "jis-b5" "jis-b6" "jis-b7" "jis-b8" "jis-b9" "jis-b10" "iso-c3" "iso-c4" "iso-c5" "iso-c6" "iso-designated-long" Verification: Use xplsprinters -l | egrep "^printer:|default-medium=|medium-source-sizes-supported=" to view the medium settings for all printers. The 'medium-source-sizes-supported='-lines have the format XXX. How do I change the default printer resolution ? 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: Adding/modifying the following line to/in ${XPCONFIGDIR}/C/print/attributes/document sets the default resolution for all printers to 600 DPI: *default-printer-resolution: 600 Adding/modifying the following two lines to/in ${XPCONFIGDIR}/C/print/attributes/document sets the default resolution for all printers to 300 DPI except for printer "tekcolor_ps" which should default to 1200 DPI: *default-printer-resolution: 300 tekcolor_ps.default-printer-resolution: 1200 Notes: Not all printers support all resolutions. The model-config may restrict the available resolutions. Setting a resolution which is not supported by either the DDX(=driver) or not specified in the model-config will cause Xprt to not set a default resolution. The PostScript DDX supports the following default resolutions X.org release 6.6 (X116.6): 300 600 720 940 1200 1440 2400 xprint.mozdev.org release >= 006: 75 100 120 150 180 200 240 300 360 400 600 720 940 1200 1440 2400 Verification: Use xplsprinters -l | egrep "^printer:|default-printer-resolution=|resolution=" to view the resolution settings for all printers. How do I change the default settings for "portrait"/"landscape"/"seascape" (=page orientation) ? 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: Adding/modifying the following line to/in ${XPCONFIGDIR}/C/print/attributes/document sets the default orientation for all printers to "portrait": *content-orientation: portrait Adding/modifying the following two lines to/in ${XPCONFIGDIR}/C/print/attributes/document sets the default orientation for all printers to "portrait" except for printer "ps003" which should default to "landscape": *content-orientation: portrait ps003.content-orientation: landscape Notes: Not all printers support all orientations. The model-config may restrict the available orientations. Setting an orientation which is not supported by either the DDX(=driver) or not specified in the model-config will cause Xprt to not set a default orientation. The PostScript DDX supports the following orientations: "portrait", "landscape", "reverse-portrait" and "reverse-landscape". Verification: Use xplsprinters -l | egrep "^printer:|default_orientation=|orientation=" to view the orientation settings for all printers. How can I prevent Xprt from using any bitmap(=gfx) fonts ? 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.
Task list: Create a new directory: % mkdir Xp_dummyfonts % cd Xp_dummyfonts Create a fonts.alias file with the following content: ! alias for "fixed" font ! original from /usr/openwin/lib/X11/fonts/misc/fonts.alias looks like this: ! fixed "-misc-fixed-medium-r-semicondensed--13-120-75-75-c-60-iso8859-1" fixed -*-r-*--*-*-*-*-*-*-iso8859-1 ! EOF. Copy or link "6x13.pcf.Z" and "cursor.pcf.Z" and create fonts.dir % ln -s /usr/openwin/lib/X11/fonts/misc/6x13.pcf.Z . % ln -s /usr/openwin/lib/X11/fonts/misc/cursor.pcf.Z . % mkfontdir $PWD Verify: The directory should now look like this: % ls -1 6x13.pcf.Z cursor.pcf.Z fonts.alias fonts.dir Add the full path (e.g. /home/xp/Xp_dummyfonts) as last element of the font path when starting Xprt: % Xprt -fp /usr/openwin/lib/X11/fonts/Type1/,/home/xp/Xp_dummyfonts :12
I want only my manually added printers managed by Xprint. How can I prevent Xprt from looking-up the printer names automatically ? 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". How can I specify an own program/script to enumerate the printers on my system ? 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. Which program is used by default by Xprt to enumerate the printers on my system ? This depends on the OS: On Solaris (and most other OSes exclusing AIX and Linux): % lpstat -a | cut -d " " -f 1 On Linux: For Xprt build from X11R6.x X.org sources: % lpc status | grep -v '^\t' | sed -e /:/s/// # '\t' means TAB For Xprt build from xprint.mozdev.org <= release 008 sources (both lines are executed to support both LPRng and CUPS (using the CUPS *BSD compatibility tools)): % lpc status | awk '/:$/ && !/@/ { print $1 }' | sed -e /:/s/// ; \ lpc -a status | awk '/@/ && !/:/ { split( $1, name, \"@\" ); print name[1]; }' Xprt build from xprint.mozdev.org >= release 009 sources uses a more flexible scheme which tries to enumerate the print spoolers in the order "CUPS" (using the normal CUPS (SYSV-like) commands), "LPRng" and finally "*BSD", the first working (=print queues are found) print spooler is chosen. The spooler(s) being used (and the query order) can be changed by the "-XpSpoolerType" command line option. The list of commands used to enumerate the queues for a specific spooler type can be found in xc/programs/Xserver/Xprint/spooler.c On AIX v4: % lsallq | grep -v '^bsh$' Notes: See xc/programs/Xserver/Xprint/Init.c (xprint.mozdev.org >= release 009 uses xc/programs/Xserver/Xprint/spooler.c) for a complete list of commands used on the specific platforms to enumerate the printers. Note that the output is always piped through "sort" to get an alphabetical order (the "default" printer is not chosen/defined here(=server side), the client side is responsible to choose a default printer. See FAQ item about the ${XPRINTER} env var how to set your default printer). Where can I get more PostScript Type1 fonts from ? Some sources: Adobe: Commercial fonts: http://www.adobe.com/type/main.html Free Euro font: Single-glyph (e.g. it contains only the euro char) euro font: http://www.adobe.com/type/eurofont.html or ftp://ftp.adobe.com/pub/adobe/type/win/all/ ("eurofont.exe" can be unzipped using "unzip") ISO8859-15: XXX - WANTED!! Solaris shipps with various PS Type 1 fonts: Arabic: /usr/openwin/lib/locale/ar/X11/fonts/Type1/ (fonts.dir and fonts.scale missing, maybe they miss the presentation forms a&b, too [unconfirmed]) ISO-8859-13 (Latin 8): /usr/openwin/lib/locale/iso_8859_13/X11/fonts/Type1/ ISO-8859-5 (Latin 5): /usr/openwin/lib/locale/iso_8859_9/X11/fonts/Type1/ ISO-8859-8/Hebrew: /usr/openwin/lib/locale/iso_8859_8/X11/fonts/Type1 (BROKEN, even "type1fix" cannot fix them. Use the hebrew fonts from broken-link-/PS_Type1_iso8859-8.tar.gz) ISO-8859-7/Modern greek: /usr/openwin/lib/locale/iso_8859_7/X11/fonts/Type1/ ISO-8859-5/Cryrillic: /usr/openwin/lib/locale/iso_8859_5/X11/fonts/Type1/ ISO-8859-4 (Latin 4): /usr/openwin/lib/locale/iso_8859_4/X11/fonts/Type1/ ISO-8859-2 (Latin 2): /usr/openwin/lib/locale/iso_8859_2/X11/fonts/Type1/ ISO-8859-1 (Latin 1) and Symbol fonts: /usr/openwin/lib/X11/fonts/Type1/ What are PMF fonts (e.g. the *.pmf fonts in ${XPCONFIGDIR}/C/print/models/%model_name%/fonts/ (or ${XPCONFIGDIR}/${LANG}/print/models/%model_name%/fonts/)) ? 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. Can I use the fontserver ("xfs") with Xprt ? 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!) What is a "model-config" ? 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: "${XPCONFIGDIR}/${LANG}/print/models/${NAME_OF_MODEL}/model-config" this file defines a set of attributes supported by this specific printer (-family/-class/etc.) and "${XPCONFIGDIR}/${LANG}/print/models/${NAME_OF_MODEL}/fonts/" - a directory which contains a set of PMF (printer metrics file) fonts builtin into the printer itself (actually the PMF "font" format contains only metrics information and no glyphs). These fonts are only available to the application after the application has selected a printer and configured it (for developers: After XpSetContext has been called). Where can I store the default values for printers ? XXX How can I create my own model-config ? XXX How can I create my own PMF "fonts" ? 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. Where can I get more model-configs from ? 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"). If I install Xprt &co. as "root" in the default location and don't need to set ${XPCONFIGDIR} - where are my configuration files located then ? 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: Solaris sets ${XPCONFIGDIR} to /usr/openwin/server/etc/XpConfig/ Linux (non-Debian) sets ${XPCONFIGDIR} to /usr/X11R6/lib/X11/xserver/ or /etc/X11/xserver/ Debian Linux sets ${XPCONFIGDIR} to /usr/share/Xprint/xserver/ If you don't know where the default location for ${XPCONFIGDIR} is located try strings -a /usr/openwin/bin/Xprt | grep XPRINTDIR - it may return some debug info from the binary containing the builtin XpConfig path. Are config files and/or the PMF fonts architecture dependent ? 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. Can I localise my Xprint/Xprt configuration (l10n) ? 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: Attribute pools ("${XPCONFIGDIR}/*/print/attributes/document", "${XPCONFIGDIR}/*/print/attributes/job", "${XPCONFIGDIR}/*/print/attributes/printer" and "${XPCONFIGDIR}/*/print/models/*/model-config"): "document", "job" and "printer" attribute pools and printer model-configs are sourced first from the "${XPCONFIGDIR}/C/print/"-directory, then they are overridden by any attributes from the locale-specific pools (in "${XPCONFIGDIR}/${LANG}/print/"), e.g. any values set in "${XPCONFIGDIR}/C/print/attributes/*" and "${XPCONFIGDIR}/C/print/models/*/model-config" will automatically apply to all other locales unless they are overridden by locale-specific versions of these files ("${XPCONFIGDIR}/${LANG}/print/attributes/*", "${XPCONFIGDIR}/${LANG}/print/models/*/model-config") "Xprinters" (list of printers): If there is a locale-specific ${XPCONFIGDIR}/${LANG}/Xprinters present it will be used instead of ${XPCONFIGDIR}/C/Xprinters (e.g. values set in ${XPCONFIGDIR}/C/Xprinters will be ignored and the values from ${XPCONFIGDIR}/${LANG}/Xprinters will be used instead). Xprt will determinate the locale which should be used based on the ${LANG}-environment vaiable at startup time. If there is no such variable set at that time LANG="C" is assumed. Note: Attribute values for paper names and orientation names refer to builtin strings in the DDX code (which are itself based on international standards), these cannot be changed to your own "inventions" (it does it make sense to try to "localize" paper names - "ISO-A4" is "ISO-A4" even in japanese/hebrew/german etc.). Locale-spefific attribute pools can set their own, different values - but only within the allowed range of values supported by the DDX and printers's model-config. Can I execute my own scripts to process the PostScript files generated by Xprt ? Yes, there are at least two possible solutions: Create your own model-config which uses a custom "xp-spooler-command" value - the xprint.mozdev.org's "PSspooldir" model config (see "${XPCONFIGDIR}/C/print/models/PSspooldir/" and "${XPCONFIGDIR}/C/print/attributes/printer" and "${XPCONFIGDIR}/C/print/Xprinters") and "PS2PDFspooldir-GS" model config (see "${XPCONFIGDIR}/C/print/models/PS2PDFspooldir-GS/" and "${XPCONFIGDIR}/C/print/attributes/printer" and "${XPCONFIGDIR}/C/print/Xprinters") are good examples for that. Use an existing "model-config" (which would normally send it's data to a printer using the default print spooler command) and provide a custom "xp-spooler-command".
Example (using "SPSPARC2" as printer model, <filename>/w/xp_conv</filename> as the script to execute and "myscriptprinter" as name of the printer): Edit ${XPCONFIGDIR}/C/print/attributes/printer and add these lines (Xprt will replace "%printer-name%" with the printer's name, "%copy-count%" with the number of job copies, "%job-name%" with the job's title and "%options%" with any custom spooler options): myscriptprinter.xp-model-identifier: SPSPARC2 myscriptprinter.xp-spooler-command: /w/xp_conv -p %printer-name% -c %copy-count% -t %job-name% -o "%options%" Edit ${XPCONFIGDIR}/C/print/Xprinters and append this line: Printer myscriptprinter
How can I disable "xp_ps_spooldir_tmp_Xprintjobs" / "xp_pdf_spooldir_tmp_Xprintjobs" printer targets ? Edit ${XPCONFIGDIR}/C/print/Xprinters and remove or comment-out (using '#') the lines "Printer xp_ps_spooldir_tmp_Xprintjobs" and "Printer xp_pdf_spooldir_tmp_Xprintjobs". Note: Note that Xprt will NOT start if this printer has been removed/disabled and no other print queue is available (e.g. if "xp_ps_spooldir_tmp_Xprintjobs" and "Printer xp_pdf_spooldir_tmp_Xprintjobs" are the only printer target available). Troubleshooting "Printing itself works but the printout covers only 1/4 of the paper - what am I doing wrong ?" This is usually an indicator for a wrong DPI setting. The default "PSdefault" model config uses 300 DPI but some printers only support 600 DPI. Workaround: Edit ${XPCONFIGDIR}/C/print/attributes/document and replace the line "*default-printer-resolution: 300" with "*default-printer-resolution: 600" (Note that locale-specific settings in ${XPCONFIGDIR}/${LANG}/print/attributes/document always override values set in ${XPCONFIGDIR}/C/print/attributes/document.) Solution: Create a model-config for your printer which only contains attributes supported by your printer ("printer-resolutions-supported" is the attribute in the "model-config" which holds the space-seperated list of DPI values which are supported by the printer). "Printing works but I get large borders/margins..." / "[Top] margin is too small" / "Margins are wrong" / etc. Two possible causes: Usually same issue as "Printing itself works but the printout covers only 1/4 of the page"-issue: Wrong DPI. Solution: Check the DPI value and adjust it as described in the FAQ item above. Common DPI values for the PostScript DDX are 240, 300, 360, 400 and 600 DPI. You are trying to print "US-letter" on a "DIN-A4" paper or "DIN-A4" on "US-letter". Solution: Check your paper settings Note that the default papersize for Xprt depends on the locale (e.g. on the env var ${LANG}) Xprt is running in - "en_US"&co. get US-letter, all others use DIN-A4 (incl. german/austrian etc. locales)). Exception from this rule: If the selected printer does not support the default paper size it will set no default paper size for this printer (then the application side has to make an explicit choice). Xprt refuses to start with the message "sh: lpc: command not found" on my Linux machine. What does that mean ? Some versions of Xprt look up printer queues using "lpc" on Linux. In this case "lpc" cannot be found for some reason. Solution: Find the place where "lpc" is installed on your machine (some distributions put it into /usr/sbin, some into /usr/bin/) and check whether your PATH env var includes this directory. Example (if "lpc" is located in /usr/sbin/): % which lpc /usr/sbin/lpc % export PATH=$PATH:/usr/sbin # Start Xprt ... % Xprt <your-options-come-here> When the application (=client side) tries to connect to the Xprt (Xserver) side it fails with a Xlib: connection to "meridian:52.0" refused by server Xlib: Client is not authorized to connect to Server What does that mean ? X11 implements access control. You can have host-based, cookie-based (a "cookie" is used like a passport) or user-based (SecureRPC or Kerberos5) authentification. Xsecurity__miscmansuffix__ has most of the details. No access control: If you do not want to use access control for Xprt then you can start it with the option "-ac" (see Xserver__mansuffix__) to disable the access control. Example: % Xprt -ac -audit 4 :12 will start Xprt with access control disabled and with auditing enabled (e.g. the "-audit 4" option). WARNING Disabling the access control will enable everyone who can access Xprt to print on your printers (that's why the above example shows how to use auditing, too - that you can see who does something with Xprt...) !! Host-based access control: Host-based access control can be archived using /etc/X<dpy>.hosts (<dpy> == display number, e.g. /etc/X0.hosts for display 0 (see Xserver__mansuffix__ manual page for further details)).
Example Add the following line to `/etc/X12.hosts' (assuming you want that the hosts 'merkur' and 'mars' should be able to access the Xprt server running as display 12 on your host 'neptun'): INET:merkur INET:mars Start Xprt Verify that Xprt is correctly configured: % export DISPLAY=neptun:12 % xhost access control enabled, only authorized clients can connect INET:localhost LOCAL: INET:merkur INET:mars
Xprt refuses to start with the message "failed to set default font path '...' Fatal server error: could not open default font 'fixed'". What does that mean ? This means one or more components in the font path (set via the option "-fp") are either... ... not valid ... contain fonts not supported by this Xserver (e.g. support has not be compiled "in" (usually happens for TrueType (which are only support for Solaris version of Xprt and xprint.mozdev.org releases ≥ 008), OpenType (which are only supported by xprint.mozdev.org releases 009 or higher) or F3 fonts (Sunsoft/F3 fonts are Solaris-specific and not supported by other vendors (AFAIK)) when support for these fonts was not enabled at build time)) ... no font or font alias in the font path matches the name "fixed" ... an entry in fonts.dir or fonts.alias with the name "fixed" which references a non-existing or non-readable file Just copying my fonts into a directory and adding the path to my Xprt command line didn't work - I always get "Fatal server error: could not open default font 'fixed'". What am I doing wrong ? Every Xserver needs an index file called fonts.dir to tell it which fonts are available in this directory and which properties these fonts have. If you are lucky there may be already a fonts.scale file which can be used by "mkfontdir" to create the fonts.dir file. If there is no fonts.scale then you have to create your own fonts.dir/fonts.scale either by hand or via tools like "mkfontscale" (works for all types of scaleable fonts), "type1inst" (for PS Type1 fonts; see http://packages.debian.org/stable/utils/type1inst.html) or "ttmkfdir" (for TrueType fonts; see http://packages.debian.org/stable/x11/ttmkfdir.html). Xprt refuses to start with the message "Fatal server error: Cannot establish any listening sockets - Make sure an X server isn't already running". What does that mean ? There is already a Xserver running at the display ID you have specified to start Xprt (for example your framebuffer Xserver runs at ":0" then Xprt can't run at the same display display). Xprt refuses to start with the message "Fatal server error: Failed to establish all listening sockets". What does that mean ? This means that the Xserver could not open one of it's sockets. Check the permission of /tmp/.X11-pipe and /tmp/.X11-unix (on Solaris a Xserver must run set-gid "root" to access these directories). Either fix the permission or start Xprt with the option "-pn". Using this option requires to access the server always with <hostname>:<displaynum> (see Xserver__mansuffix__ manual page for the side-effects of this option). Xprt refuses to start with the message "Fatal server error: could not open default font 'fixed'" or "Fatal server error: could not open default cursor font 'cursor'". All Xservers at least two fonts as the minimum: One fixed-width font ("fixed") and one font for the cursor ("cursor"). Be sure that the font path contains these fonts. Xprt refuses to start with the message "Fatal server error: no screens found". What does that mean ? Cause: This means that Xprt could not find any printers. Either there are no printers installed, "lpstat"/"lpc" could not find any printers or the configuration does not contain any manual printer configurations (see Q/A item "Which program is used by default by Xprt to enumerate the printers on my system" for further details...). Solution: Two solutions: Using "PSspooldir" model: Xprt releases from http://xprint.mozdev.org/ provide the "PSspooldir" model config for such cases. Just edit the "Xprinters" file and add this line: Printer xp_ps_spooldir_tmp_Xprintjobs this will add the pre-configured (see ${XPCONFIGDIR}/C/print/attributes/printer) "xp_ps_spooldir_tmp_Xprintjobs" printer which will send jobs to the directory "/tmp/Xprintjobs/" instead to a printer queue. (This feature was added in the xprint.mozdev.org release 007, see xprint.mozdev.org bug 2475 ("RFE: Need model-config which spools print jobs in a predefined directory").) Manual setup (task list):
Provide a simple "Xprinters" spec file which contains a dummy queue. Example: # Create "Xprinters_onlydummy" file which turns autolookup of printers # OFF (using "Augment_Printer_List %none%") and provides one dummy # queue called "ps_myscript" instead (using "Printer ps_myscript") % echo "Augment_Printer_List %none%" >Xprinters_onlydummy % echo "Printer ps_myscript" >>Xprinters_onlydummy Edit ${XPCONFIGDIR}/C/print/attributes/printer and add these two lines: ps_myscript.xp-model-identifier: PSdefault ps_myscript.xp-spooler-command: /home/sanja/xprint_test/my_xprt_cat_script.sh This means that the printer "ps_myscript" now uses the "PSdefault" printer model and it will feed the jobs to the script "/home/sanja/xprint_test/my_xprt_cat_script.sh" (via stdin). Note that the absolute path is required for "*xp-spooler-command". Start Xprt on display 18, passing the "Xprinters_onlydummy" using the "-XpFile" option: % Xprt -XpFile ./Xprinters_onlydummy -pn -ac -audit 4 :18
Xprt prints a warning like "Xp Extension: could not find config dir /usr/X11R6/lib/X11/C/print" - what does that mean ? This is actually the worst case what can happen. The message indicates that Xprt was unable to find it's configuration data. Solution: Two solutions are possible: Install the configuration data at the requested location (/usr/X11R6/lib/X11/C/print/ in this example) Set the ${XPCONFIGDIR} env var to the location of the Xprt configuration directory. Xprt crashes with "Fatal server error: Beziers this big not yet supported" What does that mean ? This is a known issue in the X11R6.5.1 code. In rare cases some PostScript Type1 fonts can trigger this. See "My PS Type1 font does not work with my Xserver" ... "My PS Type1 font does not work with my Xserver - how can I fix this ?" Some PS Type1 do not work out-of-the-box with all PS Type1 font engines - some will work with the Adobe font engine (used in Solaris Xsun) but not with the X.org font engine (or the other way round) or the fonts are simply broken. The following procedure will try to fix this problem: Get the "type1fix" perl script the TeXTrace package (http://www.inf.bme.hu/~pts/textrace-latest.tar.gz) and run it over the fonts. Example 1 (filter fonts): # Broken PFA fonts are in broken_fonts/ % mkdir fixed_fonts ; cd fixed_fonts % for i in ../broken_fonts/*.pfa ; do echo " ------- $i" ; type1fix.pl --ofmt=pfa --infile=$i --outfile=$(basename ${i}) ; done Example 2 (filter fonts and convert them to PFB on-the-fly; do not forget to update fonts.scale and run "mkfontdir" (to update fonts.dir) ; systems which use the Adobe font engine (like Solaris/Xsun) may require to run "makepsres", too): # Broken PFA fonts are in broken_fonts/ % mkdir fixed_fonts ; cd fixed_fonts % for i in ../broken_fonts/*.pfa ; do echo " ------- $i" ; type1fix.pl --ofmt=pfb --infile=$i --outfile=$(basename ${i%.pfa}.pfb) ; done I can't get it working. I have set ${DISPLAY} correctly to point to the Xprt display and... ... What is going wrong ? Do not set ${DISPLAY} to the Xprt server. You still need your normal Xserver for your video card - Xprt is only for your printer(s). Applications look up Xprt servers via the ${XPSERVERLIST} env var, NOT via the ${DISPLAY} env var. When I try to print via Xprint I get the message "Fatal server error: unable to exec '/usr/bin/lp'". What is going wrong here ? This usually means that the spooler application "/usr/bin/lp" could not be launched. This is usually the result when /usr/bin/lp does not exist or cannot be executed (for example, shell scripts without the +x (executable) flag etc.). The Solaris Xprt prints some error messages about PostScript fonts like "FOOBAR not found, using Courier. CMEX0123 not found, using Courier." etc. and uses "Courier" instead of these fonts... Cause: The Solaris (Adobe-based) PostScript font engine requires a "PostScript resource database" file named "PSres.upr" to use the PostScript fonts correctly. Solution: Create the missing PSres.upr database.
Steps to create the missing "<filename>PSres.upr</filename>" file (task list): Go to the location where the matching fonts are installed (we're using /home/sanja/mathml_fonts/tex_cmps/Type1/ in this example): % cd /home/sanja/mathml_fonts/tex_cmps/Type1// Create "PSres.upr" using the "makepsres" command. % makepsres Validation: Make sure the file has been created: % ls -l PSres.upr Restart Xprt server(s): % /etc/init.d/xprint restart Restart application which uses these fonts
References: makepsres1 manual page bugzilla.mozilla.org 120560 ("Solaris Xsun does not like CMEX10/CMSY10 Type1 fonts") bugzilla.mozilla.org 142718 ("Document how to get the MathML fonts to work on Solaris") "Xprt refused to start, complaining about a missing dir (/etc/X11/xserver/C/print/ directory)... I created it by hand (empty) and started Xprt but it still does not work properly..." Xprt expects some config data in this directory. Just making it an existing but empty dir will work around the error message but will not result in a properly working Xprt since it has no (usefull) builtins which would make it possible to run the binary without the config data. Your X11 binary distribution should always come with the config data (for example /usr/openwin/server/etc/XpConfig/ on Solaris) or you will not be able to use Xprint (however it is possible to copy the config data from another system :) BTW: Source for the configs can be found under xc/programs/Xserver/XpConfig/ My Linux system already shipps with a '/usr/X11R6/bin/Xprt'-binary. Do I need the binary distribution from http://xprint.mozdev.org/ ? This depends on what is shipped with your Linux distribution. Please check the "vendor" string of the Xprt server: % Xprt :10 & % xdpyinfo -display :10 | grep -i "vendor string" If this outputs a line like "vendor string: The XFree86 Project, Inc" then you have the Xprt binary build from Xfree86 sources - which are broken - even the newest version [I'll update this as soon as Xfree86 shipps with a working version]. Xprt from Solaris, HP-UX and my own builds (which identifies itself as "vendor string: xprint.mozdev.org" for releases >= 007, older releases (e.g. <= 006) identify itself as as "vendor string: The X.Org Group") are known to work proprtly. I am getting the error message "error opening security policy file /usr/X11R6/lib/X11/xserver/SecurityPolicy". What does that mean ? The policy file for the SECURITY extension cannot be found. This is not serious unless you want to make use of features of the SECURITY extensions (like treating clients as "untrusted", e.g. restrict their access to certain Xserver resources). Normally the missing policy file is a problem with your Unix/Linux X11 distribution; consult your vendor where to get the missing file from. Alternatively you can get the plain X11R6.6 security policy file from ftp://ftp.x.org/pub/R6.6/xc/programs/Xserver/Xext/SecurityPolicy (copy it to the matching location - but be sure that you do not overwrite any existing security policy file). I have modified the "HPLJ4family" [or "HPDJ1600C" etc.] printer model to work with my PostScript printer, but when I print I get empty places where some text should be - what am I doing wrong here ? The "HPLJ4family" and "HPDJ1600C" models are PCL-only, check the model-config spec (${XPCONFIGDIR}/C/print/models/${MODEL_NAME}/model-config) - if the "xp-ddx-identifier" attribute says something with "PCL" (like "XP-PCL-MONO" etc.) in the value string then this model-config is for the PCL-DDX only (e.g. their PMF fonts do not supply the neccesary information (e.g. the "_ADOBE_POSTSCRIPT_FONTNAME" chunk is missing; they only provide the "PCL_FONT_NAME" chunk) nor are these fonts accessible via the PostScript-support in these printers. A solution is to use the "PSdefault" model instead (and/or create your customized own version of this model) - or look if there is a model-config beginning with the same name and ending with "PS" (e.g. "HPLJ4family-PS"). Xprt outputs warning messages like: Xp Extension: Can't load driver XP-PCL-MONO init function missing Xp Extension: Can't load driver XP-RASTER init function missing What does that mean ? Two possible problems: The requested driver is not supported by that version of Xprt. For example Solaris 2.7 Xprt does not support XP-PCL-MONO nor the XP-RASTER driver. Valid values for the "xp-ddx-identifier" attribute in ${XPCONFIGDIR}/*/print/attributes/printers and/or ${XPCONFIGDIR}/*/print/models/*/model-config are Solaris 2.7: XP-POSTSCRIPT and XP-PCL-COLOR Solaris >=2.8: XP-POSTSCRIPT, XP-PCL-COLOR, XP-PCL-MONO and XP-RASTER HP-UX: XP-POSTSCRIPT, XP-PCL-COLOR, XP-PCL-MONO, XP-PCL-LJ3, XP-PCL-DJ1200 and XP-RASTER xprint.mozdev.org release 007: XP-POSTSCRIPT and XP-RASTER xprint.mozdev.org release 008: XP-POSTSCRIPT, XP-PCL-COLOR, XP-PCL-MONO, XP-PCL-LJ3 and XP-RASTER xprint.mozdev.org release >=2.0 (planned): XP-POSTSCRIPT, XP-PCL-COLOR, XP-PCL-MONO, XP-PCL-LJ3, XP-RASTER, XP-PDF and XP-SVGPRINT. There may be too many drivers loaded into one Xprt instance. By default a single Xserver instance can only handle three screens - and since one Xprint DDX maps to one Xserver screen this limit applies to the number of loaded Xprt drivers, too. Starting with xprint.mozdev.org release 008 the per-Xserver screen limit was increased from "3" to "8" to avoid this issue... Workaround: Start a 2nd instance of Xprt which handles the other drivers which do not fit into the first instance. Printing on Solaris with Mozilla/Eclipse [or any other Xprint client] removes spaces between words. What is going wrong ? Cause: This is a bug in the Solaris Xprint server binary (/usr/openwin/bin/Xprt). Various bug reports have been filed, see xprint.mozdev.org bug 3353 ("Solaris Xprt looses space when rendering with '-monotype-arial-*'-fonts") bugzilla.mozilla.org bug 199957 ("Solaris 8 Mozilla removes spaces for text within <font face="Arial">...</font>") Solution: Solution: Please apply the following OS patches from http://sunsolve.sun.com/: Solaris patches to fix <ulink url="http://xprint.mozdev.org/bugs/show_bug.cgi?id=3353">xprint.mozdev.org bug 3353 ("Solaris Xprt looses space when rendering with '-monotype-arial-*'-fonts")</ulink> Solaris 2.7 Solaris 2.8 Solaris 2.9 SPARC x86 SPARC x86 SPARC x86 n/a n/a 108652-73 108653-62 112785-21 112786-11
For Solaris 2.7 (both SPARC and x86 platforms) there are currently no patches available... ;-( Known workarounds: Remove the '-monotype-arial-*' fonts from the font path Use an alternate Xprint server like available in the "GISWxprint" package (this package is identical to the "GISWxprintglue" package except that it uses a Xprint server build from xprint.mozdev.org sources and not the /usr/openwin/bin/Xprt binary from Solaris) Mozilla-only: Adding user_pref("print.xprint.font.rejectfontpattern", "fname=-dt-.*;scalable=.*;outline_scaled=false;xdisplay=.*;xdpy=.*;ydpy=.*;xdevice=.*|" + "fname=-monotype-arial.*;scalable=.*;outline_scaled=.*;xdisplay=.*;xdpy=.*;ydpy=.*;xdevice=.*"); to prefs.js works around the problem (see bugzilla.mozilla.org bug 199957 comment #6, too). Note that this workaround may render various locales completly inaccessible for printing since many of them only employ MonoType fonts. Installation of the "GISWxprint" / "GISWxprintglue" packages fails like this: # pkgadd -d /space/staging/xprint/GISWxprint.pkg pkgadd: ERROR: no packages were found in </var/tmp/dstreAAA5Jayyz> Any idea what I am doing wrong ? The target machine misses a patch to cure SunSolve bug 4025718 ("pkginfo: allow greater than nine characters for PKG parameter value"). Please apply the patches listed in the "Installation Requirements" section in the README for the GISWxprint / GISWxprintglue package. Printing page results in [two/three/.../16] leading blank pages, followed by a correct (but offset) page. Any idea what is going wrong ? This symptom depends on the CUPS GhostScript driver used, however the exact cause is currently unknown (see comments in SuSE support database entry SDB-2002/11/jsmeix_print-81-cups-formfeed ("Blank Pages When Printing with CUPS")). Solution: Disable the CUPS accounting functionality in the cupsomatic filter by changing the line my $ps_accounting = 1; to my $ps_accounting = 0; in the filter script /usr/lib/cups/filter/cupsomatic as the user root. If you use /etc/foomatic/filter.conf, disable ps_accounting there. References: SuSE support database entry SDB-2002/11/jsmeix_print-81-cups-formfeed ("Blank Pages When Printing with CUPS") xprint.mozdev.org bug 4181 ("Two empty pages printed first") bugzilla.mozilla.org bug 180602 comment #7 ("Printing page results in 16 leading blank pages, followed by a correct, but offset, page") Software development How does the X print server (Xprt) and the Xlib client side differ from the "normal" video Xserver/video client side ? The X Print Service expands on the traditional X-Server and Xlib world in the following ways: 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 language (PDL)" output (such as PCL, PDF, PostScript, SVGprint, etc.) or sends the print rendering instructions to a platform-specific print API (like Win32/GDI). Once a print ddx driver generates PDL output, it can be sent to a spooler (using XpuStartJobToSpooler) or retrieved by the client (to implement functionality like "print-to-file" with functions such as XpuStartJobToFile). Since printers support "paged" output, unlike video, a portion of the Xp Extension supports APIs to delineate printed output into a print job. A "print job" in Xprint consists of one or more "documents" which itself consists of one or more "pages". A client starts a job sequence with XpStartJob and ends it with XpEndJob or XpCancelJob to cancel the generation of the current print job. Any document-specific print attributes MUST be changed before XpStartJob. A client starts a document sequence with XpStartDoc and ends it with XpEndDoc or XpCancelDoc to cancel the generation of the current document. Any document-specific print attributes MUST be changed before XpStartDoc or after XpEndDoc (to affect the following document). A client starts a page sequence with XpStartPage and ends it with XpEndPage or XpCancelPage to cancel the generation of the current page. Any page-specific print attributes MUST be changed before XpStartDoc or after XpEndDoc (to affect the following document). 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 context 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 output. Some "attributes" within the print context can be modified by the user, and the X-Server and print ddx driver will react accordingly. 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). 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 fonts. 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 rendering calls use the resolution of the current page (or if not given, the resolution of the current document or the current resolution for this print job). The screen's resolution is INVALID in this case. XprintUtils has the functions XpuGetResolution (to get the current print resolution (searching page, document and job level attributes (in that order)), XpuSetPageResolution (to set the current page resolution), XpuSetDocResolution (to set the current document resolution), XpuGetResolutionList (to get the list of all resolutions supported by this printer) and XpuFindResolution (to find a resolution in the list returned by XpuGetResolutionList) to support getting/setting/queries of resolutions. When a print context is created and set for a given printer, the X image rendering calls (such as XPutImage support scaling of images. The Xp Extension API provides the functions XpSetImageResolution and XpSetImageResolution to set and get an image resolution. The scaling factor for an image printed on the paper can simply calculated via scaling_factor = curr_print_resolution_resolution / image_resolution where curr_print_resolution_resolution is the value returned by a function such as XpuGetResolution, image_resolution the resolution passed to XpSetImageResolution and scaling_factor the resulting scaling factor. Note that XpSetImageResolution will failure (=FALSE) when the print DDX (for example the RASTER DDX) does not support scaling. In that case the application has to scale the image manually. How can I get the printable area (e.g. the portion of the page on which the printer is physically capable of placing ink) of the paper after I have chosen a paper ? The XpGetPageDimensions function returns the printable area and other information about the current page geometry. Note that the page geometry changes when the page attributes such as content-orientation or default-medium are changed by the application. Do "offscreen" pixmaps work on Xprt ? Yes, "offscreen" pixmaps are working on Xprt. How can I get the DPI value for the current Xprt server ? Can I use the values from "xdpyinfo" ? The Xprt screen resolution defines only the maximum resolution configured for the matching DDX, the printers real DPI is obtained via an another API (XprintUtil has a bunch of functions to get/set the document/page resolution, see XpuGetResolutionList, XpuFreeResolutionList, XpuGetResolution, XpuSetPageResolution, XpuSetDocResolution and XpuFindResolution). Why does Xprt not offer the MIT-SHM protocol extension ? The MIT-SHM protocol extension is partially (XShmPutImage would work, but others like XShmGetImage and esp. XShmCreatePixmap cannot be implemented properly) incompatible to the way how some of the Xprint DDX are implemented. For example the PostScript, PDF, PCL and SVGprint DDX do not rasterize any images on their side - instead they convert the stream of X11 rendering instructions into the matching PDL instruction stream. Only the printer side will (finally) do the rasterisation of the output image. This is the basically the same reason why XGetImage does not work for those DDXs - and functions such as XShmCreatePixmap would be useless since drawing operations on the shared pixmap would not be applied to the application (e.g. Xprint client) as well. Does Xprint/Xprt support font rotation ? Yes - Xprint/Xprt supports font rotation at any angle via the matrix XLFD enhancement (this even works for printer-builtin fonts !!). For details see the paper "New Font Technology for X11R6" by Nathan Meyers (a copy can be found in the Xprint.org source tree under xc/doc/hardcopy/XLFD/x11r6_fonts_94_paper.PS.gz) Short: The transformation-matrix for rotation can be calculated like this: +-- --+ | cos(angle) sin(angle)| | | |-sin(angle) cos(angle)| +-- --+ Examples: the following code fragment obtains a 180 degree rotated font (matrix [-1 0 0 -1]): ... = XLoadQueryFont(..., "-adobe-courier-bold-r-normal--*-[~24 0 0 ~24]-0-0-m-*-iso8859-1"); the following code fragment obtains a 90 degree rotated font (matrix [0 1 -1 0]): ... = XLoadQueryFont(..., "-adobe-courier-bold-r-normal--*-[0 24 ~24 0]-0-0-m-*-iso8859-1"); Future versions of Xprint will support the STSF font API which supports matrix transformations as well. When I render something on my window and call XpStartPage all the rendered stuff is gone, I only get a white, empty paper. What is going wrong here ? Remember the rule that "only those drawings are printed on the paper which were rendered between XpStartPage and XpEndPage". XpStartPage clears the window you passed as argument, e.g. it creates a new, blank sheet of paper where you can do your rendering stuff on. XpEndpage then pushes the "paper sheet" to the stash of papers from the document in process. If you want to render something once for multiple or all pages: Render on a offscreen pixmap and copy (with XCopyArea) the content to the "paper" drawable (after calling XpStartPage) - XpStartpage only affects the window passed as parameter. What is XpStartDoc for ? ISO 10175 and some advanced printing systems by IBM and HP had set forth the standard that a "Job" is made up of one or more "Documents", and each document is made up of one or more "Pages". Xprint was designed that in a true ISO 10175 environment/implementation (lp1 on steroids, and with an API), Xprt can actually learn about all printers and their capabilities though API's into the printer subsystem (vs. using config files), map Job/Doc/Page directly into ISO 10175 equivalents, and use APIs to view job status and kill jobs (vs. cancel1, lpcancel1, lpstatus1). Because most applications of the day are only printing one document per job, XpStartPage was designed that it generates a "synthetic" XpStartDoc if it has not been called yet. How does the XLFD for printer-builtin fonts look like ? / How can I find/identify printer-builtin fonts ? There is no special XLFD scheme for printer-builtin fonts. Instead the xp-listfonts-modes-supported is used to define whether XListFonts and co. return printer-builtin fonts or not. By default the attribute looks is set to *xp-listfonts-modes-supported: xp-list-internal-printer-fonts xp-list-glyph-fonts which defines thaht XListFonts and co. return both printer-builtin and normal fonts. Removing xp-list-internal-printer-fonts will make printer-builtin fonts disappear, removing xp-list-glyph-fonts will make normal glyph fonts disappear from font lists. How can I scale images using the Xprint API ? XXX Can I pass my own PostScript code (fragment) to the print spooler instead of letting Xprt's PostScript DDX generate it ? XXX When I use XpPutDocumentData I get a BadValue X protocol error. Any idea what am I doing wrong ? XXX How do I use the XprintUtil library ? XXX Why does the XGetImage not work for Xprt ? There are at least three reasons why XGetImage does not work for Xprt: Most of the Xprt DDX implementations do not render itself on any bitmaps like the framebuffer(=video) DDX do, they translate the rendering commands into the matching commands of the printer language (it is technically possible to implement such support for XGetImage even for those drivers - but there are more reasons:) Xprt usually operates at high resolutions which results in very large dimensions. If a client would request the 24bit TrueColor bitmap data for a whole DIN-A4 page at 2400 DPI a data chunk of ~173 megabytes would be the response. This would be more or less a DOS(=Denial of Service) for either the client, the network and/or the server. The printer-builtin fonts only provide metrics information - there is no real "outline" information at that time (these fonts reside only in the printer's ROM and are only available at the time the printer rasterizes the incoming PDL (e.g. PCL/PostScript) data stream) which could be used to rasterize the matching glyphs (which means: A XGetImage implementation would return image data but glyphs rendered using the printer-builtin fonts would be missing). How to print with Xt/Athena widgets ? There are two examples in the Xprint.org and X11R6.7.1 source trees which demonstrate how to use Xprint using Athena widgets: xc/programs/xphelloworld/xpawhelloworld/ contains a simple demo application which prints a Athena widget using the XawPrintShell widget class. xc/programs/xphelloworld/xpxthelloworld/ contains a simple demo application which prints a Athena widget without using a special print widget class (however, if possible a print shell such as XawPrintShell or XmPrintShell should be used since this is the easier way to add print support to an Athena application). How to print with Xt/Motif widgets ? The Xprint.org source tree contains the xpxmhelloworld (xc/programs/xphelloworld/xpxmhelloworld/) application to demonstrate how to print using the Motif2 toolkit. What are the differences between normal display and Xprint display ? XXX How do I scale images ? XXX libXp Image scaling vs. max. request size ? XXX How can I use XprintUtils ? XXX How do I calculate the DPI values for Xprt DDX screens ? XXX How do I find scaleable fonts ? XXX How do I find printer-builtin fonts ? XXX The XLFD for Printer-builtin fonts look like bitmap fonts - is that bad ? No, this is not "bad". The XLFD of a printer-builtin font only looks like a bitmap font since the *.pmf (Printer metrics file) format is a PCF file format variant (the DPI values in the XLFD AFAIK specifies the resolution which was used for generating the metrics) - however this does not change the fact that the printer-builtin fonts are outline scaleable fonts these fonts reside in the printer's ROM). When printing using the XawPrintShell/XmPrintShell print shells my PostScript output is always corrupt. What am I doing wrong ? Make sure the widgets (such as text input widgets) have the (blinking) cursor turned-off. Setting the XmNcursorPositionVisible, to False usually solves the problem (for Motif2 widgets). Example: ... XtSetArg(args[n], XmNcursorPositionVisible, False); ... When printing using the XawPrintShell/XmPrintShell print shells I always get a grey/dithered background on paper. Any idea how to change that to "white" ? XXX Are there any caveats/suggestions when printing via Xt/Motif2 widgets ? There are a couple of Xt resources which may likely differ from the normal values (e.g. those values used for a video Xserver): Core class level XmNbackground resource The application will probably want to set the XmNbackground resource to "white" to match the default paper color. XmNborderWidth resource The application will probably want to set the XmNborderWidth resource to "0" (usually the default value) to avoid that a black border appears around the widget. XmPrimitive class XmNshadowThickness and XmNhightlightThickness resources The application will probably want to set XmNshadowThickness and XmNhightlightThickness to "0" (usually the default value) to avoid 3D border effects on the printout (depends on application and author's preference... :-)). XmText and XmTextField classes XmNcursorPositionVisible resource The application will probably want to set XmNcursorPositionVisible to False to avoid that the cursor is visible on printouts (and to avoid problems with some nasty implementation details which may cause corrupted PostScript output). XmNscrollHorizontal and XmNscrollVertical resources The application will probably want to set the XmNscrollHorizontal and XmNscrollVertical resources to False to suppress printing of scrollbars (on paper "scrolling" is replaced with "pagination" except for rare exceptions (like 1:1 WYSIWYG-printing)). XmNmarginWidth and XmNmarginHeight resources The application will probably want to recalculate the XmNmarginWidth and XmNmarginHeight resources based on the (far) higher print resolution (or reverse: set them to "0" - depending on what style matches the application needs better...). XmLabel class XmNmarginTop, XmNmarginBottom, XmNmarginRight, XmNmarginLeft, XmNmarginWidth, XmNmarginHeight and XmNalignment resources The application will probably want to use different value for XmLabel class's XmNmarginTop, XmNmarginBottom, XmNmarginRight, XmNmarginLeft, XmNmarginWidth, XmNmarginHeight and XmNalignment resources. These resources are mainly usefull when the widget holds a border, highlight or shadow of some kind. If borders are not to be transferred there is no real need to transfer a margin either. Can I change the paper size/resolution/page orientation/etc. when printing using the XawPrintShell/XmPrintShell print shells ? Yes, it is allowed to change the page attributes in the page setup callback (e.g. XawNpageSetupCallback or XmNpageSetupCallback) since this callback is always called before XpStartPage (for the 2nd and following pages: between XpEndPage and XpStartPage). Note that changing page attributes will automagically update the print shell widget size (e.g. attributes XawNminX, XawNminY, XawNmaxX and XawNmaxX (XawPrintShell) or XmNminX, XmNminY, XmNmaxX and XmNmaxX (XmPrintShell) are updated based on events send by the Xp Extension and then the print shell is resized based on the new values (XawPrintShell is slightly more flexible since the size mode can be defined using the XawNlayoutMode attribute)). Where can I find an example how to print with Xprint using the OpenGL/GLX API ? In Xorg release 6.7.1 Xprint support was added to the GLX demo application "glxgears" (xc/programs/Xserver/glxgears/). Known bugs Xprt build from Xfree86 sources is completely broken and unuseable. Build Xprt from the CVS tree at http://xprint.mozdev.org/ or the X.org X11R6.5.1 sources (note that the client side Xprint extension library ("libXp.so") from Xfree86 is not broken and do not need to be replaced). The code which matches XLFD names to PS Type1 font names is case-sensitive in Xprts build from X.org X11R6.5.1/X11R6.6 and the current Solaris Xprt. This may cause that the PS DDX refuses to download PS Type1 fonts. Patch available, I am looking for a way to get the patch into the X11 and Solaris source trees... Xprt build from X11R6.5.1/X11R6.6 sources and Solaris's version of Xprt can only download PFA (PS ASCII font) fonts which ends of the ending "*.pfa". Either convert PFB (PS Type 1 binary font) to PFA format and adjust the fonts.dir and fonts.scale file or get a patch for the sources. I am looking for a way to get the patch into the X11 and Solaris source trees (the fixed version can download both PFA/PFB fonts in PFA format and even handles non-standard file extensions). There is an issue how the Linux and Solaris Xprt handles the "copy-count" of a print job. The result may be that a job with n copies of a document end-up in n jobs with n copies (usually equals to n^2 copies). Xprt build from xprint.mozdev.org sources has been fixed in release 007, see xprint.mozdev.org bug 1378 ("PS DDX creates n^2 copies of a job instead of n copies") and bugzilla.mozilla.org 140030 ("Setting number of copies causes too many copies to print") for details. Solaris 2.7 Xprt still suffers from this issue... ;-( Unanswered questions (My small ToDo list what I will write soon; 379 items missing... =:-) Email me if you want one of these answered "now" and/or to contribute an answer... :) How do I create a model-config for my printer ? How can I customize a model-config for my site/machine ? Which attributes/values can be set in a model-config ? Why can't I set default values (for my {paper size, resolution, ...}) in the model-config ? Should I add the fonts in the model-config dir to the Xserver's font path ? What are the fonts in the model-config dir for ? Can I use a font server for all fonts instead of passing then directly to the Xprint server ? Does the Xprint PostScript driver do full rasterisation of the print job ? Is it possible to prepare a printer config entry so that the PS output is piped to "ps2pdf" and will produce directly a PDF file? It would be nice to have mozilla directly producing PDF files when printing. Problem: I have changed the Xprt config - but "xplsprinters -l" (or any other Xprint application) does not show the change. Any idea what I am doing wrong ? How can I add a font path to Xprt ? Why does "xset +fp path_to_font" not work in some cases ? How can I get a "core"-dump when Xprt crashes ? How can I debug Xprt (hint: use "-audit 4") ? How can I debug Xprt with Sun Workshop (hint: "check -access") ? How can I check whether Xprint is "active" ? / How can I verify that a Xprint is working ? Acknowledgements We'd like like to express their gratitude to the whole community for providing insightful answers to innumerable questions. In particular, the following people (listed alphabetically) have contributed to this FAQ (apologies, in advance, if anyone has been forgotten): Alan Coopersmith alan.coopersmith@sun.com Giuseppe Ghibò ghibo@mandrakesoft.com Thomas Gilg thomas_gilg@hp.com Jay Hobson jay.hobson@sun.com Masaki Katakai katakai@japan.sun.com Simon Montagu smontagu@smontagu.org Drew Parsons dparsons@debian.org (and many many others)