Commit 024058a8 authored by Didier Raboud's avatar Didier Raboud

Imported Upstream version 3.0.2-20050218

parents
This diff is collapsed.
/COPYING/3.1/Tue Jan 28 23:01:10 2003//Tfoomatic-3_0-branch
/ChangeLog/3.99.2.23/Fri Jan 28 16:17:13 2005//Tfoomatic-3_0-branch
/Foomatic-Devel-Ideas.txt/3.2/Tue Apr 22 23:19:52 2003//Tfoomatic-3_0-branch
/Makefile.in/3.16.2.3/Fri Jan 28 16:17:13 2005//Tfoomatic-3_0-branch
/README/3.26.2.5/Tue Sep 14 21:08:37 2004//Tfoomatic-3_0-branch
/README.build-foomatic-filters-ppds/3.3.2.1/Sun Mar 28 23:04:51 2004//Tfoomatic-3_0-branch
/TODO/3.1/Fri Nov 29 01:31:37 2002//Tfoomatic-3_0-branch
/USAGE/3.14.2.4/Tue Sep 14 21:08:37 2004//Tfoomatic-3_0-branch
/acinclude.m4/3.0/Fri Oct 11 01:16:34 2002//Tfoomatic-3_0-branch
/configure.in/3.13.2.2/Tue Jul 20 15:54:10 2004//Tfoomatic-3_0-branch
/extract_pjl/3.1/Wed Nov 19 03:23:50 2003//Tfoomatic-3_0-branch
/foomatic-addpjloptions.8.in/3.2/Wed Nov 19 03:23:50 2003//Tfoomatic-3_0-branch
/foomatic-addpjloptions.in/3.1/Wed Nov 19 03:23:50 2003//Tfoomatic-3_0-branch
/foomatic-cleanupdrivers.in/3.0.2.2/Fri Jan 28 16:17:13 2005//Tfoomatic-3_0-branch
/foomatic-combo-xml.1.in/3.0/Fri Oct 11 01:16:34 2002//Tfoomatic-3_0-branch
/foomatic-combo-xml.c/3.3.2.1/Wed Mar 24 22:18:18 2004//Tfoomatic-3_0-branch
/foomatic-compiledb.1.in/3.1/Thu Nov 28 02:42:26 2002//Tfoomatic-3_0-branch
/foomatic-compiledb.in/3.6.2.1/Tue Nov 30 14:29:43 2004//Tfoomatic-3_0-branch
/foomatic-configure.1.in/3.1/Thu Nov 28 02:42:26 2002//Tfoomatic-3_0-branch
/foomatic-configure.in/3.18.2.2/Tue Nov 30 14:29:43 2004//Tfoomatic-3_0-branch
/foomatic-filters-ppds-README/3.1/Sun Feb 23 07:14:18 2003//Tfoomatic-3_0-branch
/foomatic-filters-ppds-install/3.1/Sun Feb 23 07:14:18 2003//Tfoomatic-3_0-branch
/foomatic-fix-xml.in/3.0/Fri Oct 11 01:16:34 2002//Tfoomatic-3_0-branch
/foomatic-getpjloptions.8.in/3.1/Wed Nov 19 03:23:50 2003//Tfoomatic-3_0-branch
/foomatic-getpjloptions.in/3.1/Wed Nov 19 03:23:50 2003//Tfoomatic-3_0-branch
/foomatic-kitload.8.in/3.0.2.1/Sun Mar 28 23:04:51 2004//Tfoomatic-3_0-branch
/foomatic-kitload.in/3.0/Fri Oct 11 01:16:34 2002//Tfoomatic-3_0-branch
/foomatic-nonumericalids.in/3.1/Thu Mar 27 21:01:58 2003//Tfoomatic-3_0-branch
/foomatic-perl-data.1.in/3.0/Fri Oct 11 01:16:34 2002//Tfoomatic-3_0-branch
/foomatic-perl-data.c/3.14.2.1/Wed Mar 24 22:18:18 2004//Tfoomatic-3_0-branch
/foomatic-ppd-options.1.in/3.1/Wed Nov 19 03:23:50 2003//Tfoomatic-3_0-branch
/foomatic-ppd-options.in/3.2/Wed Nov 19 03:41:29 2003//Tfoomatic-3_0-branch
/foomatic-ppdfile.1.in/3.2/Wed Nov 19 03:23:50 2003//Tfoomatic-3_0-branch
/foomatic-ppdfile.in/3.4.2.2/Tue Nov 30 14:29:43 2004//Tfoomatic-3_0-branch
/foomatic-preferred-driver.8.in/3.0/Fri Oct 11 01:16:34 2002//Tfoomatic-3_0-branch
/foomatic-preferred-driver.in/3.3.2.1/Sun Mar 28 23:04:51 2004//Tfoomatic-3_0-branch
/foomatic-printermap-to-gimp-print-xml.in/1.1.2.2/Sun Mar 28 23:04:51 2004//Tfoomatic-3_0-branch
/foomatic-printjob.1.in/3.0/Fri Oct 11 01:16:34 2002//Tfoomatic-3_0-branch
/foomatic-printjob.in/3.0/Fri Oct 11 01:16:34 2002//Tfoomatic-3_0-branch
/foomatic-replaceoldprinterids.in/3.2/Fri Apr 25 23:49:37 2003//Tfoomatic-3_0-branch
/gsPrint/3.1/Wed Nov 19 03:23:50 2003//Tfoomatic-3_0-branch
/gsQuit/3.1/Wed Nov 19 03:23:50 2003//Tfoomatic-3_0-branch
/gsTest/3.1/Wed Nov 19 03:23:50 2003//Tfoomatic-3_0-branch
/install-sh/3.0/Fri Oct 11 01:16:34 2002//Tfoomatic-3_0-branch
/makeDefaults.in/3.3.2.1/Fri Jan 28 12:39:36 2005//Tfoomatic-3_0-branch
/makeMan.in/3.1/Thu Jun 26 13:28:24 2003//Tfoomatic-3_0-branch
/make_configure/3.0/Fri Oct 11 01:16:34 2002//Tfoomatic-3_0-branch
/mkinstalldirs/3.1/Wed Nov 19 03:23:50 2003//Tfoomatic-3_0-branch
D/debian////
D/foomatic-templates////
D/lib////
foomatic-db-engine
/var/lib/cvs
Tfoomatic-3_0-branch
This source diff could not be displayed because it is too large. You can view the blob instead.
Here are some ideas on how new things could be implemented
----------------------------------------------------------
Suggested by Till
The items are not sorted in a special way, especially they are not
sorted by importance.
Conserving Foomatic data for certain distros or old driver versions
-------------------------------------------------------------------
This can be realized most easily by CVS tags which start a new
branch. When a distro or a driver is released one tags the CVS. So
retrieving this CVS state gives a Foomatic package fitting to the
appropriate distro or driver. Bug fixes for old distros or drivers
which do not apply any more to the current state of Foomatic can be
commited to the appropriate CVS branch.
The web interface of linuxprinting.org could have buttons than where
one can choose the driver or distro version for which one wants to
have the Foomatic data.
Printer compatibility classes
-----------------------------
Instead of needing to add many compatible printers to the drivers and
to the constraints of options one could introduce compatibility
classes. A compatibility class contains absolutely compatible
printers, which means printers which work with the same drivers, the
same options, and the same choices for the options. Then one can put
the class name into the list of supported printers of a driver and
also into the constraints of the options and so one avoids needint to
insert tenth of printers everywhere. Especially there are many HP
inkjets which are absolutely compatible to each other (around ten
classes instead of 100 printers) and there are many clones of HP
LaserJet printers.
The classes could be defined in a new subdirectory "class" besides the
existing "printer", "driver", and "option" subdirectories. The XML
file could look as follows (this is the class of new HP inkjets as
defined for the HPIJS driver. It contains only the "small" models with
paper sizes up to Legal format):
<class id="class/DJ9xxVIP_small">
<printers>
<printer>
<id>printer/635698</id><!-- HP DeskJet 960C -->
</printer>
<printer>
<id>printer/HP-DeskJet_980C</id>
</printer>
<printer>
<id>printer/530418</id><!-- HP DeskJet 990C -->
</printer>
...
</printers>
</class>
Then the entry to include these printers in the HPIJS driver entry would
reduce to
<printers>
...
<printer>
<id>class/DJ9xxVIP_small</id>
<!-- HP DeskJet 990C compatible, max. Legal paper -->
</printer>
...
</printers>
The 1200-dpi photo quality choice is unique to this printer class, so
it will have the constraints:
...
<constraints>
<!-- Assume the choice doesn't apply... -->
<constraint sense='false'>
<driver>hpijs</driver>
</constraint>
<!-- ...except to these: -->
<constraint sense='true'>
<driver>hpijs</driver>
<printer>class/DJ9xxVIP_small</printer>
</constraint>
<constraint sense='true'>
<driver>hpijs</driver>
<printer>class/DJ9xxVIP_large</printer>
</constraint>
</constraints>
...
This way the manual entering of Foomatic daya will get much easier.
Option conflicts
----------------
Option conflicts prevent the user from making choices which make
printing impossible or simply do not make sense (as Duplex on
transparencies or 1200 dpi on plain paper).
I have already thought about adding a fourth subdirectory (besides
"printer", "driver", "opt") named "conflict" containing files like
<conflict id="conflict/noLargeCapacityTray">
<comments>
<en>
Large capacity tray not installed but either requested or needed
due to the requested amount of copies.
</en>
</comments>
<constraints>
<constraint sense="false">
<make>Brother</make>
</constraint>
<constraints>
<conflicting_settings>
<constraints>
<constraint sense="false">
<driver>ljet4</driver>
</constraint>
<constraints>
<message>
<en>
Large capacity tray requested but not installed!
</en>
</message>
<setting>LCTInstalled eq No</setting>
<setting>InputSlot eq LargeCapacity Tray4 Tray5</setting>
</conflicting_settings>
<conflicting_settings>
<message>
<en>
No tray for &value:Copies; sheets available!
</en>
</message>
<setting>LCTInstalled eq No</setting>
<setting>Copies gt 250</setting>
</conflicting_settings>
</conflict>
Here "eq" means "equal to one of the items listed" and "gt" means
greater than the given item. A conflict happens when all the conditions
in the <settings> lines are fullfilled and it should show the <message>
in the GUI. <constraints> mean the same as in the other files.
Graying out options
-------------------
Some options do not make sense when other options have a certain
setting, as for example adjustment of Cyan, Magenta, and Yellow when
grayscale or bw printing is chosen. So one could add conditions to an
option's XML file when it should be grayed out, as
<option type="int" id="opt/MagentaLevel">
<grayout>
<setting>ColorMode eq Grayscale BlackAndWhite</setting>
</grayout>
...
The condition syntax is here the same as with the conflicts.
Standard and Advanced options
-----------------------------
A GUI could only show the standard options by default and the advanced
options only show up by clicking an "Advanced" button. This could simply
by realized by adding a
<arg_advanced />
tag to all options which should be advanced options. Perhaps one
places it in the option constraints, so an option can be advanced for
one driver and standard for another.
Option groups
-------------
Option groups allow a more structured presentation of the options in a
GUI. In XPP (CUPS frontend) for example all options except "PageSize",
"InputSlot", "Duplex" go into an "Extra" group (this is a decision
made by CUPS when there are no group definitions in the PPD
file). With option groups there could be generated varipus tabs, as
"Finishing", "Color correction", "Installable options", ... which
would make it much easier to find the options in the GUI dialogs.
Options could be grouped by adding a group name to every option XML file:
<option type="enum" id="opt/pjl-stapling">
<arg_group_longname>
<en>Finishing Options</en>
</arg_group_longname>
<arg_group_shortname>
<en>Finishing</en>
</arg_group_shortname>
<arg_longname>
<en>Phone Number</en>
</arg_longname>
...
We use a long name and a short name here, as for the option names
itself, one for the GUIs, the other internal identification or command
line applications.
In a PPD file the option entry would be surrounded by
*OpenGroup: Finishing/Finishing Options
...
*CloseGroup: Finishing
Options without group should be treated as before or get into some
default group.
Pickmany options
----------------
Pickmany options could have the same XML file structures as the "enum"
options but have the type "pickmany". They should allow to assign a
comma separated list of choices to the option:
lpr -P laserjet -o option=value1,value2,value3 file.ps
The default value in the XML database entry file for this option
should contain a comma-separated list of choice IDs or can be empty:
<arg_defval></arg_defval>
<arg_defval>ev/choice1,ev/choice2</arg_defval>
This diff is collapsed.
This source diff could not be displayed because it is too large. You can view the blob instead.
Building the foomatic-filters-ppds package
------------------------------------------
The foomatic-filters-ppds package is a simple way to use Foomatic
Till Kamppeter <till.kamppeter@gmx.net>
http://www.linuxprinting.org/
Introduction
------------
This package is intended to be a complete but simplified version of
Foomatic which does not need any compilation of C programs nor any Perl
libraries except the standard ones coming with the Perl
interpreter. Also "make" is not needed to use this package.
This file describes how to build the package.
What is required
----------------
You need at least
foomatic-db-engine
foomatic-filter
foomatic-db
To include support for HPIJS
foomatic-db-hpijs
To include support for Gimp-Print
Gimp-Print from http://gimp-print.sf.net/
To include support for Omni
Omni from
http://www-124.ibm.com/developerworks/oss/linux/projects/omni/
How to build
------------
Uncompress all foomatic packages in one directory:
tar -xvzf foomatic-db-engine*.tar.gz
tar -xvzf foomatic-filters*.tar.gz
tar -xvzf foomatic-db*.tar.gz
Build the packages:
cd foomatic-filters*
make_configure # (only if you downloaded from CVS)
./configure
make inplace
cd ..
cd foomatic-db-engine*
make_configure # (only if you downloaded from CVS)
./configure
make inplace
cd ..
Add support for HPIJS (optional):
tar -xvzf foomatic-db-hoijs*.tar.gz
cd foomatic-db-hoijs*
make_configure # (only if you downloaded from CVS)
./configure
make inplace
cd ../foomatic-db-engine*
./foomatic-kitload -f -k ../foomatic-db-hoijs*/db/source/
cd ..
Add support for Gimp-Print (optional, <...> is the Gimp-Print source
code directory):
cd foomatic-db-engine*
./foomatic-kitload -f -k <...>/src/foomatic/foomatic-db/gimp-print
./foomatic-kitload -f -k <...>/src/foomatic/foomatic-db/gimp-print-ijs
cd ..
Add support for Omni (optional):
cd foomatic-db-engine*
export PATH=$PATH:/opt/Omni/bin
/opt/Omni/bin/OmniFoomaticGenerator
./foomatic-kitload -k foomatic-db/db/source
cd ..
Exclude unwished drivers or printers from being packaged by deleting
their XML files:
cd foomatic-db*/db/source
rm -f driver/hpdj.xml
rm -f driver/stp.xml
rm -f driver/lxm3200?.xml
rm -f driver/lxm3200.xml
...
cd ../../..
Clean up:
cd foomatic-db-engine*
./foomatic-cleanupdrivers
./foomatic-preferred-driver
Now build the complete package:
make filters-ppds
This will take some time for getting all PPD files built, as result
one gets a tarball with a name like
foomatic-filters-ppds*.tar,gz
This is the ready-to-use package. Read its README file to know how to
use it.
See also the bugtracker at foomatic.sourceforge.net.
- Possibility for users to have their personal default options
(.lpoptions file as in CUPS, due to the Foomatic options having the same
names as the CUPS-O-MATIC options one can even use an .lpoptions file
with exactly the same format as the CUPS file and it will be used by
both Foomatic and CUPS)
- Write a few key lint-like and transforming tools for the xml data.
- Fold foomatic-gswrapper into the foomatic-rip
- Improve ascii support to lpdomatic and pdq files. ASCII should
simply be a matter of observing the ascii bit in the printer $dat
and sending either crlf-ed text or postscriptifying and running
through the ps driver. Right now text is always translated to
PostScript (with the advantage of more nicely-looking text
output (with head line, page numbers, ...). When one implements
the possibility to pass text directly to the printer, one should
consider the optional use or the "pr" filter.
- PDQ file versioning is still unsatisfactory. I changed from a
checksum to the current timestamp. So now it's sequential, but
changes all every time. Other spoolers' code needs a version story
in the first place.
This diff is collapsed.
dnl AC_PATH_DIR(VARIABLE, DIR-TO-CHECK-FOR [, VALUE-IF-NOT-FOUND [, PATH]])
AC_DEFUN(AC_PATH_DIR,
[# Extract the first word of "$2", so it can be a program name with args.
set dummy $2; ac_word=[$]2
AC_MSG_CHECKING([for $ac_word/])
AC_CACHE_VAL(ac_cv_path_$1,
[case "[$]$1" in
/*)
ac_cv_path_$1="[$]$1" # Let the user override the test with a path.
;;
?:/*)
ac_cv_path_$1="[$]$1" # Let the user override the test with a dos path.
;;
*)
IFS="${IFS= }"; ac_save_ifs="$IFS"; IFS=":"
dnl $ac_dummy forces splitting on constant user-supplied paths.
dnl POSIX.2 word splitting is done only on the output of word expansions,
dnl not every word. This closes a longstanding sh security hole.
ac_dummy="ifelse([$4], , $PATH, [$4])"
for ac_dir in $ac_dummy; do
test -z "$ac_dir" && ac_dir=.
if test -d $ac_dir/$ac_word; then
ac_cv_path_$1="$ac_dir/$ac_word"
break
fi
done
IFS="$ac_save_ifs"
dnl If no 3rd arg is given, leave the cache variable unset,
dnl so AC_PATH_PROGS will keep looking.
ifelse([$3], , , [ test -z "[$]ac_cv_path_$1" && ac_cv_path_$1="$3"
])dnl
;;
esac])dnl
$1="$ac_cv_path_$1"
if test -n "[$]$1"; then
AC_MSG_RESULT([$]$1)
else
AC_MSG_RESULT(no)
fi
AC_SUBST($1)dnl
])
dnl AC_PATH_DIRS(VARIABLE, DIRSS-TO-CHECK-FOR [, VALUE-IF-NOT-FOUND
dnl [, PATH]])
AC_DEFUN(AC_PATH_DIRS,
[for ac_dir in $2
do
AC_PATH_DIR($1, [$]ac_dir, , $4)
test -n "[$]$1" && break
done
ifelse([$3], , , [test -n "[$]$1" || $1="$3"
])])
dnl aclocal.m4 generated automatically by aclocal 1.4-p4
dnl Copyright (C) 1994, 1995-8, 1999 Free Software Foundation, Inc.
dnl This file is free software; the Free Software Foundation
dnl gives unlimited permission to copy and/or distribute it,
dnl with or without modifications, as long as this notice is preserved.
dnl This program is distributed in the hope that it will be useful,
dnl but WITHOUT ANY WARRANTY, to the extent permitted by law; without
dnl even the implied warranty of MERCHANTABILITY or FITNESS FOR A
dnl PARTICULAR PURPOSE.
dnl AC_PATH_DIR(VARIABLE, DIR-TO-CHECK-FOR [, VALUE-IF-NOT-FOUND [, PATH]])
AC_DEFUN(AC_PATH_DIR,
[# Extract the first word of "$2", so it can be a program name with args.
set dummy $2; ac_word=[$]2
AC_MSG_CHECKING([for $ac_word/])
AC_CACHE_VAL(ac_cv_path_$1,
[case "[$]$1" in
/*)
ac_cv_path_$1="[$]$1" # Let the user override the test with a path.
;;
?:/*)
ac_cv_path_$1="[$]$1" # Let the user override the test with a dos path.
;;
*)
IFS="${IFS= }"; ac_save_ifs="$IFS"; IFS=":"
dnl $ac_dummy forces splitting on constant user-supplied paths.
dnl POSIX.2 word splitting is done only on the output of word expansions,
dnl not every word. This closes a longstanding sh security hole.
ac_dummy="ifelse([$4], , $PATH, [$4])"
for ac_dir in $ac_dummy; do
test -z "$ac_dir" && ac_dir=.
if test -d $ac_dir/$ac_word; then
ac_cv_path_$1="$ac_dir/$ac_word"
break
fi
done
IFS="$ac_save_ifs"
dnl If no 3rd arg is given, leave the cache variable unset,
dnl so AC_PATH_PROGS will keep looking.
ifelse([$3], , , [ test -z "[$]ac_cv_path_$1" && ac_cv_path_$1="$3"
])dnl
;;
esac])dnl
$1="$ac_cv_path_$1"
if test -n "[$]$1"; then
AC_MSG_RESULT([$]$1)
else
AC_MSG_RESULT(no)
fi
AC_SUBST($1)dnl
])
dnl AC_PATH_DIRS(VARIABLE, DIRSS-TO-CHECK-FOR [, VALUE-IF-NOT-FOUND
dnl [, PATH]])
AC_DEFUN(AC_PATH_DIRS,
[for ac_dir in $2
do
AC_PATH_DIR($1, [$]ac_dir, , $4)
test -n "[$]$1" && break
done
ifelse([$3], , , [test -n "[$]$1" || $1="$3"
])])
This diff is collapsed.
This diff is collapsed.
/README.Debian/1.1.2.1/Sat Dec 4 18:15:35 2004//Tfoomatic-3_0-branch
/TODO/3.0.2.1/Sat Dec 4 18:14:26 2004//Tfoomatic-3_0-branch
/changelog/3.0.2.1/Sat Dec 4 18:14:26 2004//Tfoomatic-3_0-branch
/compat/1.1.2.1/Sat Dec 4 18:15:35 2004//Tfoomatic-3_0-branch
/control/3.0.2.1/Sat Dec 4 18:14:26 2004//Tfoomatic-3_0-branch
/copyright/3.0.2.1/Sat Dec 4 18:14:26 2004//Tfoomatic-3_0-branch
/dirs/1.1.2.1/Sat Dec 4 18:15:35 2004//Tfoomatic-3_0-branch
/docs/1.1.2.1/Sat Dec 4 18:15:35 2004//Tfoomatic-3_0-branch
/foomatic-bin.README.Debian/1.1.2.1/Sat Dec 4 18:15:35 2004//Tfoomatic-3_0-branch
/foomatic-bin.dirs/1.1.2.1/Sat Dec 4 18:15:35 2004//Tfoomatic-3_0-branch
/presubj/1.1.2.1/Sat Dec 4 18:15:35 2004//Tfoomatic-3_0-branch
/rules/3.0.2.1/Sat Dec 4 18:14:26 2004//Tfoomatic-3_0-branch
D
foomatic-db-engine/debian
/var/lib/cvs
Tfoomatic-3_0-branch
foomatic-db-engine for Debian
-----------------------------
Note that the structure of the LinuxPrinting.org (foomatic) printer
configuration system in Debian (and upstream) has changed from the 2.0
series. There are now 3 core packages:
* foomatic-db: Contains the foomatic printer database.
* foomatic-db-engine (this package): Contains the foomatic-configure script.
* foomatic-filters: Contains the filter scripts for various backend
printing systems.
In addition, the new foomatic-db-hpijs package includes the database
entries for printers supported by the HPIJS print filter developed by
Hewlett-Packard for its consumer inkjet line of printers.
The foomatic-bin package is provided for upgrade purposes from
Foomatic 2.0, and can be purged after its dependencies have been
installed.
If you want a GUI to configure your printer, you may want to try
"foomatic-gui," a GNOME-based printer configuration tool that works
with Foomatic and all of the spoolers it supports.
** How to configure a queue manually *
The command "foomatic-configure" handles this. Set up the queue as follows:
foomatic-configure -n <queue-name> -N <description> -L <location>
-c <connection> -p <printer> -d <driver> -s <spooler>
where:
queue-name: What you want the queue to be called.
description: A human-readable description of the queue.
location: The physical location of the printer.
connection: How the printer is connected. e.g.:
Parallel port: file:/dev/lp0
USB port: file:/dev/usb/lp0
IPP/CUPS: ipp://printserver.example.org/printers/lj4500
Samba/Windows: smb://WORKGROUP/PC/Canon
JetDirect: socket://jetdirect.example.org:9100/
printer: The printer database name. Generally:
Manufacturer_Model-Name
driver: The driver backend to use. For most modern printers, one of:
hpijs (if you have foomatic-db-hpijs installed)
gimp-print (if you have foomatic-db-gimp-print installed)
gimp-print-ijs (a hybrid that ijsgimpprint and hpijs to be installed)
Postscript
pcl5
Your best bet on these two items is looking them up in the database at
LinuxPrinting.org or looking through the XML files in
/usr/share/foomatic/db/source/printer/
spooler: one of: cups, lpd, lprng, ppd, direct, ppr, pdq, gnulpr
(You can omit the -s option and it will try to guess.)
** Notes for CUPS users **
IMPORTANT: If your printer filter is not working (dumping raw
PostScript to the printer) immediately after setting up a queue with
foomatic-configure, you may need to reload the CUPS daemon. e.g. use:
# invoke-rc.d cupsys reload
There used to be a package called "cupsomatic-ppd" that provided PPD
files for all printers supported by CUPS. A similar package called
"foomatic-filters-ppds" is now available in Debian.
This package saves the step of using foomatic-configure to generate
and install a PPD file for your printer and driver. Perhaps more
importantly, it provides an easy way to select printers from within
CUPS's web-based administration tool. However, it is also 15 MB when
compressed, so is not recommended unless you need to use the CUPS web
interface to initially set up printers.
-- Chris Lawrence <lawrencc@debian.org>, Tue Jul 1 19:15:43 2003
Possible future plans:
- Complete the manpages.
- Package foomatic-filters-ppds?
- Provide a simple way to generate custom debian packages containing
datafiles for selected printers/drivers?
This diff is collapsed.
Source: foomatic-db-engine
Section: text
Priority: optional
Maintainer: Chris Lawrence <lawrencc@debian.org>
Standards-Version: 3.6.1
Build-Depends: debhelper (>> 4), perl, libxml2-dev
Package: foomatic-db-engine
Architecture: any
Pre-Depends: bash (>= 2.05)
Depends: ${perl:Depends}, ${shlibs:Depends}, foomatic-db, foomatic-filters, wget | curl
Recommends: netcat
Suggests: foomatic-db-hpijs, foomatic-db-gimp-print, foomatic-gui
Conflicts: foomatic-bin (<< 2.9), foomatic-db (<< 2.9)
Replaces: foomatic-bin (<< 2.9)
Description: linuxprinting.org printer support - programs
Foomatic is a printing system designed to make it easier to set up
common printers for use with Debian (and other operating systems).
It provides the "glue" between a print spooler (like CUPS or lpr) and
your actual printer, by telling your computer how to process files
sent to the printer.
.
This package contains the architecture-dependent programs needed to
set up and maintain the foomatic system. You will also need one or
more database packages. The foomatic-db package includes drivers for
most common printers using Ghostscript as the print processor, as
well as some common glue code used in other filter systems.
.
foomatic-db-hpijs includes support for photo-quality printing with
Hewlett-Packard and some other consumer inkjets using the HPIJS
backend developed by HP.
.
foomatic-db-gimp-print includes support for photo-quality printing
with many consumer inkjets (including those from HP and Epson).
.
foomatic-gui provides a GNOME-based setup tool for Foomatic printer
queues using the command-line tools provided in this package.
.