Re: [Gimp-print-devel] Proposed changes from 4.2.5-pre1

[Till K. <til...@gm...>]

Robert L Krawitz wrote:
>    Is the IEEE-1284 auto-detection info not in the spec sheets which
>    you get for programming the Epson drivers.
> 
> For some of them.
>

Can you post a list of them? Adding them to the Foomatic entries would 
make the life much easier for auto-detecting printer config programs.

> 
>    One could do one of the following things:
> 
>    1. (removes dependency on foomatic-db): Either make faked printer
>    entry XML files whenever there is no XML file for the desired
>    printer or (better) add new command line arguments to
>    "foomatic-ppdfile" and "foomatic-compiledb" to make them generating
>    PPD files if the printer XML file is missing. This is no problem as
>    for building the driver command line no info from the printer XML
>    file is needed. Only problem is that when make and model name of
>    the printer are not in the PPD it is difficult to fid it with
>    printer configuration programs (both manually and automatically),
>    but the GIMP-Print build process could edit the generated PPDs to
>    contain the make and model name in the correct header fields.
> 
> I don't understand this; Gimp-print always knows what the make and
> model of the printer are, and could put it in the PPD file.
>

Yes, this is what I mean with "the GIMP-Print build process could edit 
the generated PPDs to contain the make and model name in the correct 
header fields". After the PPD builder of Foomatic has generated a PPD 
file without having a printer entry, the header fields are empty, as 
this data would come from the printer entry. Now GIMP-Print which has 
the knowledge about make and model could fill in these fields.

>    2. (removes dependency on foomatic-db, foomatic-db-engine, and
>    libxml2): The PPD builder of GIMP-Print directly produces PPD files
>    fulfilling the format conventions in
> 
>    http://www.linuxprinting.org/foomatic2.9/foomatic-db-engine/README
> 
>    section "Example for a Foomatic-generated PPD file" (at the end of
>    the file). This removes the XML detour and so the necessity of any
>    external packages for the PPD building process. The only external
>    program needed is foomatic-rip (foomatic-gswrapper is recommended)
>    and this is a copy-and-go, no compilation and only dependent on
>    Perl (ships with every distro). One could even put the current
>    versions of foomatic-rip and foomatic-gswrapper into the GIMP-Print
>    package and if "make install" does not find equal or newer ones on
>    the system, it installs them.
> 
> What's your opinion and why?  You know foomatic-rip a lot better than
> anyone else here.
> 

foomatic-rip is a Perl script (without any dependencies on libraries, 
foomatic-db or foomatic-db-engine also do not need to be installed to 
run it) which takes PostScript (or other file formats) on standard input 
and produces the printer's native language on standard output. It 
auto-detects the spooler in use and then takes all data and parameters 
from the places where the spooler provides them.

It understands Adobe-complient PPDs and inserts the option settings into 
the PostScript data stream according to the supplied options.

The most important is, that it understands special Foomatic keywords 
which define a GhostScript (or any other 
PostScript-to-printer's-language filter) command line and its options 
and how they depend on the user's settings. See the README file of 
foomatic-db-engine for an example PPD and the special keywords (see link 
in previous posting).

As you made the impression to me that you search for a solution which 
works without the Foomatic database, I proposed some possible solutions 
to reduce the dependencies. And one was producing the PPDs directly, it 
is not difficult and foomatic-rip does not see whether a PPD file with 
Foomatic keywords is produced by Foomatic or by something else.

Including foomatic-rip in GIMP-Print is not really necessary, as it is 
very easy to install, It was only some idea to get a certain form of 
making it as idiot-proof as possible.

>    On linuxprinting.org would then be only one XML file for
>    GIMP-Print, named "db/source/driver/gimp-print.xml" only containing
>    the comment text and the list of printers supported by the current
>    version. It will not contain a command line nor will their be
>    option XML files. The text will tell that the PPD files are
>    directly produced by GIMP-Print and so on and that there are two
>    interfaces (IJS and GhostScript "stp").
> 
>    Big disadavantage would be that there is no "Execution Details"
>    section on the linuxprinting.org web page and a printer setup
>    program based on the Foomatic XML database would not be able to set
>    up GIMP-Print (but also not to be able to set up native PostScript
>    printers).
> 
> Why?  Gimp-print can continue generating the same XML data files it
> does now.  If you're talking about setting up a Gimp-print based queue
> without having Gimp-print installed, that won't do anything too useful
> anyway.

I thought about making PPDs for GIMP-Print's GhostScript and IJS drivers 
without having foomatic-db-engine installed (you wanted to get rid of 
the dependencies on foomatic-db and foomatic-db-engine).

> 
>    Another problem is Foomatic 2.0.x where GIMP-Print had to build 3
>    different types of files (PPD, PDQ description file,
>    LPD/LPRng/direct description file).
> 
> I thought it only built one kind of XML file, and then the foomatic
> system takes it from there.
> 

Yes, there is only one kind of XML files, but in Foomatic 2.0.x, there 
were separate filters for the different supported spoolers (cupsomatic, 
lpdomatic, directomatic, ppromatic, ...) and every filter needed its own 
file format for the description of the printer capabilities (see the 
four buttons on the driver entry pages on linuxprinting.org). Foomatic 
2.9.x uses the same XML format, but it builds only PPDs to be used with 
foomatic-rip with all spoolers.

What do you want to change on the way to make available PPD files for 
the GhostScript and IJS drivers? Do you want to get rid of the 
dependencies on the PPD-building part of Foomatic? Do you want to avoid 
a collection of XML or PPD files on the disk and get only the needed 
PPDs generated on-the-fly?

What I like to keep on linuxprinting.org are the "Execution Details" on 
the gimp-print pages. The PPD download facility can be suppressed and 
replaced by a text hint that one should get the PPD from the package. 
The package should provide an easy way to obtain the PPDs. A source 
package can require Foomatic. I think someone who is able to compile 
GIMP-Print should also be able to compile Foomatic. A binary package of 
GIMP-Print should better provide pre-built PPDs so that the user does 
not need to compile and install Foomatic. He simply downloads the 
ready-to-use foomatic-rip and puts it into the right place.

>    Perhaps GIMP-Print should produce both direct PPDs and XML data,
>    "./configure" will decide on the presence of Foomatic packages and
>    on command line options whether to build XML, direct PPDs, both, or
>    nothing.
> 
>    3. (Perhaps for GIMP-Print 4.3.x): The GIMP-Print capabilities
>    daemon.  One has a virtual file system (as /proc or /dev on systems
>    with DevFS) making available all PPD files. These PPD files are not
>    on the disk any more, if a program accesses them, the daemon (which
>    is linked against libgimpprint) will provide the data. So one does
>    not need a space-consuming copy of data on the disk which
>    libgimpprint knows anyway. This would save a lot of disk space and
>    guarantee that the PPDs are in sync with the installed libgimpprint
>    (at least for new CUPS queues, as CUPS copies the PPDs into
>    /etc/cups/ppd/, PPR does not copy them, there you could choose your
>    libgimpprint before every job then).
> 
>    Problems:
> 
>    - Is it possible to make a virtual file system with a user-space program 
>    as a daemon?
> 
>    - The daemon would probably have to run as root, which can open security 
>    holes.
> 
> This is very OS-specific.  Any operating system that supports an NFS
> client *could* do this; that's basically how automounters work.  It
> certainly does have major security and reliability issues.
> 
> It's not that much of a secret that I really don't like PPD files very
> much anyway.  Yes, it's possible to represent anything at all with
> sufficient constraints and option choices, but it gets unwieldly
> fast.
> 
It was only an idea, perhaps there will be later some thingy which makes 
available printer capability information in a more sophisticated way as 
PPDs. The CUPS/IPP concept which propagates the PPD from the server to a 
zero-configuration client is already very nice.

    Till