INTRODUCTION This is Gutenprint version 5.0.0 release candidate 1, the first release candidate of Gutenprint 5.0. Gutenprint, formerly named Gimp-Print, is a suite of printer drivers that may be used with most common UNIX print spooling systems, including CUPS, lpr, LPRng, or others. These drivers provide high quality printing for UNIX (including Macintosh OS X 10.2 and newer) and Linux systems in many cases equal to or better than proprietary vendor-supplied drivers, and can be used for many of the most demanding printing tasks. A complete list of supported printers may be found in the NEWS file. The package has been renamed in order to clearly distinguish it from the GIMP. While this package started out as the Print plugin for the GIMP, it has expanded into a collection of general purpose printer drivers, and the Print plugin for the GIMP is now only a small (but important) piece of the package. Furthermore, the name Gutenprint recognizes Johannes Gutenberg, the inventor of the movable type printing press. Finally, the word "guten" means "good" in German. Gutenprint also includes a plug-in for the GIMP image editor. This plug-in is also distributed with the GIMP. Gutenprint was previously known as Gimp-Print. The name was changed prior to the 5.0.0 release. Please read this README, and the NEWS file carefully! Many things have changed from previous releases. The package is quite different in many ways from Gimp-Print 4.2, and you should read these instructions carefully. In addition, the NEWS file contains specific software requirements. A user's manual exists in doc/users_guide; it is normally installed in PDF and HTML form in /usr/local/share/gutenprint/doc. This manual covers setup and use of the GIMP Print plug-in and the CUPS driver. We urge all distributors of this package to read the PACKAGING and KNOWN BUILD ISSUES section below. BASIC INSTALLATION Gutenprint includes the following primary components: - The core driver, libgutenprint.so - A user's manual - A Print plug-in for the GIMP - A CUPS (Common UNIX Printing System) driver - An IJS-based Ghostscript driver - Support for the Foomatic spooler configuration system - A utility to administer Epson printers, escputil By default, Gutenprint builds the Print plugin for the GIMP, the user's manual, and a utility to perform head cleaning, nozzle alignment, and other tasks on EPSON Stylus inkjet printers, named "escputil". Directions for building other components are listed below. Please check our web site at http://gimp-print.sourceforge.net for details about what is and is not supported. Please report any problems to gimp-print-devel@sourceforge.net. In general, to build Gutenprint, you run the following commands: ./configure [options] make make install If you do not have the GIMP installed (or if you have only the user package installed, and not the development package that most distributions include separately), the attempt to run configure will fail. To build other components (such as the Ghostscript or CUPS drivers) without the GIMP being present, you must use the --without-gimp option to configure. By default dynamically loadable modules (plug-ins) will be built, and loaded at run-time if your operating system supports it. If you experience problems, --with-modules=dlopen or --with-modules=ltdl may be used to select the module loading method (dlopen is the default, but GNU libltdl is more portable), or --with-modules=static or --without-modules disables them. Note: This package requires the use of GNU Make to compile. On systems with both GNU make and another make installed, GNU make may be named `gmake' or `gnumake'. BSD users in particular will need to use 'gmake'. THE GIMP Gutenprint may be used as a plug-in for the GIMP, providing the ability to print images. If you wish to do so, you must use the GIMP 1.2.3 or above on the 1.2 line, or any GIMP 2.x release (2.0, 2.1, 2.2, etc.) Please read the release notes in addition to this README, as there have been some changes in procedure since Gimp-Print 4.2 if you are using certain versions of the GIMP. To build and install the GIMP Print plug-in for the GIMP 1.2: ./configure [--with-gimp] make make install For the GIMP 2.0 or above, the option "--with-gimp2" rather than "--with-gimp" should be used. You may optionally specify --with-gimp or --with-gimp2 if you wish to be explicit about building the GIMP Print plugin; --with-gimp is implied if `configure' detects that the GIMP is installed, so you do not actually need to specify it. This installs the GIMP Print plugin in your system plug-in directory. If you wish to install it in your personal plugin directory, you may use ./configure --enable-user-install If you have installed the GIMP as a precompiled package (e. g. from an RPM), you will need to install the gimp-devel (sometimes called gimp-developer, or something similar) package as well as the gimp package. The GIMP package as supplied in most distributions only contains what's needed to run the GIMP, not the additional files needed to build GIMP-based applications and plugins such as the Print plugin. On some systems, you will also need to install gtk-devel and glib-devel packages as well. If you have installed the GIMP from source on Linux: after running make install, you must run ldconfig as root before attempting to build this plugin. The GIMP 1.2 will not be supported in Gutenprint 5.1 and beyond. However, all Gutenprint 5.0 releases will support The GIMP 1.2. The GIMP 2.x plugin may eventually be migrated to The GIMP project for a future GIMP release. It may be removed from the Gutenprint distribution following Gutenprint 5.0. CUPS Gutenprint may be used as a driver under CUPS (Common UNIX Printing System), if your system uses that spooler. Full description of CUPS is beyond the scope of this README file; full information may be found at http://www.cups.org. Gutenprint 5.0 requires CUPS 1.1.9 or higher. We recommend use of 1.1.15 or above; that release of CUPS fixes some important bugs. This package includes a CUPS driver that may be built, allowing use of this software for general printing purposes. To build and install the CUPS driver, you must run: ./configure --with-cups make make install cups-genppdupdate.5.0 (OPTIONAL) /etc/init.d/cups restart If you have installed CUPS as a precompiled package (e. g. it's the standard printing system that your distribution uses), you may need to install a separate development package (typically called "cups-devel" or "cups-developer"). You will need to do this if configure completes correctly, but "make" fails when building in src/cups. The CUPS package typically installed by most distributions only contains the components needed to run CUPS, not those required to build additional CUPS drivers. The last command (/etc/init.d/cups restart) varies with your operating system; the purpose is to restart the CUPS server (daemon) so that it sees the newly installed driver. It is typically /etc/init.d/cups, /etc/software/init.d/cups, /etc/rc.d/cups, or even /etc/rc.d/init.d/cups. Your system may have a different way to restart the CUPS server. OS X uses the following command: sudo /System/Library/StartupItems/PrintingServices/PrintingServices.sh restart You may optionally choose to update your existing PPD files using the command cups-genppdupdate.5.0, after which you should restart CUPS as described above. We strongly recommend use of this update procedure. This script will automatically update Gutenprint PPD files from earlier versions. This script will only work with Gimp-Print 4.3.21 or above, or any earlier version of Gutenprint; it will not update Gimp-Print 4.2 PPD files. However, you may install Gutenprint 5.0 alongside Gimp-Print 4.2, and use both Gimp-Print 4.2 and Gutenprint 5.0 drivers concurrently. Therefore, you need not convert a workflow based on Gimp-Print 4.2 right away, but can gradually convert or even use both drivers for different printer queues. If you do not choose to automatically update existing PPD files, you should reinstall any printers that you are using Gutenprint PPD files with. The Gutenprint driver and the PPD files must be kept in sync, since the PPD files reflect the particular version of the driver that they were built against. If you attempt to use a version of Gutenprint with PPD files not built for that precise version, the driver will fail with a diagnostic error message. For example, PPD files built for Gutenprint 5.0.0-beta4 will not work with driver version 5.0.0-rc1. You can identify printers using Gutenprint PPD files by the name of the PPD file, which will be something like: EPSON Stylus Photo EX - CUPS+Gutenprint v5.0.0-rc1(en) NOTE for Linux (at least) users: If you are using CUPS 1.1.11 or higher, and you have a USB-connected printer, you must have a printer connected to each USB port that you plan to use and powered on when you restart CUPS. If you do not do so, you will not be able to reinstall the printer. It is only necessary to do this if you wish to update PPD files manually; if you use cups-genppdupdate.5.0, you do not need to do this. Starting with CUPS 1.1.11, you cannot choose an AppSocket connection and enter "usb:/dev/usblp0" or the like as the URI; you will get a "client-error-not-possible" error at the end of the installation process, and you will have a message like the following in your CUPS error log (typically /var/log/cups/error_log): E [21/Nov/2001:17:59:07 +0500] add_printer: bad device-uri attribute 'usb:/dev/usb/lp0'! If the printer was turned on correctly, you will be given a choice of a USB connection in the Device dialog. You may also have problems if you have a .lpoptions file that has old options set. If you have problems printing, please remove any existing .lpoptions file in your home directory and try printing again. This package normally builds translated versions of the PPD files. This provides PPD files translated into the languages that this package supports. However, the translation process does not work correctly on all systems; in particular, many BSD systems are known to simply build multiple copies of the English PPD files. If your system does not build these files correctly, which will be apparent when you use a CUPS front end to select a PPD file and you see something like this: EPSON Stylus Photo EX - CUPS+Gutenprint v5.0.0-rc1(en) EPSON Stylus Photo EX - CUPS+Gutenprint v5.0.0-rc1(en) EPSON Stylus Photo EX - CUPS+Gutenprint v5.0.0-rc1(en) rather than this: EPSON Stylus Photo EX - CUPS+Gutenprint v5.0.0-rc1(en) EPSON Stylus Photo EX - CUPS+Gutenprint v5.0.0-rc1(sv) EPSON Stylus Photo EX - CUPS+Gutenprint v5.0.0-rc1(fr) you may wish to turn off the translation of PPD files: ./configure --with-cups --disable-translated-cups-ppds You may also wish to do this to greatly reduce the number of PPD files installed on your system, as the number of translations is large and growing. The PPD files associated with this driver are normally for Level 3 PostScript. CUPS versions starting with 1.1.15 fully implement Level 3 Postscript, but earlier versions do not implement a few Level 3 constructs. The configuration script will attempt to detect the version of CUPS and generate appropriate PPD files. If you wish to build PPD files for Level 2 Postscript even with a newer version of CUPS, you can run ./configure --with-cups --disable-cups-level3-ppds We recommend that all users who wish to use this package for general purpose printing install either CUPS or use Foomatic with the Ghostscript driver (both described below) and use that as their printing system, rather than the traditional lpd or lp systems. It is much simpler to manage than lpd, and provides an excellent web-based interface for both administration and use. Please visit http://www.cups.org for information on downloading and installing CUPS. FOOMATIC Gutenprint includes support for the Foomatic meta-driver package. This requires the foomatic-xml distribution. Foomatic is available from http://www.linuxprinting.org/foomatic.html. The first version of Foomatic (the one used with Gimp-Print 4.0) is not compatible with Gutenprint 5.0. Note that the Foomatic driver was named `stp' in Gimp-Print 4.0; in Gimp-Print 4.2 (and early 4.3) it was named `gimp-print' for the Ghostscript ("stp") driver and "gimp-print-ijs" for the IJS driver. In 5.0 only the "gutenprint-ijs" data is present. The data for the Gimp-Print 4.2 driver is not compatible with the 5.0 driver. Furthermore, as of Gutenprint 5.0 the Foomatic driver will include the release version of Gutenprint in its name. Therefore, the Foomatic name for this driver is "gutenprint-ijs.5.0". Foomatic data generation has been fixed as of Gutenprint 5.0.0-beta4, and is now an appropriate solution for queue configuration. To verify that you have an appropriate version of Foomatic, please run foomatic-kitload or /usr/local/sbin/foomatic-kitload (if /usr/local/sbin is not on your PATH). Both Foomatic 2.0.x (old stable branch) and 3.0 (current stable branch) are supported. With Foomatic 3.0 there are the extra features of heaving an additional "PrintoutMode" option with pre-configurations for common printing tasks and the options being put into different groups ("General", "PrintoutMode", "Adjustment"). If you don't have Foomatic installed, or the version that is installed is too old, please download the current Foomatic 3.0x package from http://www.linuxprinting.org/download/foomatic/foomatic-current.tar.gz and follow the instructions in that package. See After Foomatic is installed, build the Foomatic data as follows: ./configure --with-foomatic make make install The "make install" step will add the necessary data to your Foomatic installation. It must be run as root. It will fail if Foomatic is not installed or your Foomatic is too old. Now you can either set up a queue for your printer with "foomatic-configure" (see USAGE file in the Foomatic package) or generate the printer description file for your spooler (with "foomatic-datafile") and configure your printer as described on the spooler-specific web pages of linuxprinting.org. IMPORTANT: Whenever you install a new version of Gutenprint you must re-create the printer queues using Gutenprint with Foomatic (these queues have a driver name of "gutenprint-ijs.5.0"). Note that it almost never makes sense to build the Foomatic driver without also building the Ghostscript driver, even if Foomatic is to be used with CUPS (CUPS-O-Matic). Please read the instructions below in the GHOSTSCRIPT section. If you do not wish to build the Gimp Print plugin, you must run ./configure --with-foomatic --without-gimp or ./configure --with-ghostscript --with-foomatic --without-gimp Please visit http://www.linuxprinting.org/foomatic.html for more information on Foomatic. Foomatic provides an alternate interface to CUPS, in addition to an interface to LPD, LPRng, GNUlpr, PDQ, PPR, CPS, and spooler-less printing. GHOSTSCRIPT Gutenprint includes an IJS-based Ghostscript driver. As paraphrased from the Ghostscript documentation, IJS is a relatively new initiative to improve the quality and ease of use of inkjet printing with Ghostscript. Using IJS, one can add new drivers, or upgrade existing ones, without recompiling Ghostscript. IJS drivers run as separate processes that communicate with Ghostscript via an IPC channel. As the basic IJS implementation is licensed compatibly with the GPL, and as the driver runs in a separate process from Ghostscript itself, the IJS driver may be used with AFPL Ghostscript (7.04 and above). The basic way to build the Ghostscript driver is ./configure --with-ghostscript [--without-gimp] make make install You must have the IJS libraries installed for this to work. Instructions for that are included with GNU Ghostscript 6.53 and beyond, AFPL Ghostscript 7.04 and beyond, and ESP Ghostscript 7.05 and beyond. We strongly recommend that end users not use this driver directly. The available options are very complex and are subject to change, and the standard printer configuration tools (such as apsfilter and magicfilter) do not provide a convenient interface to the driver's capabilities. We recommend that end users either install CUPS, as described above, or use Foomatic to configure printer queues, as described above. We no longer provide documentation on manual use of this driver. Gutenprint 5.0 no longer provides the monolithic "stp" driver present in 4.2. This driver, which was linked directly into Ghostscript, was very difficult to maintain and required a complex integration procedure. RECOMMENDED SETTINGS We recommend starting with all default settings for the color settings. The settings can be adjusted as necessary for particular combinations of ink, paper, and subject material. On most inkjet printers, using plain or coated inkjet paper, 600 or 720 dpi will produce high quality; 1200x1200 or 1440x720 dpi will produce extremely high quality. On newer printers with very small drops, or when printing photographs to special photo paper, higher resolutions such as 2880x1440 DPI may be required to achieve the highest quality. SUPPORT 1) Read the FAQ, in doc/FAQ.html. Your question may be answered there. 2) Read the user's manual, in doc/users_guide. 3) There are public forums on Sourceforge dedicated to this package. Please see http://sourceforge.net/forum/?group_id=1537 for more information. The Help forum is a good source of information. 4) If you have a technical support issue that does not appear to be a bug in the software, you can use the Tech Support Manager. Please see http://sourceforge.net/support/?group_id=1537. 5) If you have found a clear bug in the package, you may file a bug report at http://sourceforge.net/bugs/?group_id=1537. 6) You may send mail to the gimp-print-devel@sourceforge.net mailing list. This is recommended as a last resort only. KNOWN BUILD/INSTALLATION ISSUES This section describes a number of issues that have been encountered while building or installing Gutenprint. If any of these apply to you, please read the notes carefully. The issues are: 1) Building escputil may fail, or escputil may fail to run. 2) CUPS PPD files may not be translated (there may be multiple versions of the PPD files, all in English). 3) Build/installation of Foomatic data may happen correctly, but the generated PPD files do not work correctly. Detailed descriptions of these issues follow. * There is a known complication building "escputil" that causes problems on some systems. "escputil" uses the "readline" package, to support command editing and history within the program. Unfortunately, linking programs with "readline" often requires linking against additional libraries, and the exact library depends upon the system (e. g. not all Linux systems have the same requirements). The configure script attempts to determine which additional library must be linked against. It tries using the following libraries in this order to build a test executable: -lncurses -lcurses -ltermcap no additional libraries The reason it tries other libraries first is that some systems will link successfully, but only fail when an attempt is made to actually call readline. Therefore, we assume that additional libraries are required. Since we try the extra libraries in order from most recent to oldest, we expect that the first one we find will be appropriate. For example, if the "ncurses" library is the standard on a given system, the "termcap" library may be provided for back compatibility, but it is unlikely that "termcap" will be the standard with "curses" or "ncurses" being provided for compatibility only (so that the link will succeed but the command will use the incorrect library). As this procedure is not failsafe, we provide the following configure options to control this behavior: ./configure --with-readline=yes (the default; attempts to determine the correct library to link against) ./configure --with-readline=no (turns off use of readline altogether) ./configure --with-readline=only (specifically instructs configure to not attempt to link against any other libraries) ./configure --with-readline=libs (specifies the libraries to be linked against) An hypothetical (this won't work anywhere!) example of the latter would be ./configure --with-readline='-lncurses -ltermcap' Note that configure will not allow readline to be used if it cannot successfully build the test program, regardless of the option selected. If you are having difficulty getting escputil to build, we suggest using --with-readline=no. The commands used within escputil are very short and seldom require significant editing. * There is a known translation problem building the PPD files used by the CUPS driver such that on many systems all of the PPD files are in the English language. This causes CUPS tools, such as KUPS or http://localhost:631 to display many copies of each PPD file, all in the English (en) language. In fact, the PPD files should be translated into Swedish, Polish, Norwegian, French, Danish, Spanish, Slovakian, Greek, British English, Dutch, German, and Portuguese. With CUPS 1.1.10 and lower, there should be two copies of the (en) PPD file, and one copy each of (sv), (no), (fr), (pl), (da), (sk), (el), (es), (nl), (de), and (pt). With CUPS 1.1.11 and above, there should be (en), (en_GB), (sv), (no), (fr), (pl), (da), (sk), (el), (es), (nl), (de), and (pt) PPD files. The PPD files are created by a program named "genppd" in the src/cups directory. This program is called once for each language, and creates all of the PPD files for the language in one shot. The command 'zgrep' can be used to determine if genppd is creating the PPD files correctly, as follows: src/cups$ zgrep LanguageVersion ppd/*/pcl-4.ppd.gz ppd/C/pcl-4.ppd.gz:*LanguageVersion: English ppd/da/pcl-4.ppd.gz:*LanguageVersion: Danish ppd/en_GB/pcl-4.ppd.gz:*LanguageVersion: English-GB ... If the PPD file for each language has a different language version, the genppd program operated correctly. If instead the output looks like this: src/cups$ zgrep LanguageVersion ppd/*/stp-pcl-4.5.0.ppd.gz ppd/C/stp-pcl-4.5.0.ppd.gz:*LanguageVersion: English ppd/da/stp-pcl-4.5.0.ppd.gz:*LanguageVersion: English ppd/en_GB/stp-pcl-4.5.0.ppd.gz:*LanguageVersion: English ... the program did not operate correctly. If you do not have 'zgrep' on your system, you can gunzip the PPD files, and use grep LanguageVersion ppd/*/stp-pcl-4.5.0.ppd to accomplish the same test. The normal mechanism for performing translations is to set the LANG environment variable to the appropriate language prior to running the program. This normally causes the program to search the translations (normally in /usr/share/locale or /usr/lib/locale) for the chosen language. When a specially marked string is used, a special macro calls `gettext()' on the string to retrieve the translation, and substitutes the translation for the string in question. There are two problems with this approach in the context of genppd. The translation engine is intended to be used after installation, not during build, and this causes problems. 1) At the time genppd is run, the translations have not been installed in the normal system directories. Fortunately, it's possible to tell the translation machinery (via bindtextdomain) to look elsewhere for the translation catalogs. What we do is install the catalogs in a temporary directory under src/cups, and tell genppd to instruct the translation machinery to look there. This workaround is straightforward, and doesn't normally cause problems. 2) LANG only lets us pick a valid locale (normally determined by listing the directories in /usr/share/locale or /usr/lib/locale). Unfortunately, while language codes (which form the base of locales) are standard, the actual locale names aren't always. On some systems, the locale names are just the language base names; on others, they are the language names concatenated with country codes (e. g. en_US), while on others they are language codes concatenated with character sets. We are not aware of any workaround for this, possibly short of actually running make install and then rebuilding the PPD's. 'make install' will install the message catalogs, and that may create the necessary locale directories. This is not exactly a very elegant approach. The GNU gettext library (libintl.a) provides another environment variable, LANGUAGE, which unconditionally looks up translations according to the language, ignoring LANG and the LC_* environment variables that are normally used for translation. This library is no longer included with Gutenprint (--with-included-gettext will not work). Install the GNU gettext package first if you need libintl.a. Many systems provide translation machinery in their standard libraries, and it may not always be best to use foreign libraries to replace standard system functionality. We have chosen to use LANGUAGE for this purpose, as the GNU gettext library appears to offer the most reliable translation, and LANGUAGE appears to offer the most reliable mechanism. We have actually found that LANG and LC_* can interfere with LANGUAGE, thus we do not use both. To determine if the translations are working, you must actually inspect the PPD files. You will need to cd src/cups/ppd/sv gunzip * more * or the like to determine if this is successful. In particular, look for LanguageVersion, and make sure that it is correct (it should be "Swedish" in the sv directory, for example), and also make sure that the paper sizes are also translated. We currently suggest using the Swedish translation for this purpose as it is the most complete. If packagers find that the PPD files are all in English, rather than translated into the appropriate languages, we suggest the following: 1) Install GNU gettext (libintl). If your system is not based on GNU libc (Linux usually is based on GNU libc; BSD, Solaris, IRIX, etc. are not), you will need this to have any possibility of creating the translated PPD files. 2) Run 'make install' to install the package (including the message catalogs) onto the system first, and then do the following: cd src/cups rm ppd-stamp make to rebuild the PPD files. Having the message catalogs on the system may permit this to succeed. 3) Ensure that your system actually has locales named 'sv', 'pl', and all of the other supported languages, and change LANGUAGE to something more appropriate (most likely LANG, LC_MESSAGES, or LC_ALL). 4) Build the PPD files on a Linux-based system; they are portable. 5) Use --disable-translated-cups-ppds on the configure command line to suppress the translated PPD files altogether. Please feel free to contact us about this issue. * There are multiple issues that one must be aware of when using Foomatic with Gutenprint. 1) Before installing Gutenprint 5.0.0-rc1, you must manually remove any existing Foomatic option files. This is because the Foomatic utility to load data kits (foomatic-kitload) does not remove obsolete data files from the Foomatic database. If you do not do this, any PPD files you generate will be incorrect and printing may work incorrectly or not at all. Foomatic option files are usually located in /usr/local/share/foomatic/db/source/opt or /usr/share/foomatic/db/source/opt Assuming they're in the former location, you must remove data files associated with the Gutenprint driver. The command to do this, which must be run as the superuser (root) is cd /usr/local/share/foomatic/db/source/opt ls -l gutenprint-ijs*.xml If there are existing files present, you must remove them: rm -f gutenprint-ijs*.xml Now check to make sure that they are gone: ls -l gutenprint-ijs*.xml CAUTION: Be very careful when typing this command! Minor errors in typing these commands may result in severe damage to your system. After this, you may run 'make install' in your Gutenprint source directory to install the package. You will then need to re-create any printer queues using Foomatic. In general, you will have to perform this procedure any time you install a new version of Gutenprint. Please check the Foomatic site (http://www.linuxprinting.org/foomatic.html) and the Gutenprint site (http://gimp-print.sourceforge.net) for updated instructions about this. 2) Unlike with the CUPS native driver, there is no simple way to update all PPD files when you install a new version of Gutenprint. You must either use the foomatic-ppdfile command to upgrade PPD files individually, or foomatic-compiledb to build all PPD files. From this point forward, the Foomatic data will be version locked to the Gutenprint release installed on the system. For example, PPD files generated with the Foomatic data for this release will not work with the ijsgutenprint in the next release. This is to prevent accidentally using incorrect data, which could cause incorrect function to take place. PACKAGING We recommend that packagers and distributors of Gutenprint use the following settings to build the package: --with-foomatic --with-ghostscript --with-user-guide --with-samples --with-escputil We suggest the following packaging: * A Gutenprint core package should contain the following. You may wish to install the user's guide only in certain formats. /usr/lib/libgutenprint.so.2.x.y (the core shared library) /usr/bin/escputil (Epson Stylus utility) /usr/bin/ijsgutenprint.5.0 (Gutenprint Ghostscript IJS plug-in driver) /usr/share/gutenprint/doc/html (HTML documentation) /usr/share/gutenprint/doc/users-guide.pdf /usr/share/gutenprint/doc/users-guide.ps /usr/share/locale/*/LC_MESSAGES/gutenprint.mo * A gutenprint-devel package (for developers) should contain the following. Again, you may wish to install the programmer's manual only in certain formats. /usr/include/gutenprint /usr/bin/gutenprint-config /usr/share/gutenprint/doc/manual-html /usr/share/gutenprint/doc/gutenprint.ps /usr/share/aclocal/gutenprint.m4 /usr/lib/libgutenprint.a /usr/lib/libgutenprint.so You may wish to include the test pattern generator source and the sample test pattern in this package, and you may wish to include test patterns of your own. You may also wish to include the various unprint programs and the parse-* scripts from the test directory, although these are typically of more use to developers of the Gutenprint package per se than developers of applications layered on Gutenprint. However, the test programs have received less testing than the others, and are known to have some limitations that are not documented. * A gutenprint-extras package should contain /usr/share/gutenprint/samples You may wish to include the test pattern generator and the sample test pattern from src/testpattern if you don't include it in the developer package; test/unprint; test/pcl-unprint; test/bjc-unprint; test/parse-escp2; and test/parse-bjc in this package. * Ghostscript requires GNU Ghostscript 6.53 or above, or ESP Ghostscript 7.05 or above. * CUPS packages should include the gutenprint PPD's in /usr/share/cups/model, and the following utilities: + "epson" and "canon" belong in /usr/lib/cups/backend. + "rastertogutenprint-5.0", "commandtoepson", and "commandtocanon" belong in /usr/lib/cups/filter. + "cups-calibrate" belongs in /usr/bin. + "command.types" belongs in /etc/cups. + "calibrate.ppm" belongs in /usr/share/cups. The PPD's packaged with gutenprint are rather bulky, about 1 MB for each language installed. At present, twelve language translations are installed, in addition to the US English defaults: GB English, Swedish, Danish, Norwegian, French, Polish, Slovakian, Greek, Spanish, Dutch, German, and Portuguese. You may wish to install these selectively. Please see KNOWN BUILD ISSUES above for more discussion about build issues related to the PPD files. * A gutenprint-foomatic package, containing the src/foomatic/foomatic-db/gutenprint*/ directories, should be provided to allow people who wish to use foomatic to install the corresponding data files. The packaging should arrange to call "foomatic-kitload" (or the equivalent) on this tree when it is installed. An alternative option is to install pregenerated PPD files, which may be created with foomatic-compiledb. * Please read the release notes carefully! * Distributors (UNIX vendors and Linux distributors) should subscribe to the gimp-print-devel@sourceforge.net mailing list to monitor development activities. When reporting a problem related to building the package for distribution, please identify yourself as such. The Gutenprint package is primarily an infrastructure package, rather than an end-user application, and as such we particularly want to fix any problems that interfere with building and distribution of this package on any POSIX-compliant operating system. DEBIAN The Debian packaging has been rewritten from scratch in 4.2. It is compliant with Standards-Version 3.5.6.0, and is lintian-clean. It should build from source on woody and sid, but will not build on potato. There are seven separate packages: gimp1.2-print The GIMP Print plugin. Also contains HTML and SGML documentation that is registered with doc-base. cupsys-driver-gutenprint The CUPS driver and PPD files. ijsgutenprint Ghostscript IJS server. foomatic-db-gutenprint Foomatic data files for gutenprint drivers. libgutenprint1 The libgutenprint library (Gutenprint core). libgutenprint1-dev Headers, symlinks, m4 macro (AM_PATH_GUTENPRINT) and gutenprint-config needed to develop programs that link with libgutenprint. gutenprint-doc User's Guide in HTML and PDF format libgutenprint1-doc Programmer's Guide in Info, DVI and HTML format. gutenprint-locales Message catalogues for internationalisation. escputil The escputil printer tool for Epson printers. The library symlinks will get packaged without any modification needed to the debian packaging whatever library versioning scheme is used. Most packages depend on libgutenprint as this will provide translations for i18n in the future that they will use, or they require libgutenprint anyway. The newer Debian gs packages (>= 5.50) are linked with libgutenprint, so you need not do any patching! However, if you compile a newer version of libgutenprint, the newer version will be used by ghostscript. USE OF THE CVS REPOSITORY Please read doc/README.maintaining for instructions on how to build from the CVS repository.