Menu
▾
▴
omniprint-developer
|
From: Pete Z. <pz...@us...> - 2002-01-08 22:27:31
|
>> > 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...
|
|
From: Michael S. <mi...@ea...> - 2002-01-09 13:59:45
|
On Tuesday 08 January 2002 05:27 pm, Pete Zannucci wrote: > ... > 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 I would argue that we do not want to distinguish between a local and network printer. All printers should be treated the same, and an application that communicates with a local print queue should be able to access a network print queue the same way. Again, I'm harping on network transparency! > 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. I would argue that even a single user will have multiple windows, etc. open that want to access a printer at the same time, especially to check the current status. > 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 Most printers cannot "fully describe" their configuration. The smartest inkjets provide a model ID (which often is too general to be of use), installed inkset, paper status, and ink levels. That is enough if you know which driver to use, etc., but not which variety of ESC/P, PCL, etc. to use, and what capabilities the printer has. > ... > 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 Right, and currently the best match for that "standard" format is a PPD file, which is supported by a lot of applications and adequately describes most options. I'm not saying PPD is the best format in the world (there are many issues, and I'm quite sure that Adobe would be interested in addressing them in a new rev of the spec), but it is the best supported format, both under Linux and other operating systems. It is also already in use in all of the scenarios that have been brought up. > ... > 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. The device daemon should *not* try to understand the data to/from the printer, nor should we expect it to track printer or job status. Specialization leads to bloat and all sorts of implementation problems. > ... > - 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. > ... I would argue that an IPC mechanism at the application level has already been defined and implemented - IPP. Between driver and device, the interface to use is the pipe/socket: that abstracts the device IO into simple modules that can be reused for many drivers and devices. The printer-specific stuff is then handled entirely by the printer driver, which has to be specialized... As for licensing issues, simpler public interfaces eliminate this problem - if a vendor doesn't like the license the "standard" implementation uses, it can roll its own interfaces. The TurboPrint folks do this for their CUPS drivers, for example, since they don't want to link to the CUPS imaging library (which is GPL'd, while the rest of the CUPS API is LGPL'd...) to read the raster data. Instead, they rolled their own read-header/pixels code. -- ______________________________________________________________________ Michael Sweet, Easy Software Products mi...@ea... Printing Software for UNIX http://www.easysw.com |
|
From: Robert L K. <rl...@al...> - 2002-01-10 00:56:17
|
From: Michael Sweet <mi...@ea...> Date: Wed, 9 Jan 2002 09:00:26 -0500 On Tuesday 08 January 2002 05:27 pm, Pete Zannucci wrote: > ... > 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 I would argue that we do not want to distinguish between a local and network printer. All printers should be treated the same, and an application that communicates with a local print queue should be able to access a network print queue the same way. Again, I'm harping on network transparency! I agree with this. I would further argue that if the behavior of the printer differs depending upon whether it's locally connected in a single user environment vs. remotely connected, or in a multiuser environment, that the system violates the "principle of least surprise". Unless it's absolutely impossible to provide identical semantics (which I don't believe it is here), distinguishing these two cases will simply lead to user confusion. > 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. I would argue that even a single user will have multiple windows, etc. open that want to access a printer at the same time, especially to check the current status. While it's true that the latency issue largely goes away in this case (at least if the printer supports an IEEE 1284.4 packet mode, which Epson printers do, and the driver deals with this), it's really not clear to me why we want to special case this. > 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. The device daemon should *not* try to understand the data to/from the printer, nor should we expect it to track printer or job status. Specialization leads to bloat and all sorts of implementation problems. Depends upon exactly what the device daemon does. If the device daemon actually talks to the printer, it may have to understand the data if the printer is a winprinter (the infamous Samsung laser printer requires reasonably correct timing for sending data). But the application shouldn't know about the existence of something like this, and certainly shouldn't talk to it. > - 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. I would argue that an IPC mechanism at the application level has already been defined and implemented - IPP. Between driver and device, the interface to use is the pipe/socket: that abstracts the device IO into simple modules that can be reused for many drivers and devices. The printer-specific stuff is then handled entirely by the printer driver, which has to be specialized... I'd like to repeat my question to the people advocating a new mechanism: what required capabilities does IPP lack? -- Robert Krawitz <rl...@al...> http://www.tiac.net/users/rlk/ Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2 Member of the League for Programming Freedom -- mail lp...@uu... Project lead for Gimp Print/stp -- http://gimp-print.sourceforge.net "Linux doesn't dictate how I work, I dictate how Linux works." --Eric Crampton |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X