Archive-name: Xprint/FAQ_OLD
Version: 0.8
Last-Modified: 2003/08/04 15:20:19
Maintained-by: Roland Mainz <Roland.Mainz@informatik.med.uni-giessen.de>

NOTE: This version of the FAQ has been discontinued and was replaced by the
DocBook-based version available under xc/doc/hardcopy/XPRINT/Xprint_FAQ.xml
(available through http from
<http://xprint.mozdev.org/lxr/http/source/xprint/src/xprint_main/xc/doc/hardcopy/XPRINT/Xprint_FAQ.xml>)

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 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.mozdev.org/lxr/http/source/xprint/src/xprint_main/xc/doc/hardcopy/XPRINT/Xprint_old_FAQ.txt>

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... :)

1. GENERAL
- Q: What is "Xprint" ?
  A: 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 or PDF.
     
     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.
     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... 

- Q: Where can I get Xprint/Xprt from ?
  A: Xprint is client-server based, therefore two answers:
     - The server side is available by default on Solaris[1] 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)       
     - The client-side Xprint support library (libXp.so) is available on all
       X11 platforms >=R6.4, including Linux, Solaris, HP-UX, AIX etc.
       if you do not have it you can build it from the sources available at 
       http://xprint.mozdev.org/

       [1]=(for Solaris >= 2.7 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))

- Q: What is "Xprt" ?
  A: 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.).

- Q: "Why do some people like Xprint ?" / "What are the advantages of Xprint ?"
  A: - 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.

- Q: Why do some people dislike Xprint?
  A: There are a few common misconceptions about Xprint.
     Let's take a look some of these "myths", some background - and the facts:
            
     - Myth: "Xprint prints just a XWD dump of the Xserver bitmap"
       Fact: Whoever says Xprint simply does an "xwd"-like dump is wrong.

             In short, Xprint _currently_ (X11R6.5.1) supports *four* drivers:
             1) X to native Postscript
             2) X to native PCL5
             3) X to native PCL3
             4) 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 PostScrpt and PCL5 printing and more
             drivers (like a PDF DDX etc.) are in the development.

     - Myth: "Xprint cannot handle non-'ISO Latin 1' chars"
     - Fact: 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.
             
     - Myth: "Xprint uses a 1024x768 screen resolution to render the stuff on 
             the paper - therefore it will never be able to do high-resolution
             stuff"
       Fact: 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.

     - Myth: "Xprint prints only graphics(=bitmap/gfx) fonts"
     - Fact: 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 PostScipt Type1 fonts. However this
             is the fallback - the _last_ option used by Xprt. Used if
             everything else fails.
             But when someone does not pass any 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...

     - Myth: "Xprint does not support pages sizes larger than DIN-A4"
       Fact: 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.
             
     - Myth: "Xprint does not support rotated text"
       Fact: Xprint and all it's drivers support the X11 matrix XLFD
             enhancement introduced in X11R6. Fonts can be rotated at any
             angle. Take a look at the "SOFTWARE DEVELOPMENT" section in this
             FAQ for examples...

- Q: Does Xprint support anti-aliased fonts ?
  A: 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.

- Q: How can I check if Xprint is working and should be used ?
  A: Check whether the ${XPSERVERLIST} env var is set or not. 
     If ${XPSERVERLIST} is set then Xprint is available and should be used.   

- Q: How can I view PS(=PostScript) files ?
  A: - On Unix/Linux (general):
       - GhostScript ("gs") and GhostView ("gv")
     - Solaris:
       - /usr/dt/bin/sdtimage (DPS-based image viewer for CDE)
       - /usr/openwin/bin/pageview (DPS-based image viewer for OpenWindows)

- Q: How can I view PCL files ?
  A: XXX - http://xprint.mozdev.org/bugs/show_bug.cgi?id=2261 has been filed
     for that issue.
    
- Q: How does Xprt find fonts ?
  A: Lookup-rule for Xprt's PostScript DDX to find fonts:
    1. Printer-builtin fonts (defined by the fonts/-dir in the model-config)
    2. PostScript fonts (will be downloaded via generated print job)
    3. GFX-fonts build from X11 scaleable fonts
    4. GFX-fonts build from X11 bitmap fonts

- Q: How can I print TrueType fonts with Xprint ?
  A: 1. 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.
     2. Sun's Xprt on Solaris (/usr/openwin/bin/Xprt) has TrueType font
     support out-of-the-box and does not require any special actions
     3. You can setup a TTF-aware X font server ("xfs", see xfs(1)) with the
     matching TrueType fonts and add the font server location to Xprt's font
     path.
     4. 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...

- Q: What does "DDX" mean ?
  A: DDX is a short term for "Device Dependent X" - the device-specific layer
     of a Xserver ("DIX"(="Device Independent X") is the counterpart).
     
- Q: What does "DIX" mean ?
  A: DIX is a short term for "Device Independent X" - the non-device specific
     code of a Xserver ("DDX"(="Device Dependent X") is the counterpart).

- Q: I have twenty printers installed on my system - but Xprt only shows two
     screens. Where are all the other printers ?
  A: 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).

- Q: Which platforms support Xprint ?
  A: 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-HX
     (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/

- Q: 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 ?
  A: 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.

- Q: Which spelling is correct - "Xprint", "XPrint", "Xprinter" or Xprt" ?
  A: "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).

- Q: Which applications support Xprint ?
  A: There are various applications which support Xprint:
    - Motif/LessTif (full framework incl. special widgets like XmPrintShell)
    - Common Desktop Environment (CDE) 2.x
    - Mozilla
    - Eclipse
    - KDE/Qt support is comming is planned for the end of Dec/2002
    - StarOffice 5.x
    etc.
    
- Q: Is "Xprint" "mozilla"-only (I saw that it's hosted by mozdev.org) ?
  A: No, Xprint is a general-purpose print API based on the X11 API used by
     many applications (mozdev.org is just hosting the development area, but
     this does not mean the project is limited to mozilla... :)

- Q: Under which license is the source code from xprint.mozdev.org distributed
     under ?
  A: That's the plain "MIT" license, the same as used by Xfree86.org and X.org:
     -- snip --
     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.
     -- snip --

2. USAGE
- Q: How do I configure Xprint on the client side ?
  A: There are two env vars which control Xprint on the client side:
     1. 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.
     2. The env variable ${XPRINTER} defines the default printer used by print
        applications. The syntax is either <printername> or
        <printername>@<display>
        - Examples:
          1. % export XPRINTER=ps003
          tells an application to look for the first printer named "ps003" on
          all Xprt servers.
          2. % export XPRINTER="hplaser19@littlecat:80"
          tells an application to look for the printer "hplaser19" on the Xprt
          display "littlecat:80".
        * If ${XPRINTER} is not set the applications will examine the values of
          the ${PDPRINTER}, ${LPDEST}, and ${PRINTER} env vars (in that order).

- Q: How do I start Xprt ?
  A: 1. 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...

     2. 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}:
     -- snip --
     export XPSERVERLIST="`/bin/sh /etc/init.d/xprint get_xpserverlist`"
     -- snip --
     See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=171174
     ('"xprint-xprintorg" should automatically populate $XPSERVERLIST') for
     further details on this issue...
     
     3a. 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...

     3b. 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).
     
     4. 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.

     5. 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":
       -- snip --
       % 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)
       -- snip --
     - 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):
       -- snip --
       % find /usr/openwin -name fonts.dir | while read i ; do echo
       ${i%/fonts.dir} ; done | fgrep -v "models/"
       -- snip --
       Plug it into the filter above to remove the Truetype fonts and you are
       "done"... :)
 
     See TROUBLESHOOTING if you run into problems...

- Q: How can I get a list of printers managed by Xprint ?
  A: 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:
       -- snip --
       % xplsprinters
       printer: hplaserjet001@castor:19
       printer: hpcolor001@castor:19
       printer: laser1@jason:5
       printer: david_dj01@jason:5
       -- snip --
     - Get information about the supported attrbites of printer "ps002":
       -- snip --
       % xplsprinters -printer ps002 -l
       printer: ps002@castor:18
               comment=
               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
       -- snip --

- Q: How can I start Xprt at boot time ?
  A: "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.

- Q: How can I start Xprt per-user ?
  A: "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.
     
- Q: How can I start Xprt only for one application ?
  A: 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.
  
- Q: How can I filter the font path which should be passed to Xprt for
     certain fonts ?
  A: XXX

- Q: How can I manage access control to the Xprt server ?
  A: 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(1)))
     and/or per-machine (using "xhost" (see xhost(1)) and/or 
     /etc/X<dpy>.hosts (<dpy> ==  display number, e.g. /etc/X0.hosts for
     display 0) (see Xserver(1)))
     Consult manual pages Xsecurity(7), xhost(1), Xserver(1) etc. for further
     details.
  
- Q: How can I log access to the Xprt server ?
  A: Logging access to Xprt can be done using the standard Xserver auditing,
     see the Xserver(1) manual page, option "-audit"

- Q: Does it require "root" permissions to use Xprt/Xprint ?
  A: 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).

- Q: How can I see the attributes of a printer managed by Xprint ?
  A: "xplsprinters -printer myprinter004 -l" will do the job for printer
     "myprinter004". See xlsfonts(1) for futher usage and a description of
     the output. 

- Q: How can I list the font path used by a Xprt server ?
  A: Figure out the display id of the server which should be queried (we are
     using "foobar:98" in this example) and then try this:
     -- snip --
     % (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/
     -- snip --
     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).

- Q: "xset q" lists all model-specific font dirs (like
     PRINTER:/myxpcfg/C/print/models/SPSPARC2/fonts/") - is that a bug ?
  A: 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.

- Q: My application lists a printer called "spooldir_tmp_Xprintjobs" in the
     print dialog but I do not have such a print queue installed anywhere.
     What is that for a thing ?!
  A: "spooldir_tmp_Xprintjobs" is a special Xprint printer target which uses
     the "PSspooldir" printer model. This model config sends PostScript jobs
     to the /tmp/Xprintjobs/ directory instead to a physical printer (quite
     usefull for people who want to get the PostScript files as output instead
     of printed pages).

3. CONFIGURATION
- Q: How do I change the defaults for double-sided/single-sided/etc.
     printing ?
  A: 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:
     1. Adding/modifying the following line to/in
        ${XPCONFIGDIR}/C/print/attributes/document sets the default plex for
        all printers to "duplex":
        -- snip --
        *plex: duplex
        -- snip --
     2. 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":
        -- snip --
        *plex: duplex
        ps003.plex: simplex
        -- snip --
     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.

- Q: 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) ?
  A: 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:
     1. Adding/modifying the following line to/in
        ${XPCONFIGDIR}/C/print/attributes/document sets the default paper size
        for all printers to "na-letter":
        -- snip --
        *default-medium: na-letter
        -- snip --
     2. 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":
        -- snip --
        *default-medium: na-letter
        ps003.default-medium: iso-a4
        -- snip --
     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.

- Q: How do I change the default printer resolution ?
  A: 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:
     1. Adding/modifying the following line to/in
        ${XPCONFIGDIR}/C/print/attributes/document sets the default
        resolution for all printers to 600 DPI:
        -- snip --
        *default-printer-resolution: 600
        -- snip --
     2. 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:
        -- snip --
        *default-printer-resolution: 300
        tekcolor_ps.default-printer-resolution: 1200
        -- snip --
     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.

- Q: How do I change the default settings for "portrait"/"landscape"/"seascape"
     (=page orientation) ?
  A: 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:
     1. Adding/modifying the following line to/in
        ${XPCONFIGDIR}/C/print/attributes/document sets the default
        orientation for all printers to "portrait":
        -- snip --
        *content-orientation: portrait
        -- snip --
     2. 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":
        -- snip --
        *content-orientation: portrait
        ps003.content-orientation: landscape
        -- snip --
     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.
      
- Q: How can I prevent Xprt from using any bitmap(=gfx) fonts ?
  A: 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:
     1. Create a new directory:
       % mkdir Xp_dummyfonts
       % cd Xp_dummyfonts
     2. Create a fonts.alias file with the following content:
       -- snip --
       ! 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.
       -- snip --
     3. 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
     4. Verify: The directory should now look like this:
       -- snip --
       % ls -1
       6x13.pcf.Z
       cursor.pcf.Z
       fonts.alias
       fonts.dir
       -- snip --
     5. 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 created a tarball from these instructions, get it from
     | http://puck.informatik.med.uni-giessen.de/people/gisburn/work/xprint/fonts/Xp_dummyfonts.tar.gz
     | Unpack it and add the new dir to your fontpath)
     
- Q: I want only my manually added printers managed by Xprint. How can I
     prevent Xprt from looking-up the printer names automatically ?
  A: 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:
     -- snip --
     Augment_Printer_List %none%
     Printer ps001
     Printer ps003
     Printer hplaser6
     -- snip --
     will add only the printers "ps001", ps003" and "hplaser6".
     
- Q: How can I specifc an own program/script to enumerate the printers on by system ?
  A: 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.
  
- Q: Which program is used by default by Xprt to enumerate the printers on
     my system ?
  A: 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 sources (both lines are executed
         to support both LPng and CUPS):
         % lpc status | awk '/:$/ && !/@/ { print $1 }' | sed -e /:/s/// ;
           lpc -a status | awk '/@/ && !/:/ { split( $1, name, \"@\" ); print name[1]; }'
     - On AIX v4:
       % lsallq | grep -v '^bsh$'
     * See xc/programs/Xserver/Xprint/Init.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).

- Q: Where can I get more PostScript Type1 fonts from ?
  A: 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:
           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
         http://puck.informatik.med.uni-giessen.de/people/gisburn/work/xprint/fonts/postscript_type_1/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/
     - Some of my own collections:
       (see http://puck.informatik.med.uni-giessen.de/people/gisburn/work/xprint/fonts/postscript_type_1/):
       - KOI8-R:
         http://puck.informatik.med.uni-giessen.de/people/gisburn/work/xprint/fonts/postscript_type_1/PS_Type1_koi8-r.tar.gz
       - ISO-8859-8/Hebrew:
         http://puck.informatik.med.uni-giessen.de/people/gisburn/work/xprint/fonts/postscript_type_1/PS_Type1_iso8859-8.tar.gz

- Q: 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/)) ?
  A: 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.).

- Q: Can I use the fontserver ("xfs") with Xprt ?
  A: 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
     http://xprint.mozdev.org/bugs/show_bug.cgi?id=2092 if they use "xfs";
     this has been fixed in the 007 release!)

- Q: What is a "model-config" ?
  A: 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).
  
- Q: Where can I store the default values for printers ?
  A: XXX

- Q: How can I create my own model-config ?
  A: XXX
  
- Q: How can I create my own PMF "fonts" ?
  A: XXX - no solution yet, but 
     http://xprint.mozdev.org/bugs/show_bug.cgi?id=2430 ("RFE: Need tool to
     create PMF (printer metrics file) fonts") has been fixed to create a
     freeware tool to create such fonts.

- Q: Where can I get more model-configs from ?
  A: If you miss a model-config for your printer please open a bug/RFE at
     http://xprint.mozdev.org/bugs/enter_bug.cgi?product=xprint&component=Server%3A+Config%3A+model-configs
     (e.g. ttp://xprint.mozdev.org/bugs/ , product "Xprint", component
     "Server Config: model-configs").
 
- Q: 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 ?
  A: 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.

- Q: Are config files and/or the PMF fonts architecture dependent ?
  A: The PMF fonts are AFAIK 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.

- Q: Can I localise my Xprint/Xprt configuration ?
  A: 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.
     * Notes:
       - 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.

- Q: Can I execute my own scripts to process the PostScript files generated
     by Xprt ?
  A: Yes, there are at least two possible solutions:
     1. 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") is a good example for that.
     2. 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 and "myscriptprinter" as
       name of the printer):
       1. 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):
         -- snip --
         myscriptprinter.xp-model-identifier: SPSPARC2
         myscriptprinter.xp-spooler-command: -printer %printer-name% -copies %copy-count% -title %job-name% -options "%options%"
         -- snip --
       2. Edit ${XPCONFIGDIR}/C/print/Xprinters and append this line:
         -- snip --
         Printer myscriptprinter
         -- snip --

- Q: How can I disable "spooldir_tmp_Xprintjobs" printer target ?
  A: Edit ${XPCONFIGDIR}/C/print/Xprinters and remove or comment-out the line
     "Printer spooldir_tmp_Xprintjobs".
     Note that Xprt will _NOT_ start if this printer has been removed/disabled
     and no other print queue is available (e.g. if "spooldir_tmp_Xprintjobs"
     is the only printer target available).

4. TROUBLESHOOTING
- Q: Xprt refuses to start with the message "sh: lpc: command not found" on
     my Linux machine. What does that mean ?
  A: Xprt looks up printers 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>
     
- Q: When the application (=client side) tries to connect to the Xprt
     (Xserver) side it fails with a
     -- snip --
     Xlib: connection to "meridian:52.0" refused by server
     Xlib: Client is not authorized to connect to Server
     -- snip --
     What does that mean ?
  A: 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(7) has most of the details.
     a. 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(1)) 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...) !!
     
     b. 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(1) manual page for further details)).
       Example:
       1. 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'):
          -- snip --
          INET:merkur
          INET:mars
          -- snip --
       2. Start Xprt
       3. Verify that Xprt is correctly configured:    
          -- snip --
          % export DISPLAY=neptun:12
          % xhost
          access control enabled, only authorized clients can connect
          INET:localhost
          LOCAL:
          INET:merkur
          INET:mars
          -- snip --

- Q: 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 ?
  A: 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 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"

- Q: 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 ?
  A: 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 a tool like "type1inst" (see
     http://packages.debian.org/stable/utils/type1inst.html) for PS Type1
     fonts and "ttmkfdir" (see
     http://packages.debian.org/stable/x11/ttmkfdir.html) for TrueType fonts.

- Q: 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 ?
  A: 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).

- Q: Xprt refuses to start with the message "Fatal server error: Failed to
     establish all listening sockets". What does that mean ?
  A: 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(1) manual page for the side-effects
     of this option).

- Q: 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'".
  A: 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.
     I created a tarball which contains only these two fonts, get it from
     http://puck.informatik.med.uni-giessen.de/people/gisburn/work/xprint/fonts/Xp_dummyfonts.tar.gz

- Q: Xprt refuses to start with the message "Fatal server error: no screens
     found". What does that mean ?
  A: 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...).
     
     Two solutions:
     1. Using "PSspooldir" model:
        Xprt releases from http://xprint.mozdev.org/ provide the "PSspooldir"
        model config for such cases. Just edit the "Xprinters" and add
        this line:
        -- snip --
        Printer spooldir_tmp_Xprintjobs
        -- snip --
        this will add the pre-configured (see
        ${XPCONFIGDIR}/C/print/attributes/printer) "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 
        http://xprint.mozdev.org/bugs/show_bug.cgi?id=2475 ("RFE: Need
        model-config which spools print jobs in a predefined directory"))

    2. Manual setup:
      Step 1: 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
      Step 2: Edit ${XPCONFIGDIR}/C/print/attributes/printer and add these
        two lines:
        -- snip --
        ps_myscript.xp-model-identifier: PSdefault
        ps_myscript.xp-spooler-command: /home/sanja/xprint_test/my_xprt_cat_script.sh
        -- snip --
        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".
      Step 3: Start Xprt on display 18, passing the "Xprinters_onlydummy"
        using the "-XpFile" option:
        % Xprt -XpFile ./Xprinters_onlydummy -pn -ac -audit 4 :18

- Q: "Printing itself works but the printout covers only 1/4 of the paper
     - what am I doing wrong ?"
  A: 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).

- Q: "Printing works but I get large borders/margins..." / "[Top] margin is too small" /
     "Margins are wrong" / etc.
  A: 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).

- Q: Xprt prints a warning like "Xp Extension: could not find config dir
     /usr/X11R6/lib/X11/C/print" - what does that mean ?
  A: This is actually the worst case what can happen.
     The message indicates that Xprt was unable to find it's configuration
     data.
     Solution:
     - Install configuration data at the requested location
     OR
     - Set the ${XPCONFIGDIR} env var to the location of the Xprt
       configuration directory.

- Q: Xprt crashes with "Fatal server error: Beziers this big not yet supported"
     What does that mean ?
  A: 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" ...

- Q: "My PS Type1 font does not work with my Xserver - how can I fix this ?"
  A: 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

- Q: I can't get it working. I have set ${DISPLAY} correctly to point to the
     Xprt display and... ... What is going wrong ?
  A: 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.

- Q: 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 ?
  A: It usually means that the spooler application "/usr/bin/lp" would 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 flag etc.).
 
- Q: 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...
  A: The Solaris (Adobe-based) PostScript font engine requires a "PostScript
     resource database" file named "PSres.upr" to use the PostScript fonts
     correctly.
     * Solution:
     Steps to create the missing file:
     1. 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/
     2. Create "PSres.upr" using the "makepsres" resource file
       % makepsres
     3. Validation:
       Make sure the file has been created:
       % ls -l PSres.upr
     4. Restart Xprt server(s):
       % /etc/init.d/xprint restart
     5. Restart application which uses these fonts     

     The makepsres(1) manual page has some additional details about this
     subject...

- Q: "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..."
  A: 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 won't
     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

- Q: My Linux system already shipps with a '/usr/X11R6/bin/Xprt'-binary.
     Do I need the binary distribution from http://xprint.mozdev.org/ ?
  A: 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.

- Q: I am getting the error message "error opening security policy file
     /usr/X11R6/lib/X11/xserver/SecurityPolicy". What does that mean ?
  A: 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).

- Q: 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 ?
  A: 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").

- Q: Xprt outputs warning messages like:
    -- snip --
    Xp Extension: Can't load driver XP-PCL-MONO
                  init function missing
    Xp Extension: Can't load driver XP-RASTER
                  init function missing
    -- snip --
    What does that mean ?
  A: Two possible problems:
    1. 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 >=1.0 (planned): XP-POSTSCRIPT, XP-PCL-COLOR,
        XP-PCL-MONO, XP-PCL-LJ3, XP-RASTER and XP-PDF
    2. 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.

- Q: Printing on Solaris with Mozilla/Eclipse [or any other Xprint client]
     removes spaces between words. What is going wrong ?
  A: This is a bug in the Solaris Xprint server binary (/usr/openwin/bin/Xprt).
     Various bug reports have been filed, see
     - http://xprint.mozdev.org/bugs/show_bug.cgi?id=3353 ("Solaris Xprt looses
       space when rendering with '-monotype-arial-*'-fonts")
     - http://bugzilla.mozilla.org/show_bug.cgi?id=199957 ("Solaris 8 Mozilla
       removes spaces for text within <font face="Arial">...</font>")
     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
       -- snip --
       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=.*");
       -- snip --
       to prefs.js works around the problem (see
       http://bugzilla.mozilla.org/show_bug.cgi?id=199957#c6 , too).

5. SOFTWARE DEVELOPMENT
- Q: 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 ?
  A: XpGetPageDimensions() returns the printable area and other information
     about the page geometry.

- Q: Do "offscreen" pixmaps work on Xprt ?
  A: Yes, "offscreen" pixmaps are working on Xprt.

- Q: How can I get the DPI value for the current Xprt server ? Can I use the
     values from "xdpyinfo" ?
  A: 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()).

- Q: Does Xprint/Xprt support font rotation ?
  A: 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 <XXX: URL ?>.
     Short:
     The transformation-matrix for rotation can be calculated like this:
     +--                    --+
     | cos(angle)   sin(angle)|
     |                        |
     |-sin(angle)   cos(angle)|
     +--                    --+
     Examples:
     1. the following code fragment obtains a 180 degree rotated font (matrix [-1 0 0 -1]):
     -- snip --
     ... = XLoadQueryFont(..., "-adobe-courier-bold-r-normal--*-[~24 0 0 ~24]-0-0-m-*-iso8859-1");
     -- snip --
     2. the following code fragment obtains a 90 degree rotated font (matrix [0 1 -1 0]):
     -- snip --
     ... = XLoadQueryFont(..., "-adobe-courier-bold-r-normal--*-[0 24 ~24 0]-0-0-m-*-iso8859-1");
     -- snip --

- Q: 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 ?
  A: 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.
     Solution - 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.
     
- Q: What is XpStartDoc() for ?
  A: 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 (lp(1) 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. cancel(1), lpcancel(1),
     lpstatus(1)).
     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.
  
- Q: How does the XLFD for printer-builtin fonts look like ?
  A: XXX

- Q: How can I scale images using the Xprint API ?
  A: XXX
  
- Q: How do I use the XprintUtil library ?
  A: XXX

- Q: Why does XGetImage() not work for Xprt ?
  A: There are at least two reasons why XGetImage() does not work for Xprt:
     1. 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 is reason [2]:)
     2. 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.

- Q: How to print with Xt/Athena widgets ?
  A: XXX

- Q: How to print with Xt/Motif widgets ?
  A: XXX

- Q: What are the differences between normal display and Xprint display ?
  A: XXX

- Q: How can I find/identify printer-builtin fonts ?
  A: XXX

- Q: How do I scale images ?
  A: XXX

- Q: libXp Image scaling vs. max. request size ?
  A: XXX

- Q: How can I use XprintUtils ?
  A: XXX

- Q: How do I calculate the DPI values for Xprt DDX screens ?
  A: XXX

- Q: How do I find scaleable fonts ?
  A: XXX

- Q. How do I find printer-builtin fonts ?
  A: XXX

- Q: The XLFD for printer-builtin fonts look like bitmap fonts - is that bad ?
  A: XXX
  
- Q: When can I use printer-buildin fonts ?
  A: XXX

- Q: Where can I find examples fir adding Xprint support to my Xt/Athena application ?
  A: XXX

- Q: Where can I find examples fir adding Xprint support to my Xt/Motif application
  (without the need for CDE's DtPrint library) ?
  A: XXX

- Q: Where can I find examples fir adding Xprint support to my Qt application ?
  A: XXX


6. KNOWN BUGS:
   ('P'=Problem, 'S'=Solution)
   - P: Xprt build from Xfree86 sources is completely broken and unuseable.
     S: 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).

   - P: 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.
     S: Patch available, I am looking for a way to get the patch into the X11
        and Solaris source trees...

   - P: 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".
     S: 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).

   - P: 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).
     S: Xprt build from xprint.mozdev.org sources has been fixed in release
        007, see http://xprint.mozdev.org/bugs/show_bug.cgi?id=1378 ("PS DDX
        creates n^2 copies of a job instead of n copies") and
        http://bugzilla.mozilla.org/show_bug.cgi?id=140030 ("Setting number
        of copies causes too many copies to print") for details.
        Solaris 2.7 Xprt still suffers from this issue... ;-(

   XXX XXX XXX

7. 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... :)
  - Q: How do I create a model-config for my printer ?
  - Q: How can I customize a model-config for my site/machine ?
  - Q: Which attributes/values can be set in a model-config ?
  - Q: Why can't I set default values (for my {paper size, resolution, ...})
       in the model-config ?
  - Q: Should I add the fonts in the model-config dir to the Xserver's
       font path ?
  - Q: What are the fonts in the model-config dir for ?
  - Q: Can I use a font server for all fonts instead of passing then directly
       to the Xprint server ?
  - Q: Does the Xprint PostScript driver do full rasterisation of the
       print job ?
  - Q: 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.
  - Q: 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 ?
  - Q: How can I add a font path to Xprt ?
  - Q: Why does "xset +fp path_to_font" not work in some cases ?
  - Q: How can I get a "core"-dump when Xprt crashes ?
  - Q: How can I debug Xprt (hint: use "-audit 4") ?
  - Q: How can I debug Xprt with Sun Workshop (hint: "check -access") ?
  - Q: How can I check whether Xprint is "active" ? / How can I verify that a Xprint is working ?
 
  XXXX XXXX XXXX
  
8. 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>
  Thomas Gilg <thomas_gilg@hp.com>
  Jay Hobson <jay.hobson@sun.com>
  Masaki Katakai <katakai@japan.sun.com>
  Simon Montagu <smontagu@netscape.com>
  Drew Parsons <dparsons@debian.org>
  (and many many others)

# EOF.