path: root/NEWS

Welcome to Gutenprint 5.3.0-pre1, an initial development release for
5.3.  Please read these release notes carefully.

Gutenprint is a suite of printer drivers for UNIX, Linux, and
Macintosh OS X systems (10.6 and above) that use CUPS as their
printing system.  Gutenprint currently supports over 2800 printers.
It also includes an enhanced Print plug-in for GIMP that replaces the
print plug-in packaged with the GIMP distribution.

*** NOTE TO PACKAGERS: Please read the file README.package for issues
    that are of interest to distributors and packagers of Gutenprint.
    It is not necessary for end users of Gutenprint to read this file.

These release notes contain the following sections:

I)    General Requirements
II)   Changes from Previous Releases
III)  Exceptions and Workarounds
	A) General Issues
	B) Printer-Specific Issues
	C) Build/Installation Issues
IV)   Overall changes from Gutenprint 5.2.13
	A) General User-visible Changes
	B) New Functionality
	C) Changes to the Enhanced Print plugin for GIMP
	D) Changes to the CUPS interface
	E) Architectural Changes
V)    Critical Upgrade Note from Gutenprint 5.0 or Earlier

================================================================

I) GENERAL REQUIREMENTS

Gutenprint will run on any reasonably modern computer running Linux,
Macintosh OS X (10.6 or above), Solaris, or any other UNIX-like
operating system.  If you plan to compile this package from source,
you will also need an ANSI C compiler, such as gcc (recommended).  A
compiler is not required if you are installing a pre-compiled package.

Processor and memory requirements vary depending upon the printer and
runtime options selected; it is suggested that you have at least 64 MB
of memory for general purpose printing, 256 MB or more for high
quality printing on a good printer, and 1 GB or more for large format
printing at high resolution.  You should have at least 50 MB of free
disk space to compile and install Gutenprint.  Disk space requirements
for printing will vary depending upon how you use Gutenprint, but are
generally modest except as noted below.  We recommend a processor
speed of at least 300 MHz.  Fast printers may require a faster
processor to achieve maximum printing speed.

For general use, you should have the Common UNIX Printing System, CUPS
(version 1.1.15 or above).  Please the rest of the release notes, in
particular the Exceptions and Workarounds, for full details on
installation, as there is important information to be aware of.  CUPS
is the printing system used on Macintosh OS X 10.3 and above, and many
other systems use it.  The combination of CUPS and Gutenprint provides
a flexible, general purpose printing system capable of producing the
highest quality output with any of the printers supported by this
package.  We strongly recommend using CUPS with Gutenprint as a
general-purpose printing solution.

The enhanced Print plug-in for GIMP requires GIMP 2.0 or above (GIMP
2.2 recommended).  This plug-in will work with any printing system,
and offers a comprehensive user interface to control all aspects of
the printing process.  If you are printing photographs in large format
from GIMP at very high resolution, disk space requirements may be
substantial, and we recommend at least 2 GB of free disk space for
that purpose.

Users of Macintosh 10.6 (Snow Leopard) and above can use this package.
For ease of installation, a pre-built package with installer is
normally supplied a few days after the release of the source package.
We strongly recommend that OS X users use the pre-built package rather
than attempt to build it themselves.  Packages are not always supplied
for development releases.

The README file included with this package provides full instructions
for building and installing Gutenprint.
================================================================


II) MAJOR CHANGES FROM PREVIOUS RELEASES

* This is the initial 5.3 pre-release.  Please refer to the release
  notes from Gutenprint 5.2.13 and the Overall Changes from 5.2.13
  below.


================================================================


III) EXCEPTIONS AND WORKAROUNDS

A) GENERAL ISSUES

  1) The Canon, Hewlett-Packard, Lexmark, and dye sublimation drivers
     do not offer all of the additional options and improvements that
     the Epson driver does.  Please contact us if you would like to
     assist with making these options available (requires C
     programming skills).


----------------

B) PRINTER-SPECIFIC ISSUES

  1) A number of Epson printers have been reported to produce poor
     quality at the bottom of the page in borderless mode when the
     resolution is set to 5760x2880 DPI.  The specific problem
     observed is that the print fades at the bottom of the page.
     Other than reducing the resolution or avoiding use of borderless
     mode, there is no known workaround for this problem.

  2) There have been reports of poor color fidelity on the Epson
     Stylus Photo R2880 with certain paper types.  This problem has
     not been reproduced.

  3) A number of laser printers capable of large format printing are
     incorrectly classified as small format, thereby not permitting
     users to select large paper sizes.  The workaround is to use the
     printer named "Generic PCL 6/PCL XL LF Printer".  Please report
     any such printers to gimp-print-devel@lists.sourceforge.net; they
     will be fixed in the next available release.

  4) Color laser printers are currently supported only in black and
     white mode.  At present, we do not have resources to add a color
     laser driver.  If you have interest in this area and the
     requisite skills, please contact
     gimp-print-devel@lists.sourceforge.net.


----------------

C) BUILD/INSTALLATION ISSUES

  1) With certain versions of CUPS and in certain non-default
     configurations, if a new version of Gutenprint is installed over
     an existing version genppd will create PPD files based on the
     older version of Gutenprint rather than the newer version.  This
     will happen if all of the following are true:

     i) The cups-config provided by the CUPS driver adds
        -Wl,rpath=/usr/lib. This is done by some versions of CUPS
        reportedly because in some cases the runtime linker does not
        pick up libraries out of /usr/lib.  This can be checked by
        running

        cups-config --libs --ldflags

        and inspecting the output for any mention of "rpath", "RPATH",
        "RUN_PATH", or the like.  This is controlled by the CUPS
        installation on your system.

     ii) There is presently a version of Gutenprint installed in /usr
        (--prefix=/usr) rather than /usr/local or the like.  The
        default location of Gutenprint installation is in /usr/local,
        but system vendors typically install Gutenprint in /usr.

     iii) Gutenprint is built dynamically only (--disable-static or
        --disable-static-genppd).  This is not a default, and requires
        the explicit --disable-static or --disable-static-genppd on
	the Gutenprint "configure" command line.  Therefore, if you
	build Gutenprint normally you should not be vulnerable to this
	problem.

     Note that in general if you install CUPS into a non-standard
     location, and install Gutenprint into the same location, this
     problem can surface.  For example, if you choose to install CUPS
     in /usr/local and Gutenprint in /usr/local you are vulnerable to
     this.  However, it is not standard practice to install CUPS
     anywhere but /usr.

     In this case, the run path embedded in the genppd executable
     points to the version of Gutenprint installed in /usr/lib.  This
     run path overrides any attempt by libtool to look in the build
     directory.  The result is that cups-genppd and rastertogutenprint
     are run against the older version of Gutenprint.  If the new
     version contains additional features (more printers, changes to
     printer options, etc.) they will not be available.

     This bug is difficult to detect in a normal build.  It normally
     does not cause an error to happen during build unless there is an
     API change from the version installed and the version being
     built; the only failure is frequently that some PPD files may not
     be built or may be built with missing options.  Due to the PPD
     version checking introduced in this release, the behavior might
     manifest itself as a runtime error.  It is also possible that
     there will be no error at all other than the older version of
     Gutenprint being used, with the result that new features and bug
     fixes are not available.

     If you wish to use only shared libraries, do not wish to build
     static libraries at all, and are vulnerable to this issue
     (because cups-config --ldflags sets the run path), there are
     three workarounds available:

     i) Build and install Gutenprint into /usr (rather than
        /usr/local) and then rebuild Gutenprint from scratch.  This
        will install the correct libgutenprint.so in /usr/lib, and in
        the rebuild genppd will be run against the correct library.

     ii) Remove the old version of Gutenprint prior to building the
        new version of Gutenprint.  The important files to remove are
        anything named /usr/lib/libgutenprint*.

     iii) Edit cups-config to remove the reference to the run path.

  2) There is a known complication building "escputil" that causes
     problems on a small number of 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/UNIX
     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)

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

================================================================

IV) OVERALL CHANGES FROM 5.2.13 to 5.3

A) GENERAL USER-VISIBLE CHANGES

   1) It is now possible to specify units in fractional point sizes,
      allowing more precise placements and page sizes.


B) NEW FUNCTIONALITY

   1) All units are now floating point rather than integer.


C) CHANGES TO THE ENHANCED PRINT PLUGIN FOR GIMP

   1) Units can be entered in fractional point sizes as well as
      Imperial and metric sizes that are not exact numbers of points.


D) CHANGES TO THE CUPS INTERFACE

   1) Units can be entered in fractional point sizes as well as
      Imperial and metric sizes that are not exact numbers of points.


E) ARCHITECTURAL CHANGES

   1) All units are now floating point rather than integer.


================================================================

V) CRITICAL UPGRADE NOTE FROM GUTENPRINT 5.0 OR EARLIER

This note does not apply to initial installations of Gutenprint,
upgrades from any 5.2 release, or to Macintosh users; if this
describes you, you should skip this section.

If you are using CUPS with Gutenprint on a non-Macintosh system, and
are upgrading from Gimp-Print 4.2 or a version of Gutenprint prior to
5.2, please read this note carefully as there are special procedures
that you should follow in addition to the normal procedure of running
cups-genppdupdate.

Background: older versions of Gutenprint distributed CUPS backends,
named "epson" and "canon", that we have determined have compatibility
problems on certain systems.  The symptom of this problem is that the
last page of each print job does not complete; it prints almost to the
end of the page, and the printer stops.  The only way to clear this
condition is to power the printer off and back on after each job.

A CUPS "backend" is a special program whose purpose is to transfer
data from the printer driver to the printer itself.  CUPS provides a
number of general purpose backends.  The "epson" and "canon" backends
previously provided with Gutenprint are capable of retrieving ink
level information from Epson and Canon inkjet printers respectively.
These backends are no longer needed in CUPS 1.2, and are not strictly
necessary in CUPS 1.1.  Therefore, these backends have been removed
from Gutenprint as of 5.2.

Due to a subtle issue, these backends may not correctly send all of
the data to the printer on some systems.  While we have not fully
characterized the systems on which this happens, it appears likely
that it is on certain operating system versions.  The backend believes
that all data has been sent, but the way it does I/O results in some
data not being sent on all systems.  As a result, the printer
continues to wait for more data to be received.

We recommend that if you have any printer queues using these backends
that you modify the queues to use a different backend.  Even if you
are not currently having problems, we recommend that you do this, as a
future operating system upgrade may result in this problem becoming
visible.  If this is the first version of Gutenprint or Gimp-Print you
have installed on your system, you should not have these backends
present.  Here are the steps we recommend that you follow.

1) Determine whether any printers on your system use the epson or
   canon backends.

   This can be determined via "lpstat -v".  This may be done without
   administrator privileges:

      $ lpstat -v
      device for EPSON_Stylus_Photo_R300_USB_1: usb://EPSON/Stylus%20Photo%20R300
      device for espr300-ez: usb://EPSON/Stylus%20Photo%20R300
      device for r300-test: epson:/dev/usb/lp0
      device for HP_LaserJet_1022_USB_1: usb://HP/LaserJet%201022

   Inspect each device line for a device that begins with "epson:" or
   "canon:".  These are the queues you must modify.  In this case, the
   only queue that must be modified is "r300-test".  The other queues
   all have devices that begin with "usb:"; these queues use the
   standard CUPS USB backend that does not have this problem.

2) For each queue that uses the epson or canon backend, modify it to
   use an appropriate backend.

   If your system provides a user interface for administering
   printers, we recommend that you use that interface.  If you're
   comfortable with the KDE or GNOME print manager, you may use that
   interface.  However, we recommend using the CUPS web interface
   (http://localhost:631/printers) to modify the printer.  The steps
   you should follow (assuming that you are using the CUPS web
   interface) are:

   i) Click "Modify Printer", to start leading you through a series of
      screens allowing you to change the printer properties.

   ii) The first screen, entitled "Modify Printer r300-test" (the
      printer name, of course, will vary), will display the name of
      the printer, along with the location and description.  You may
      modify these if you wish, but it isn't necessary.  Click
      "Continue".

   iii) The next screen, entitled "Device for r300-test", is the
      important one.  This provides you a drop-down list of devices.
      These devices typically include "AppSocket/HP JetDirect",
      "LP#1", and so forth.  It is critical that you select the
      correct device at this point.

      The entries that you want are of the form

      EPSON Stylus Photo R300 USB #1 (EPSON Stylus Photo R300)

      or

      EPSON Stylus Photo EX Parallel #1 (EPSON Stylus Photo EX)

      Make sure to select the one that's appropriate for your printer
      model.

      You will likely also see entries such as "Gutenprint USB Printer
      #1 (EPSON USB2.0 Printer (Hi-speed)".  These are the entries
      corresponding to the "epson" and "canon" backends, and you must
      avoid these.

   iv) The next screen, entitled "Make/Manufacturer for r300-test",
      allows you to select the manufacturer of the printer.  Normally,
      the correct manufacturer (Epson or Canon) will be highlighted,
      and you can click Continue.

   v) The next screen, entitled "Model/Driver for r300-test", allows
      you to select the precise model of the printer.  Normally, the
      correct model (which will be named something like "Epson Stylus
      Photo R300 - CUPS+Gutenprint v5.3.0-pre1") will already be
      highlighted, and you can click "Modify Printer".  Otherwise, you
      must find and select the correct printer model before clicking
      Modify Printer.  You will likely need to provide your
      administrator username and password to continue here.

      After this, you should see a message "Printer r300-test modified
      successfully".

3) Remove the epson and canon backends.

   On most systems, the backends will be named
   /usr/lib/cups/backend/canon and /usr/lib/cups/backend/epson.  On
   some systems, the backends will be named
   /usr/lib64/cups/backend/canon and /usr/lib64/cups/backend/epson.
   They may be present in other locations, but these are the most
   common locations.  If these files are present, you should create a
   directory named /usr/lib/cups/old-backend or
   /usr/lib64/cups/old-backend, and move the epson and canon backends
   there just in case you later need them.

      % cd /usr/lib/cups
      % sudo mkdir old-backend
      Password: <type your administrator password>
      % cd backend
      % sudo mv canon epson ../old-backend
      Password: <retype your administrator password if prompted>

The specific underlying technical problem appears to be that when at
least certain devices are in non-blocking mode (O_NONBLOCK or
O_NDELAY) with certain operating system versions (Linux 2.6.25 appears
to be suffer this problem, and most likely some other versions also
do), the close() call does not result in all data being flushed to the
device.  We have determined that the data is in fact written by the
"epson" process, but it's never getting to the printer.