ANNOUNCEMENT: Foomatic 3.0.0 released!

Till Kamppeter till.kamppeter at gmx.net
Wed Apr 30 21:31:54 CEST 2003


Oi,

this is Foomatic 3.0.0, the first stable release in the Foomatic 3.0.x
series.

Compared to Foomatic 2.0.x a lot has changed: For all spoolers the same
PPD files are used now to provide the printer/driver capability
information and there is also only one filter ("foomatic-rip") which is
used with all spoolers. The PPD files are fully Adobe-compliant now and
do not contain embedded Perl data any more. foomatic-rip also supports
the use of manufacturer-supplied PPD files for PostScript printers with
all spoolers. Other features are composite options, page-wise option
settings, unprintable margin definitions, ...

Give your comments and suggestions for the further development on the
Foomatic Development List/Newsgroup on linuxprinting.org.

See details and how to proceed below.

Happy printing!

     Till


Changes
-------

Compared to Foomatic 2.0.x

  - For all supported spoolers (CUPS, LPRng, LPD, GNUlpr, PPR, PDQ, CPS,
    no spooler) the same PostScript-to-printer's-native-language filter
    (RIP, Raster Image Processor), foomatic-rip is used. foomatic-rip
    detects automatically from which spooler it is called.

  - foomatic-rip gets the info about the printer's capabilities and the
    driver options and default settings always from PPD files,
    independent which spooler is used. It is possible to use
    Foomatic-generated PPD files (usually for non-PostScript printers) or
    manufacturer-supplied PPD files of PostScript printers. So

     o PPD files of PostScript printers can be used with every spooler,
       not only with CUPS and PPR and on all spoolers all options will be
       available. So PostScript printers work always "Perfectly".

     o With the PPD file one has one configuration file for every place
       where information about the printer and its options is needed:
       The print queue itself, PPD-aware applications (as Star Office,
       OpenOffice.org, GIMP, ...), and clients (Windows, Mac, Unix with
       arbitrary spooler). The PPD format is a standard format used by
       every modern operating system.

  - PPD building and PostScript processing is done according to the
    Adobe specifications DSC (Document Structuring Conventions) and
    PPD (PostScript Printer Description) as published on

    http://partners.adobe.com/asn/tech/ps/technotes.jsp

  - foomatic-rip inserts all default settings from the PPD file (so you
    can edit the "*Default..." lines in the PPD files to set the
    defaults), reads option settings from the user's command line, and
    from the PostScript data stream. Settings in the PostScript data
    stream have the highest priority to assure that what one sets in an
    application is used. Depending on the option type the settings are
    applied to the renderer's (usually GhostScript's) command line, to
    the JCL header, or stuffed in at the right place of the PostScript
    data stream.

  - Support for option settings only acting on a certain page selection
    (example: First page on letterhead paper from tray 1, rest on plain
    paper from tray 2). Settings must be put into the
    "%%BeginPageSetup"/ "%%EndPageSetup" sections (or at least right
    after the "%%Page:" comments) of the appropriate pages in the
    PostScript input file. They can also be specified on the command
    line by specifying a page range before the option name (ex: "lpr -o
    1,5-8:ColorMode=CMYK file.ps"). If necessary, the renderer (usually
    GhostScript) is stopped and restarted in the middle of the job,
    when certain pages need a different command line for the
    renderer. The bug of Star Office/OpenOffice.org inserting the
    "%%BeginSetup...%%EndSetup" section after the first "%%Page:"
    comment is taken care of.

  - foomatic-rip does neither use temporary files on the disk, nor does
    it need to load huge documents completely into memory. All is done in
    data streams where not more data than necessary is buffered. To make
    this possible foomatic-rip forks into up to six sub-processes.

  - The installation is very easy, one needs only foomatic-rip
    (absolutely monolithic, no Perl modules needed), a PPD file, and
    optionally foomatic-gswrapper. No different files for different
    spoolers.

  - Custom page size support with all spoolers when the PPD file has
    Adobe-compliant definitions for usage of custom page sizes.

  - The spooler-less printing mode of foomatic-rip can be used for
    testing and debugging PPD files in arbitrary directories, one simply
    specifies them with the new "--ppd" option.

  - With PDQ one can print arbitrary file types now, and even set up raw
    printers. The PDQ driver files are generated by foomatic-rip, so
    the user does not need to download more files than with other
    spoolers.

  - Under PPR 1.50 and newer foomatic-rip runs as a PPR RIP, under older
    versions, as before, as a PPR interface.

  - foomatic-configure sets up printer queues based on Foomatic database
    entries, arbitrary third-party PPDs (as shipped with PostScript
    printers), or raw queues.

  - foomatic-configure is much faster when copying or modifying print
    queues now, as it does not rebuild the PPD from the Foomatic database
    all the time (as long as one does not force a rebuild with "-f").

  - foomatic-addpjloptions works also in regular installations now, not
    only in "inplace" installations.

  - foomatic-compiledb generates only PPD and XML files now.

  - foomatic-datafile is renamed to foomatic-ppdfile, a compatibility
    link named foomatic-datafile is set. foomatic-ppdfile generates
    only PPDs, the options "-t" and "-f" are ignored.

  - foomatic-configure, foomatic-printjob, and all the other scripts
    have the same command lines as in Foomatic 2.0. Exceptions: In
    foomatic-configure "--oldppd" was dropped, "--ppd" (for setting up a
    queue with a third-party PPD file) added, and the meaning of "-f"
    (force rebuild of PPD) changed.

  - Option groups: Options can be put into groups and subgroups in the
    PPD files, so that GUIs can present them in a structured way (in
    tabs or in a tree structure). It is nearly completely functional,
    the only thing missing is translation support ("long names" for the
    groups, as "Adjustments and Corrections" for "Adjustment", or
    translations to other languages). Now the PPD generator makes
    trivial translations ("ThisIsAGroup" -> "This Is A Group")
    automatically.

  - Composite options: This is a new option type to make it easier for
    users to choose the best settings for a certain printing task,
    especially if the driver has very many options. The idea is to have
    an enumerated choice option which does not directly modify
    something in the driver's command line but sets several of the
    other options.

    We will have a "Printout Mode" option for all printers with the
    following choices:

       Draft
       Normal
       High Quality
       Very High Quality
       Photo

    For an Epson Stylus Color 680 with GIMP-Print it sets the options
    resolution, ditherering, and image type as follows:

       Choice           Resolution     Dither            ImageType
       ------------------------------------------------------------------
       Draft            180x180 dpi    Very Fast         LineArt
       Normal           360x360 dpi    Adaptive Hybrid   Photographs
       High Quality     720x720 dpi    Adaptive Hybrid   Photographs
       Very High Qual.  1440x720 dpi   Adaptive Hybrid   Photographs
       Photo            2880x720 dpi   Even Tone         Photographs

    The mentioned settings set all the color mode to "Color", there
    are also choices with a ".Gray" modifier (ex: "Normal.Gray" which
    set the color mode to "Grayscale", but the other mentioned options
    as the standard variants ("Normal").

    The member options of the composite option all get one choice
    called "FromPrintoutMode"/"Controlled by 'Printout Mode'" added,
    which gets their default setting. If this choice is selected, the
    option is set by the composite option according to the table. If
    the user wants to modify one of the individual member options, he
    simply chooses a value other than "FromPrintoutMode" for this
    particular option. In addition the member options will be put into
    a group (named "Printout Mode"). and the composite option goes into
    the same group as "PageSize", "InputSlot", ... So the user sees the
    composite option on the "Front page" of the GUI and can quickly set
    up print jobs without getting confused. The user with more special
    demands goes to the tab with the member options and makes detailed
    choices.

  - Forced composite options: These are special composite options where
    the user cannot set the individual member options, but only the
    composite option (the user is forced to use the composite
    option). This allows options acting at two or more places, for
    example a "PageSize" option for a driver which is a filter
    translating GhostScript bitmap output to the printer's
    language. One lets one member option be an option inserting
    PostScript code for the page size into the PostScript input data
    stream for GhostScript, and another member option insert the
    correct bitmap size into the filter's command line. The user sees
    only the composite option and sets the paper size with it as usual.

  - String and password options: These options allow the user to supply
    nearly arbitrary strings (a length limit and restrictions be a list
    of allowed characters or a Perl regular expression can be set) to
    the printer driver, for example names of color calibration files,
    fax numbers, passwords for confidential jobs, ... Frequently needed
    strings can be added as enumerated choices, so a frontend can show
    the option as a combo-box. The enumerated choices are also used for
    frontends which only support options as defined by the PPD spec.

  - New handling of numerical options in the PPD files:
    "*Default<option>: ..." now always contains one of the enumerated
    choices to be Adobe-compliant, the exact default value for
    Foomatic-aware applications is stored with the new
    "*FoomaticRIPDefault<option>: ..." keywords now.

  - URIs (Unified Resource Identifiers, the descriptions for the
    printer connection type used with the "-c" option of
    foomatic-configure) are exactly the same as under CUPS now. The
    only difference was that before for local printers always URIs
    beginning with "file:" were used, now "parallel:", "usb:", or
    "serial:" is used. The old form with "file:" is still accepted
    for compatibility.

  - For USB printers CUPS 1.1.17 and newer supports URIs which refer to
    manufacturer, model, and serial number and not to the device file
    (/dev/usb/lp*) any more. This way the queues still work when the
    printers are plugged in or turned on in another order in a later
    session (the printers can get different device files
    then). Foomatic now automatically converts the conventional USB
    URIs to the new ones when an appropriate versions of CUPS is used.
    When copying a queue to another spooler the URI is converted back
    in the copied queue.

  - Support for the MTink daemon from the MTink package
    (http://xwtools.automatix.de/). MTink allows monitoring the ink
    levels of Epson inkjets also while printing.

  - Non-printable margins: Both printer and driver XML database entries
    should get a new section for unprintable margins, so that the
    "*ImageableArea" entries in the PPD files can be correctly set.
    Entries should be possible for printers (printer XML file), for
    drivers (main part of driver XML file), for printer/driver combos
    (in printer list of driver XML file), and they can contain general
    margins (valid for all paper sizes) and paper-size-specific margins.
    If for one "*ImageableArea" entry in a PPD file more than one of the
    above mentioned possible margin entries applies, the "worst case"
    (individually determined for each page border) is inserted. If the
    unprintable margins of a printer depend on options settings, the
    "worst case" is chosen, too.

  - Facility to make a package consisting of all possible Foomatic PPD
    files, foomatic-rip, and foomatic-configure, see
    README.build-foomatic-filters-ppds for how to proceed.

  - Support for inserting arbitrary constant entries (as a default
    resolution if there is no "Resolution" option) into the PPD
    file. The entries can be printer-specific, driver-specific, or
    printer/driver-combo-specific.

  - Extended structure for auto-detection info in printer XML files:
    General section for entries valid for both USB and parallel port
    connection, possibility to insert the constant part of the original
    IEEE-1284 ID string. The ID string will also be inserted into the
    PPD file.

  - Added a facility to chnage all the cryptic numerical printer IDs
    from the old PostGreSQL time to clear-text printer IDs. With a
    translation function it is assured that one can still use the old
    IDs, for example to not break links to the linuxprinting.org web
    site.

  - The Foomatic database uses clear-text printer IDs for all printers
    now.

Compared to Foomatic 3.0.0rc2

- Limitation of the length of the "*ShortNickName" fields in the PPD
   files to 31 characters to fulfill the Adobe specifications

- Fixes on translating old numerical printer IDs

- Documentation fixes


To do
-----

(for 3.0.1, 3.0.2, ...)

  - Option conflicts: PPDs allow to define conflicts between option
    settings, so that one cannot set up things which the printer cannot
    do or which dont make sense (Duplex on transparencies, printing from
    tray 4 when only 2 trays are installed, ...).

  - Printer and driver classes: The class XML files should look like
    printer or driver entries, with the same fields and with an
    additional member list. If one marks an option or an option choice as
    being valid for a class, it is valid for all member printers and
    classes, If a printer or driver is a member of a class, all fields
    which are left blank in this entry, are filled in with the value
    defined in the appropriate field of the class. If the class contains
    a comment text, it is shown in addition to the printer's or driver's
    own text. This saves from a lot of duplicate entering of data when
    adding printers, drivers, options, choice, option groups, or option
    conflicts to the database.


Packages
--------

The release consists of four packages, to be installed in the given order:

http://www.linuxprinting.org/download/foomatic/foomatic-filters-3.0.0.tar.gz
http://www.linuxprinting.org/download/foomatic/foomatic-db-current.tar.gz
http://www.linuxprinting.org/download/foomatic/foomatic-db-hpijs-1.3.1-4.tar.gz
http://www.linuxprinting.org/download/foomatic/foomatic-db-engine-3.0.0.tar.gz

Please read the USAGE files to know how to install and use these
packages. You do not necessarily need to install foomatic-db-hpijs, you
only need it when you want to use a printer with the HPIJS driver.

Uninstall any old version of Foomatic before you install these packages.

To set up print queues for any supported spooler (CUPS, LPRng, LPD,
GNUlpr, PPR, PDQ, CPS, no spooler) use "foomatic-configure" as described
in the USAGE file of foomatic-db-engine. You can set up printer queues
based on the Foomatic database, with PPD files for PostScript printers,
or raw queues. This is possible for all spoolers. You can also print a
wide range of file types with every spooler (when you use LPRng, LPD,
GNUlpr, PDQ, CPS, or no spooler you need "a2ps" on your machine).

If you want to know how all this works, see the README files of both the
foomatic-db-engine and foomatic-filters packages.


Web site
--------

Alternatively you can download all what you need for setting up a print
queue from the web, as it was possible all the time with
Foomatic 2.0.x. Go simply to the usual site:

        http://www.linuxprinting.org/

All documentation on the web site is updated. So you can simply
follow the step-by-step instructions on the documentation page for your
spooler  The main Foomatic page gives you download links and
instructions for installing the Foomatic 3.0.0 packages and for
anonymous download of the CVS where you can follow the further
development on the way to version 3.0.1.






More information about the kde-print mailing list