[Omniprint-user] Re: [printing-driver] Re: [printing-cap] Re: [Inkjet-list] Re: Taking a step back

[Pete Z. <pz...@us...>]

>> > Ultimately, you *really* want a static snapshot of what a driver
>> > can
>>
>> I think that this is a bit of an implementation thing. I really don't
>> want a static representation.
>>
>> > do.  This ideally should be a data file that can be read by a
>> > driver/ filter (using a standard API of course) to handle any
>> > printer/job specific setup.  For devices whose options depend on,
>> > say, what kind of ink cartridge is installed, a background driver
>> > process can monitor the printer and update the static snapshot as
>> > needed (and obviously any driver would need to reject/stop a job
>> > that won't print on the current configuration)
>>
>> I'm really not a fan of this functionality. I'd much rather have some
>> sort IPC mechanism rather than some sort of dropbox.
>
> The problem with IPC is that it can cause major performance problems,
> especially if you have to wait for a driver program to try to
> communicate with a printer, which may be servicing a request from
> another process/system which also wants to print...  Also, any IPC
> mechanism you come up with has to be supported over networks to be
> useful - network transparency is a requirement in today's "connected"
> world...
>
> No matter how you do it, your application will only have a static
> snapshot from when it queried the printer driver.  Rebuilding this
> snapshot each time it is requested is inefficient and will lead to
> major performance and availability issues.

This all really depends on what set of problems you want to solve.
If you look at several scenarios it will better define the components
that are needed and the way you could handle most of the scenarios.
We need to handle:
-  Device configuration information dynamic from the printer
-  Status information returned from the printer
-  Local configured printer
-  Network configured printer

1. Local printer configuration and capabilities

  The local printing (single user) scenario is fairly easily handled
  when utilizing IPC mechanisms.  Latency and information about the
  printer go away in this scenario because you don't have to worry
  about the 100 user scenarios.
  Information does not necessarily need to be statically maintained
  unless the printer does not handle bi-directional information
  that fully describes its configuration.  If the printer does not
  handle everything, then it should be up to some API interface into
  the print subsystem to be able to provide a representation of the
  configuration back to the application.  Notice I said interface and
  is required no matter where the information is coming from.

  The Print Summit was about interfaces and how do we get at the info.
  that is needed so that there can be consistency as the print system
  in Linux does its necessary evolution.

  It can be done by reading a PPD or it can be done by calling a printer
  driver and getting the current information back.  In either scenario,
  it would be a very good idea to have an API that can return the
  information in a STANDARD format to a calling application.  It would
  be of benefit if any information that may need to be extended, such
  as driver information, be abstracted away to an API that will allow
  for a standard format of information to be passed back so that as
  things evolve the APIs should be consistent from an application
  perspective.

   Local printer status information

  When doing local printing, the status should be immediate and any
  device specific protocol converter (daemon) of the data be manage
  the flow to and from the printer to always maintain an accurate
  account of the status of the job and printer state.

2. Networked printer configuration and capabilities

  In a networked environment with multiple users the problem gets
  a little harder.  It now depends on the components and how you
  manage the components but you are going to have to rely more on
  a static representation of the printer than a dynamic one.
  Again, if you have some protocol conversion daemon that is managing
  the data going back and forth between the printer and the system,
  it will know the current state of the printer and if it will have to
  rely on a statically cached version of the configuration or it can
  actually request an update from the printer.

   Networked printer status

  This one will work very similar in that if the converter is managing
  the flow of data and it understands the state of the printer, it can
  make the decision on if it can query the printer or it has to pass
  back to a caller (spooler or gui app) a static cache of the last known
  state of the printer.
  The static cache is necessary to avoid latency in the information.
  The conversion code should be able to know the type of the printer and
  when a transaction can occur with the printer.


Again, there should be:

  - Common API interfaces for getting the information to the application
  - Standard data format that is returned to the application looking for
    capabilities
    Underlying code and implementation does not need to be exposed as long
    as there is a defined API for getting the data in a standard format.
  - Tightly coupled component with the printer driver to manage the data
    flow to and from the printer and allow for things like getting caps.
    information from the printer, getting status from the printer,
    restarting pages and/or jobs, and aborting jobs.
  - An IPC mechanism for getting dynamic information from the driver and
    subsystem will be mandatory for licensing purposes.  It would likely
    be simpler if a singular interface could be used by both an application
    and the renderer.


** This of course doesn't include multiple systems hitting one printer or
   a networked environment where the printers are on different networks.

We went round and round a number of times on implementations and for
capabilities once we did the preliminary work for the summit, it really
got down to standardizing a way for the application to get the information
about the device and a way the driver gets told the settings when the job's
data is to be generated.

Fonts and drawing caps. are a different issue and purely dependant on the
rendering system and printer driver combo.



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) pz...@us...