Xprint Frequently Asked Questions

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

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

Xprint is client-server based, therefore two answers:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

There are various applications which support Xprint:

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

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

Copyright (c) <year> <copyright holders>

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

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

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

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

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

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

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

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

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

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

XXX

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

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

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

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

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

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

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

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

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

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

References:�

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

% echo $XPSERVERLIST

west:33

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

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

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

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

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

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

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

% xp_print_slogin_args.ksh

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

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

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

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

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

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

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

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

Augment_Printer_List %none%
Printer ps001
Printer ps003
Printer hplaser6

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

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

This depends on the OS:

Some sources:

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

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

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

XXX

XXX

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

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

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

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

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

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

Yes, there are at least two possible solutions:

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".

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

Two possible causes:

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>

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.

This means one or more components in the font path (set via the option "-fp") are either...

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

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

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(1x) manual page for the side-effects of this option).

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.

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:

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:

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" ...

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

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.

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

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.

References:�

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/

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.

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

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

Two possible problems:

Cause:� This is a bug in the Solaris Xprint server binary (/usr/openwin/bin/Xprt). Various bug reports have been filed, see

Solution:� Solution: Please apply the following OS patches from http://sunsolve.sun.com/:

Known workarounds:�

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.

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:�

The X Print Service expands on the traditional X-Server and Xlib world in the following ways:

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.

Yes, "offscreen" pixmaps are working on Xprt.

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

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.

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:

Future versions of Xprint will support the STSF font API which supports matrix transformations as well.

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.

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.

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.

XXX

XXX

XXX

XXX

There are at least three reasons why XGetImage does not work for Xprt:

There are two examples in the Xprint.org and X11R6.7.1 source trees which demonstrate how to use Xprint using Athena widgets:

The Xprint.org source tree contains the xpxmhelloworld (xc/programs/xphelloworld/xpxmhelloworld/) application to demonstrate how to print using the Motif2 toolkit.

XXX

XXX

XXX

XXX

XXX

XXX

XXX

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

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

XXX

There are a couple of Xt resources which may likely differ from the normal values (e.g. those values used for a video Xserver):

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

In Xorg release 6.7.1 Xprint support was added to the GLX demo application "glxgears" (xc/programs/Xserver/glxgears/).

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

Patch available, I am looking for a way to get the patch into the X11 and Solaris source trees...

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

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... ;-(