[Printing-architecture] FSG Printer Working Group conference call 03/26/03

[Printing-architecture] FSG Printer Working Group conference call 03/26/03

[Mark Hamzy]

Wednesday, March 26

GMT 19:00
EST 14:00
CST 13:00
MST 12:00
PST 11:00

Tie Line:    650-3239
Toll Free:   1-800-497-2024
Toll Number: 1-719-457-3821
Passcode:    160458

Topics

* should printer drivers implement a required set of common job properties
(JP)?
  Examples of keys would be: orientation, form, tray, media, duplex,
resolution.

  + Should we use
       - one existing standard
          PWG well known values (
http://www.pwg.org/schemas/sm/latest/MediaWellKnownValues.xsd)
       - two or more existing standards
          PWG and/or JDF
       - a new standard

  + is support of the FSG's Job Ticket standard a requirement?

* should all JPs be passed in one call or only one JP for each call
  (requiring multiple calls to a driver)?

* can there be default job properties or must every property be set?

* should we use a named pipe (or similar) to communicate to a driver or
  can we use an API?

  + If an API, should that API implement a pipe under the covers?

* should there be different pipes for each print job or should the driver
  be required to multiplex between the jobs in one pipe?

* should there be application presentation information that can be
  queried?  Some examples are:
     printable page size
     resolution
     current color depth
     font metrics

* can there be different job properties for each page?

  + Can this can be optional?

* should we allow for future extensibility to support optional components
of
  a printer driver?

  + vector graphics

    - should we use existing vector language? (SVG, PDF)

    - can it be multiple languages?

    - should we require simulation?
      That is if a driver only accepts bitmaps, then create a raster image
      of the vector commands.  If a driver doesn't support rounded boxes
      but does support arcs and lines, then break a round box into
      multiple arc and line calls.

  + device fonts

* should we have an interface to query the printer's job dialog?
  This will allow for programmatic support of setting/querying the JPs.

     + grouping/structuring

     + constraints

     + type of data (boolean, int, float, string, password, etc)

* should we require a standard install path?
  /usr/lib/print/driver/drivername
  /usr/share/print/font/drivername/

Mark

Take a look at the Linux Omni Printer Driver Framework at
http://www.ibm.com/linux/ltc/projects/omni/

[Printing-architecture] Re: [printing-driver] FSG Printer Working Group conference call 03/26/03

[Robert L Krawitz]

   From: Mark Hamzy <hamzy@us.ibm.com>
   Date: Mon, 24 Mar 2003 13:30:36 -0600

   * should printer drivers implement a required set of common job properties
   (JP)?
     Examples of keys would be: orientation, form, tray, media, duplex,
   resolution.

These certainly don't apply to all printers; most inkjets don't
support duplex, and many also don't have selectable input sources.
I'd prefer to see a list of standard job properties that could be
amended, and standards (and/or a registry) for drivers to support
non-standard properties (such as the whole mess of things Gimp-print
supports).

     + Should we use
	  - one existing standard
	     PWG well known values (
   http://www.pwg.org/schemas/sm/latest/MediaWellKnownValues.xsd)
	  - two or more existing standards
	     PWG and/or JDF
	  - a new standard

I don't like the fixed values at all; they basically try to force all
papers into specific niches.  For example, Epson offers a number of
different photographic papers (Photo Paper, Premium Glossy Photo
Paper, Premium Semiglosss, etc.), and each one has different
characteristics.  There are a lot of third party papers as well, and
these also have different characteristics.  Having the
MediaTypeExtensionPattern is fine, but on Epson (and other inkjet)
printers, "photographic-glossy" simply isn't a very useful
description; there are enormous differences between different
photographic-glossy papers, and it's important for the user to specify
the precise paper by name.  Subtle differences in the coating (which
users generally can't distinguish except by name) require great
differences; for example, when printing to Premium Glossy on the
Stylus C80, it's important to not use black ink, which is formulated
differently and doesn't adhere correctly to the paper.  Other glossy
photo papers should be printed with black ink, however.

   * should all JPs be passed in one call or only one JP for each call
     (requiring multiple calls to a driver)?

I'd vote for all at once.  It doesn't enormously matter for
Gimp-print, but it may make it easier for drivers to sanity check
early.

   * can there be default job properties or must every property be set?

Defaults should be allowed.  For example (using a Gimp-print
property), a user should not have to specify the ink type; the driver
should pick it automatically.

   * should we use a named pipe (or similar) to communicate to a driver or
     can we use an API?

stdin/stdout/stderr

   * should there be application presentation information that can be
     queried?  Some examples are:
	printable page size
	resolution
	current color depth
	font metrics

Yes.  It should be possible for the application to determine
e. g. what the current settings are.

   * can there be different job properties for each page?

     + Can this can be optional?

I don't much like it, but Mike presents a good case, and anyway
Gimp-print is really page-oriented anyway.

   * should we allow for future extensibility to support optional components
   of
     a printer driver?

       - should we require simulation?
	 That is if a driver only accepts bitmaps, then create a raster image
	 of the vector commands.  If a driver doesn't support rounded boxes
	 but does support arcs and lines, then break a round box into
	 multiple arc and line calls.

Yes.  The higher level software should break these things down as
appropriate.  Otherwise drivers have to duplicate code.

   * should we have an interface to query the printer's job dialog?
     This will allow for programmatic support of setting/querying the JPs.

Yes.  This actually maps very well to Gimp-print, particularly in
4.3.  It's a lot more flexible than a static file; expressing
constraints using boolean logic can get extremely complex.

	+ grouping/structuring

	+ constraints

	+ type of data (boolean, int, float, string, password, etc)

Add curve, vector, and raw to that, and I'll be happy.  Gimp-print
also supports file, but neither the Ghostscript nor the CUPS driver
supports this for security reasons (the only thing that uses it is the
GIMP plugin, so the Postscript family driver can find a PPD file).

   * should we require a standard install path?
     /usr/lib/print/driver/drivername
     /usr/share/print/font/drivername/

This is much too system-specific.  Obviously Windows will have
different conventions from UNIX (what, me defend Windows?), and
different UNIX versions/Linux distributions have different
conventions.  The printing system should manage that.

-- 
Robert Krawitz                                     <rlk@alum.mit.edu>      

Tall Clubs International  --  http://www.tall.org/ or 1-888-IM-TALL-2
Member of the League for Programming Freedom -- mail lpf@uunet.uu.net
Project lead for Gimp Print   --    http://gimp-print.sourceforge.net

"Linux doesn't dictate how I work, I dictate how Linux works."
--Eric Crampton

Re: [Printing-architecture] Re: [printing-driver] FSG Printer Working Group conference call 03/26/03

[Mike Sweet]

Robert L Krawitz wrote:
>    From: Mark Hamzy <hamzy@us.ibm.com>
>    Date: Mon, 24 Mar 2003 13:30:36 -0600
> 
>    * should printer drivers implement a required set of common job properties
>    (JP)?
>      Examples of keys would be: orientation, form, tray, media, duplex,
>    resolution.
> 
> These certainly don't apply to all printers; most inkjets don't
> support duplex, and many also don't have selectable input sources.
> I'd prefer to see a list of standard job properties that could be
> amended, and standards (and/or a registry) for drivers to support
> non-standard properties (such as the whole mess of things Gimp-print
> supports).

WRT the sides (duplex) attribute, the related sides-supported
attribute lists the supported values.  For a printer that does
not support duplexing, the only supported value will be
"one-sided".

As for the property "registry", that is one topic for the
capabilities API that will be part of PAPI 2.0 (or 1.1, or
whatever).  At present, it looks like we'll have an attribute
that lists the available job template attributes, additional
attributes to handle simple constraints, and finally an API
for doing round-trip constraint checks.

> ...
>    * should we have an interface to query the printer's job dialog?
>      This will allow for programmatic support of setting/querying the JPs.
> 
> Yes.  This actually maps very well to Gimp-print, particularly in
> 4.3.  It's a lot more flexible than a static file; expressing
> constraints using boolean logic can get extremely complex.

First, we need static files (or the equivalent attributes) for
the UI; there cannot be a direct interface between app and driver,
otherwise we're repeating the same old errors that have been
cursed on Windows.

Second, all constraints can be expressed using boolean logic;
putting them in code or in a file doesn't matter much - the
same amount of complexity is required either way.  Keep in mind
that we are planning on providing a constraint mechanism that
is a superset of that supported by PPD and that there will still
be a way to do full round-trip constraint checks through the
printing system (if supported); the latter checks are meant for
sanity checks when submitting options/jobs and not for on-the-fly
constraint checking when a user changes an option.

-- 
______________________________________________________________________
Michael Sweet, Easy Software Products                  mike@easysw.com
Printing Software for UNIX                       http://www.easysw.com

Re: [Printing-architecture] Re: [printing-driver] FSG Printer Working Group conference call 03/26/03

[Robert L Krawitz]

   Date: Mon, 24 Mar 2003 21:13:35 -0500
   From: Mike Sweet <mike@easysw.com>

   >    * should we have an interface to query the printer's job dialog?
   >      This will allow for programmatic support of setting/querying the JPs.
   > 
   > Yes.  This actually maps very well to Gimp-print, particularly in
   > 4.3.  It's a lot more flexible than a static file; expressing
   > constraints using boolean logic can get extremely complex.

   First, we need static files (or the equivalent attributes) for the
   UI; there cannot be a direct interface between app and driver,
   otherwise we're repeating the same old errors that have been cursed
   on Windows.

True; I guess I glossed over the "job dialog" part.  However, I don't
think that there actually need to be static files; an API to the
printing system (whereby the printing system acts as an abstraction
barrier between the application and the driver) would also accomplish
this end.  The back end of this could be whatever the driver and the
printing system agree on: it could be a PPD file for some drivers and
an interface module (like rastertoprinter or ijsgimpprint) between the
driver and the printing system for others.

   Second, all constraints can be expressed using boolean logic;
   putting them in code or in a file doesn't matter much - the same
   amount of complexity is required either way.

Not necessarily; the internal logic might be dynamic, based on the
printer state (e. g. the driver might want to offer only options that
are actually installed on the printer), or it might reference internal
driver logic that's unwieldly to express via logic or simply doesn't
need to be exposed to the application.  To illustrate what I mean, the
compressed Gimp-print PPD files for the Epson Stylus printers total
1440 KB (each one totals about 12 KB; the entire compressed source
code for the Epson family driver totals 48 KB, even though Gimp-print
doesn't query printer status (it does offer dynamic options based on
the state of other options).
						 
						 Keep in mind that we
   are planning on providing a constraint mechanism that is a superset
   of that supported by PPD and that there will still be a way to do
   full round-trip constraint checks through the printing system (if
   supported); the latter checks are meant for sanity checks when
   submitting options/jobs and not for on-the-fly constraint checking
   when a user changes an option.

Can it express certain options being entirely unavailable in some
circumstances (e. g. when the user chooses to print in black and
white, color controls should be disabled)?

-- 
Robert Krawitz                                     <rlk@alum.mit.edu>      

Tall Clubs International  --  http://www.tall.org/ or 1-888-IM-TALL-2
Member of the League for Programming Freedom -- mail lpf@uunet.uu.net
Project lead for Gimp Print   --    http://gimp-print.sourceforge.net

"Linux doesn't dictate how I work, I dictate how Linux works."
--Eric Crampton

Re: [Printing-architecture] Re: [printing-driver] FSG Printer Working Group conference call 03/26/03

[Michael Sweet]

Robert L Krawitz wrote:
> ...
>    First, we need static files (or the equivalent attributes) for the
>    UI; there cannot be a direct interface between app and driver,
>    otherwise we're repeating the same old errors that have been cursed
>    on Windows.
> 
> True; I guess I glossed over the "job dialog" part.  However, I don't
> think that there actually need to be static files; an API to the
> printing system (whereby the printing system acts as an abstraction
> barrier between the application and the driver) would also accomplish
> this end.  The back end of this could be whatever the driver and the
> printing system agree on: it could be a PPD file for some drivers and
> an interface module (like rastertoprinter or ijsgimpprint) between the
> driver and the printing system for others.

Right, but from the application/PAPI standpoint, that interface
is hidden.

(and from the CUPS standpoint, we *will not* be supporting a
direct scheduler<->driver interface, as that opens up serious
security and performance issues...)

>    Second, all constraints can be expressed using boolean logic;
>    putting them in code or in a file doesn't matter much - the same
>    amount of complexity is required either way.
> 
> Not necessarily; the internal logic might be dynamic, based on the
> printer state (e. g. the driver might want to offer only options that
> are actually installed on the printer), or it might reference internal
> driver logic that's unwieldly to express via logic or simply doesn't
> need to be exposed to the application.  To illustrate what I mean, the

First, "dynamic" logic based upon the current printer state is not
dynamic - it is static logic based upon dynamic information,
something that the current design allows for and is already
implemented with some drivers in PPD files for CUPS.

> compressed Gimp-print PPD files for the Epson Stylus printers total
> 1440 KB (each one totals about 12 KB; the entire compressed source
> code for the Epson family driver totals 48 KB, even though Gimp-print
> doesn't query printer status (it does offer dynamic options based on
> the state of other options).

That's not a valid comparison - you'd need to compare the size of
the constraints in PPD files to the constraints in code.  IIRC,
there are *no* constraints in the current GIMP-print PPD files...

Any textual representation of attributes, constraints, etc. will
generally be larger than the compiled code that uses them - it
doesn't matter whether this data is in a static file (PPD, UPDF,
etc.) or is passed via a direct interface.

That said, using a separate data store (file and/or attributes in
memory) to hold this information has several pleasant effects:

     1. Apps can locally resolve constraints in real-time
        (for the user: things work faster) vs. round-trip
        delays and resending of every selected attribute.

     2. Drivers can be totally data-based, allowing new devices
        to be added relatively easily (barring major format/
        protocol changes requiring new support code)

     3. Printer/driver state and capability information can be
        provided locally and over the network to multiple
        platforms, and can be converted to any designed format
        or interface.

 > ...
> Can it express certain options being entirely unavailable in some
> circumstances (e. g. when the user chooses to print in black and
> white, color controls should be disabled)?

Certainly, as can PPD files...

-- 
______________________________________________________________________
Michael Sweet, Easy Software Products           mike at easysw dot com
Printing Software for UNIX                       http://www.easysw.com

Re: [Printing-architecture] Re: [printing-driver] FSG Printer Working Group conference call 03/26/03

[Robert L Krawitz]

   From: Michael Sweet <mike@easysw.com>
   Date: Tue, 25 Mar 2003 10:22:09 -0500

   Robert L Krawitz wrote:
   > ...
   >    First, we need static files (or the equivalent attributes) for the
   >    UI; there cannot be a direct interface between app and driver,
   >    otherwise we're repeating the same old errors that have been cursed
   >    on Windows.
   > 
   > True; I guess I glossed over the "job dialog" part.  However, I
   > don't think that there actually need to be static files; an API
   > to the printing system (whereby the printing system acts as an
   > abstraction barrier between the application and the driver) would
   > also accomplish this end.  The back end of this could be whatever
   > the driver and the printing system agree on: it could be a PPD
   > file for some drivers and an interface module (like
   > rastertoprinter or ijsgimpprint) between the driver and the
   > printing system for others.

   Right, but from the application/PAPI standpoint, that interface is
   hidden.

Agreed; the application shouldn't know where the data comes from.

BTW, whatever the driver interface looks like, I could see a use for
a back end other than a file -- suppose a large company wants to have
a common set of printing options for all of its printers; it could use
a network service to distribute the printing information, rather than
having to copy flat files to every single workstation in the company.

   (and from the CUPS standpoint, we *will not* be supporting a
   direct scheduler<->driver interface, as that opens up serious
   security and performance issues...)

What's the security issue?

   > Not necessarily; the internal logic might be dynamic, based on the
   > printer state (e. g. the driver might want to offer only options that
   > are actually installed on the printer), or it might reference internal
   > driver logic that's unwieldly to express via logic or simply doesn't
   > need to be exposed to the application.  To illustrate what I mean, the

   First, "dynamic" logic based upon the current printer state is not
   dynamic - it is static logic based upon dynamic information,
   something that the current design allows for and is already
   implemented with some drivers in PPD files for CUPS.

True enough.

   > compressed Gimp-print PPD files for the Epson Stylus printers total
   > 1440 KB (each one totals about 12 KB; the entire compressed source
   > code for the Epson family driver totals 48 KB, even though Gimp-print
   > doesn't query printer status (it does offer dynamic options based on
   > the state of other options).

   That's not a valid comparison - you'd need to compare the size of
   the constraints in PPD files to the constraints in code.  IIRC,
   there are *no* constraints in the current GIMP-print PPD files...

All right, that's fair enough.

Another issue that didn't occur to me last night is that actually
going through and computing the constraints (to generate PPD
constraints) is expensive; in principle, genppd would have to set all
of the option to all of the possible values to determine the legal
combinations.  While in practice it's not that bad, it's much easier
to determine the legal values for a given option in the context of all
other current settings.

(Ironically, the reason it's not actually "all that bad" is because
Gimp-print's very permissive -- it's perfectly happy to let you set
2880x1440 with 7-color inks printing line art to plain paper, and it's
also willing to let you print full bleed on all paper sizes, not just
those where there's a pad under the carriage to catch the ink that
bleeds over.  It's also very happy to let you set arbitrary options
that aren't used by the current driver, and simply ignores them.)

   Any textual representation of attributes, constraints, etc. will
   generally be larger than the compiled code that uses them - it
   doesn't matter whether this data is in a static file (PPD, UPDF,
   etc.) or is passed via a direct interface.

I was comparing it to the source code, not the compiled code.

   That said, using a separate data store (file and/or attributes in
   memory) to hold this information has several pleasant effects:

	2. Drivers can be totally data-based, allowing new devices
	   to be added relatively easily (barring major format/
	   protocol changes requiring new support code)

I have no objection to this at all; I'd just like to see other options
available for drivers that are more complicated.

-- 
Robert Krawitz                                     <rlk@alum.mit.edu>      

Tall Clubs International  --  http://www.tall.org/ or 1-888-IM-TALL-2
Member of the League for Programming Freedom -- mail lpf@uunet.uu.net
Project lead for Gimp Print   --    http://gimp-print.sourceforge.net

"Linux doesn't dictate how I work, I dictate how Linux works."
--Eric Crampton

Re: [Printing-architecture] Re: [printing-driver] FSG Printer Working Group conference call 03/26/03

[Mike Sweet]

Robert L Krawitz wrote:
 > ...
>    (and from the CUPS standpoint, we *will not* be supporting a
>    direct scheduler<->driver interface, as that opens up serious
>    security and performance issues...)
> 
> What's the security issue?

The two main ones are:

     1. If we directly connect to the driver/library, then any buffer
        overflows in the driver/library might be exploited to gain
        root access.  Thus, we won't directly connect...

     2. If we indirectly connect to the driver/library, and do it
        "safely" with a non-priviledged user with pipes to and from
        the backend so the driver can communicate with the device,
        we run the risk of a DoS attack if more than one user wants
        to print at the same time and needs the "dynamic" driver
        data.  This also falls under the performance umbrella...

The mechanism we will be using in CUPS 1.2 is an asynchronous
device daemon with a "port monitor" facility that will allow
developers to provide printer driver filter(s) and a "port
monitor" program; the filter(s) will handle the production of
data suitable for the printer, while the (optional) port
monitor handles printer queries, data encoding, etc.  One other
task for the port monitor is periodic status updates via the
device monitor - this will allow the port monitor to update the
PPD file for current device configuration, update the printer
object for current state, etc.

> ...
> Another issue that didn't occur to me last night is that actually
> going through and computing the constraints (to generate PPD
> constraints) is expensive; in principle, genppd would have to set all
> of the option to all of the possible values to determine the legal
> combinations.  While in practice it's not that bad, it's much easier
> to determine the legal values for a given option in the context of all
> other current settings.
 > ...

I have some code we're using for the HP APDK drivers in ESP Print
Pro (those are the same ones that come in HP IJS, although the IJS
drivers are stripped down in comparison...) that may come in handy
for doing the basic constraints.  It isn't that bad for the
relatively small number of drivers we have to generate PPD files
for...

Ideally we should be able to provide a GIMP-print API for
retrieving the driver constraints and/or put all of the driver-
specific data in the printers.xml file so that the driver and
PPD files are data driven and not hardcoded.  This would also
make it possible for programmatic PPD file generation - CUPS
would ask GIMP-print for a list of the drivers it supports
along with "virtual" PPD filenames, and then CUPS can have
GIMP-print write the PPD file in /etc/cups/ppd as requested by
the administrator.

-- 
______________________________________________________________________
Michael Sweet, Easy Software Products                  mike@easysw.com
Printing Software for UNIX                       http://www.easysw.com

Re: [Printing-architecture] Re: [printing-driver] FSG Printer Working Group conference call 03/26/03

[Robert L Krawitz]

   Date: Tue, 25 Mar 2003 23:31:44 -0500
   From: Mike Sweet <mike@easysw.com>

   Robert L Krawitz wrote:
    > ...
   >    (and from the CUPS standpoint, we *will not* be supporting a
   >    direct scheduler<->driver interface, as that opens up serious
   >    security and performance issues...)
   > 
   > What's the security issue?

   The two main ones are:

	1. If we directly connect to the driver/library, then any buffer
	   overflows in the driver/library might be exploited to gain
	   root access.  Thus, we won't directly connect...

Yup, that makes sense.  The driver should in any event run with the
least possible privilege.

	2. If we indirectly connect to the driver/library, and do it
	   "safely" with a non-priviledged user with pipes to and from
	   the backend so the driver can communicate with the device,
	   we run the risk of a DoS attack if more than one user wants
	   to print at the same time and needs the "dynamic" driver
	   data.  This also falls under the performance umbrella...

   The mechanism we will be using in CUPS 1.2 is an asynchronous
   device daemon with a "port monitor" facility that will allow
   developers to provide printer driver filter(s) and a "port monitor"
   program; the filter(s) will handle the production of data suitable
   for the printer, while the (optional) port monitor handles printer
   queries, data encoding, etc.  One other task for the port monitor
   is periodic status updates via the device monitor - this will allow
   the port monitor to update the PPD file for current device
   configuration, update the printer object for current state, etc.

That sounds like a good architecture anyway.  I don't see why the
filter couldn't also act as an "option server" or some such, though.

   Ideally we should be able to provide a GIMP-print API for
   retrieving the driver constraints and/or put all of the driver-
   specific data in the printers.xml file so that the driver and PPD
   files are data driven and not hardcoded.  This would also make it
   possible for programmatic PPD file generation - CUPS would ask
   GIMP-print for a list of the drivers it supports along with
   "virtual" PPD filenames, and then CUPS can have GIMP-print write
   the PPD file in /etc/cups/ppd as requested by the administrator.

Any suggestions from your experience what kind of constructs might be
good for this purpose?

-- 
Robert Krawitz                                     <rlk@alum.mit.edu>      

Tall Clubs International  --  http://www.tall.org/ or 1-888-IM-TALL-2
Member of the League for Programming Freedom -- mail lpf@uunet.uu.net
Project lead for Gimp Print   --    http://gimp-print.sourceforge.net

"Linux doesn't dictate how I work, I dictate how Linux works."
--Eric Crampton

Re: [Printing-architecture] Re: [printing-driver] FSG Printer Working Group conference call 03/26/03

[Mike Sweet]

Robert L Krawitz wrote:
> ...
> That sounds like a good architecture anyway.  I don't see why the
> filter couldn't also act as an "option server" or some such, though.

You'd be forcing every driver to handle multiple requests at the
same time, or serializing requests which would invoke a serious
performance hit.  Also, keep in mind that serving a static file/
data store involves MUCH less CPU/IO than processing each query
individually.  Any solution we come up with has to scale to
thousands of printers and users.

>    Ideally we should be able to provide a GIMP-print API for
>    retrieving the driver constraints and/or put all of the driver-
>    specific data in the printers.xml file so that the driver and PPD
>    files are data driven and not hardcoded.  This would also make it
>    possible for programmatic PPD file generation - CUPS would ask
>    GIMP-print for a list of the drivers it supports along with
>    "virtual" PPD filenames, and then CUPS can have GIMP-print write
>    the PPD file in /etc/cups/ppd as requested by the administrator.
> 
> Any suggestions from your experience what kind of constructs might be
> good for this purpose?

You already have most of the data in structures right now - just move
it to the XML file and add the constraint data.  The PPD file then
just needs to reference the instance in the XML file (e.g. driver
name, ID, etc., like we already have...)

-- 
______________________________________________________________________
Michael Sweet, Easy Software Products                  mike@easysw.com
Printing Software for UNIX                       http://www.easysw.com

Re: [Printing-architecture] Re: [printing-driver] FSG Printer Working Group conference call 03/26/03

[Pete Zannucci]

From: Robert L Krawitz <rlk@alum.mit.edu>

> True; I guess I glossed over the "job dialog" part.  However, I don't
> think that there actually need to be static files; an API to the
> printing system (whereby the printing system acts as an abstraction
> barrier between the application and the driver) would also accomplish
> this end.  The back end of this could be whatever the driver and the
> printing system agree on: it could be a PPD file for some drivers and
> an interface module (like rastertoprinter or ijsgimpprint) between the
> driver and the printing system for others.


The goal should be to abstract away the ugliness of the system and
provide a clean simple API for the application.  Applications should
not be concerned about the underlying architecture or implementation.

Secondly it would be nice if we could agree upon a single format for
storage of the properties based on the current printer configuration.
The driver/backend could use whatever mechanism it wants to use for
generating or using information internally but if properties could
be stored by the print system/driver when settings change or at
install/config time in a common database, that will ease the burden of
having to put translation layers in for each of the formats going to
the application interface.  This would allow consistent information be
returned to the app.  It would also solve a lot of portability issues
between systems and make the interface consistent and less error prone.




Peter Zannucci

IBM Linux Technology Center
Open Source Software Development
Omni Print Project http://sourceforge.net/projects/omniprint
Austin, TX - Tel. 512-838-4687 (t/l 678) pzaan@us.ibm.com

Re: [Printing-architecture] Re: [printing-driver] FSG Printer Working Group conference call 03/26/03

[Robert L Krawitz]

   From: "Pete Zannucci" <pzaan@us.ibm.com>
   Date: Tue, 25 Mar 2003 08:06:22 -0600

   From: Robert L Krawitz <rlk@alum.mit.edu>

   > True; I guess I glossed over the "job dialog" part.  However, I
   > don't think that there actually need to be static files; an API
   > to the printing system (whereby the printing system acts as an
   > abstraction barrier between the application and the driver) would
   > also accomplish this end.  The back end of this could be whatever
   > the driver and the printing system agree on: it could be a PPD
   > file for some drivers and an interface module (like
   > rastertoprinter or ijsgimpprint) between the driver and the
   > printing system for others.

   The goal should be to abstract away the ugliness of the system and
   provide a clean simple API for the application.  Applications
   should not be concerned about the underlying architecture or
   implementation.

Agreed.  It's the back end (from the printing system on down) I'm
talking about.

   Secondly it would be nice if we could agree upon a single format
   for storage of the properties based on the current printer
   configuration.  The driver/backend could use whatever mechanism it
   wants to use for generating or using information internally but if
   properties could be stored by the print system/driver when settings
   change or at install/config time in a common database, that will
   ease the burden of having to put translation layers in for each of
   the formats going to the application interface.  This would allow
   consistent information be returned to the app.  It would also solve
   a lot of portability issues between systems and make the interface
   consistent and less error prone.

BTW, how would we represent ICC profiles (for example)?

-- 
Robert Krawitz                                     <rlk@alum.mit.edu>      

Tall Clubs International  --  http://www.tall.org/ or 1-888-IM-TALL-2
Member of the League for Programming Freedom -- mail lpf@uunet.uu.net
Project lead for Gimp Print   --    http://gimp-print.sourceforge.net

"Linux doesn't dictate how I work, I dictate how Linux works."
--Eric Crampton