From: Mark H. <ha...@us...> - 2001-12-26 21:22:51
|
First, I would like to point out that I am not an IBM spokesperson. Don't take my views as "IBM says you should do this." I am just someone who has worked with printer drivers on multiple operating systems for ten years. Second, this group came together to work on standards for Linux in the area of printing. No one person should control it and everyone should come together in agreement for what direction Linux should take. At this stage, proposals should be announced. It shouldn't be one or another. We should look at existing solutions and if they do not provide what we need, then we should take the best ideas from everyone and create something new. IPP has looked at and standardized on many things that relate to printing. However, they look at it from the view point of the physical printer instead of from the software printer driver. I need to reread all the IPP documentation. However, if each printer driver is an IPP server, can it handle that? Also, it defines the contents of the job as a block of binary data. There are many steps in going from high level calls to the printer control language that a printer driver and operating system need. I think that there are many different areas that make up a printer driver. It is not just a filter to translate raster bitmap data into printer control language. For example, there is another subgroup that is talking about printer capabilities. That should be included in what makes up a printer driver. Also, drivers need to have translatable resources such as form names that can be used to build a graphical representation of itself. Should there be many different pieces of software to install or protocols to speak to be able to handle each of these? All of the things that are considered as "the Omni group" put into PDC should not be viewed as proprietary extensions. These are some of the things that I think are necessary as paradigms of common printer driver information and setup. I have tried to design this to be as easy as possible for other printer drivers to implement. There should be as much information and routines as possible to be common for the best user experience. Now that that was said, let me move on to the differences between PDC and IJS. Printer Capabilities -------------------- The capabilities subgroup needs to query the printer driver at runtime and not though a static file (like a PPD). Also, I believe that applications will want to be able to select between different print paths based on the printer's capabilities. Translatable Resources ---------------------- A GUI application will need to query the printer driver for its strings as well as hints as to how to display the information. High Level Device Acceleration ------------------------------ While inkjets may not need acceleration, there are other printers that do. It is much more efficient to transfer a high level call like drawing a rounded box than it is to transfer a bitmap image of that box. Some examples of high level languages are: HP-GL/2, PCL6, and even Postscript. Should there be two different code paths for printing to an inkjet printer vs printing to a Postscript printer? Device Fonts ------------ One example of reducing data that is sent to the printer driver is to use device fonts that are resident in the printer. To achieve WYSIWYG printing, an application will have to query the printer driver for its font metrics. Constraints ----------- In order to prevent printing duplex on transparencies, the application should be told by the printer driver that this will cause a problem. A printer driver writer will know what are the constraints that the device places on the coder but there is no way to let an application know. Job id vs New Instance of Communications ---------------------------------------- I believe that making the client allocate and keep track of job ids causes extra complexity without any benefit. It is easier to start another communications session to the printer driver. This way, the printer driver does not have to keep track that id X is in page Y and band Z while id X' has just started. Also, I don't see how the output from multiple simultaneous jobs are kept separate. Form Size vs Form Name ---------------------- The form should be selected by the media name. First, there is a non-exact conversion between inches and millimeters. Second, it is easier to remember the form name rather than the form size. For example, a non-US user wants to print out on A3 paper. Is it easier to specify 11.69x16.53 or iso_A3? While a table may help, if a new form comes out, then it will be unknown to the application. Device Name ----------- Printer drivers that handle many different categories of devices need to be told unequivocally what the model name and device name is. It should not have to do a bidirectional call to query the printer name (one reason why would be printing to a file). I believe that this is something that the operating system should store and tell the application and printer driver. All of the Job Properties ------------------------- I think that the protocol should send every job property to the printer driver. It should also, in the best case, set all of the job properties at once. PDC tries to define a set of common job properties that are the same between all drivers. It is difficult for the user to know that there is a set of Ghostscript job properties (-sPAPERSIZE=a4, -r300) and a set of IJS job properties (-dIjsDepth=24, -sIjsParam="..."). Printer Properties ------------------ Printer properties are necessary to know things like 4Mb of memory is installed and yellow paper is in tray 2. The printer driver will send different commands to the printer based on what printer properties are set. Mark Take a look at the Linux Omni printer driver at http://www.ibm.com/linux/ltc/projects/omni/ |
From: Pete Z. <pz...@us...> - 2002-01-10 20:28:06
|
> ... > 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. The above was an example of problems to solve, not all the problems or that each of the problems should be handled in different ways. If you don't define what we are trying to solve we will never put code in place to handle those conditions. This wasn't meant to differentiate the items. > 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 > Epson printers do, and the driver deals with this), it's really not > clear to me why we want to special case this. The point here was to explain that you don't need the caching mechanisms in place for having non-current information about the printer at a particular time. Only when the printer can't return real-time information (in the middle of processing data) will the query information of the device need to be pulled from a cache. At that point in time, everything will work the same between a multi-user printer and a single user. There isn't any difference except to make sure both cases can be handled in the same fashion. I would also state with most printers, you still will only have one process at a time accessing them so the item about multiple windows should go away. The spool system should be the process of choice because with most printers, you can't print to them from multiple apps. The application will not have access to the output device so spooling is the only real option here to return the application to the user when multiple apps are printing. > 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. This was to bring up a point that a separate process could track that data to and from the printer. The management of that data via that process would be beneficial because the associated code that is run by that process will know the specifics of the datastream and when it can query, abort, send additional info. etc. to the printer. If you have two printers that the protocol is the same, why re-write the code that manages the protocol (bidirectional send, receive, abort, restart, etc) code into each driver. The individual protocol code that can be shared on a grouping of printers therefore written once, tested once, and plugged in along with its sister printer driver. > - 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? I don't think that we are really advocating something other than IPP. It may end up that way but I think we are just talking about two different levels and communications areas of the system. From a printing application perspective, I would not want to have to code IPP into it. I would expect the appropriate subsystems to handle the management of this for me. I would expect nice query, set, page, job, and drawing commands to be all I would worry about. The system APIs I utilize should do all the management and how we talk to the printer from a system perspective should be nebulous. printer is. We are still grappling with the issues of renderer and driver interface in these groups. The licensing issue is very real and that is why it is a hot button for a number of people. Vendors would rather not have to open source their intellectual property because they have to run their drivers in the same process as open source licensed code. IPP is typical for use with communications between systems and systems/printers. This does not address the fact of how an application talks to a driver or finds out information about the capabilities of the subsystem and driver combination (fonts and other things that can be lumped under system). What I am pointing out is additional things that should be in place. What I was attempting to point out is that we need to define interfaces for standardization and to be able to allow extension. We shouldn't be tied to the past with things such as PPDs or munging them so that we now become incompatible with applications that might not know how to parse the data. An API needs to be defined with data structures, possibly XML, to isolate the application from having to do the tedious work such as parsing information that may need to be changed in the future. Methods and managing should be crisply defined for the application via an API for capabilities support. 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-10 21:27:46
|
On Thursday 10 January 2002 03:27 pm, Pete Zannucci wrote: > ... > The point here was to explain that you don't need the caching > mechanisms in place for having non-current information about the > printer at a particular time. Only when the printer can't return > real-time information (in the middle of processing data) will the > query information of the device need to be pulled from a cache. > At that point in time, everything will work the same between a > multi-user printer and a single user. There isn't any difference > except to make sure both cases can be handled in the same fashion. Without caching you are going to run very, very slowly with multiple users/processes asking for printer status. Also, state information queries can be very time consuming on some printers, due to the interface, amount of information, or protocol(s) being used. Also, many printers offer a "continuous update" mode that a driver can use to get status/configuration updates *when they happen*, instead of polling all the time. This further improves performance because the monitor only updates the status/config info as needed, rather than rebuilding that data at regular intervals, on-demand, or both. *My* point is that you *do* need a caching mechanism in place; it may not be used all the time, but it *will* be used. > I would also state with most printers, you still will only have one > process at a time accessing them so the item about multiple windows > should go away. The spool system should be the process of choice > because with most printers, you can't print to them from multiple Repeat after me: "Applications do not directly communicate with the printer device." Applications (and even the spooler, if you make the device monitor a separate daemon) communicate with an intermediary which manages access to the printer device. In the normal course of events, you may have several (or thousands) of processes/users requesting the current status of the printer. This is one of the reasons that a certain very popular Windows file/printer sharing program (SAMBA) has to cache all of the printer and job status information to keep up. Under UNIX/Linux today, few applications actually know enough to communicate with the printing system to keep track of the current printer and job information. In the future, thanks to GNOME and KDE, many more applications will be "printer-aware" and will be asking for things like "what is your current status", or "what is the status of the job I just printed for this user?". What does this mean? Well, for one thing we need to cache the state information. We also need to integrate state/configuration reporting with the printing system, so that applications have a single interface for printing. This interface will likely be abstracted to support multiple printing environments (e.g. KDEprint). > ... > This was to bring up a point that a separate process could track that > data to and from the printer. The management of that data via that > process would be beneficial because the associated code that is run > by that process will know the specifics of the datastream and when it > can query, abort, send additional info. etc. to the printer. > > If you have two printers that the protocol is the same, why re-write > the code that manages the protocol (bidirectional send, receive, > abort, restart, etc) code into each driver. The individual protocol > code that can be shared on a grouping of printers therefore written > once, tested once, and plugged in along with its sister printer > driver. Your first paragraph conflicts with the second. You can't write a general-purpose device interface (say, for IEEE-1284 packet mode) that can handle aborting a job cleanly by "managing the print data", unless you have the driver tell the device interface what each piece of data is. You might be able to define a subset of devices for which this would work, but doing it in a general way is very, very difficult. In CUPS we use pipes between the driver/filter processes and the backend (device interface) that communicates with the printer. CUPS 1.2 adds the "backchannel" pipe that allows bidirectional comm with the printer through the backend which handles the device-specific communication stuff. Both the driver/filter and backend processes can communicate information back to the scheduler which is provided to the client(s) that need it. If a job is cancelled, the printer driver is responsible for sending any required "cleanup" data to the backend - this will make sure that the current page is ejected, the printer is reset, and so forth. The point of the last paragraph is to show that it *is* possible to support device interface/backend software for multiple devices, or to substitute device interfaces, without having to change the printer driver or add special handling code to the device interface. > ... > From a printing application perspective, I would not want to have to > code IPP into it. I would expect the appropriate subsystems to > handle the management of this for me. I would expect nice query, > set, page, job, and drawing commands to be all I would worry about. > The system APIs I utilize should do all the management and how we > talk to the printer from a system perspective should be nebulous. > printer is. I believe that a lot of this is already available from the KDE and GNOME folks (for the general interface), and is provided specifically in the CUPS API for CUPS. > We are still grappling with the issues of renderer and driver > interface in these groups. The licensing issue is very real and that > is why it is a hot button for a number of people. Vendors would > rather not have to open source their intellectual property because > they have to run their drivers in the same process as open source > licensed code. Lets be honest - Ghostscript is the stumbling block, as most print files in UNIX are PostScript. Everything else is available in many forms and under many licenses, but Ghostscript is only available as GPL or AFPL. Putting a generic raster interface into Ghostscript is not new - we've been doing it since 1993 - and it works very well. The generic interface bypasses those licensing issues nicely. > IPP is typical for use with communications between systems and > systems/printers. This does not address the fact of how an > application talks to a driver or finds out information about the > capabilities of the subsystem and driver combination (fonts and other > things that can be lumped under system). What I am pointing out is > additional things that should be in place. Actually, IPP *does* address those things in several of the more recent extension proposals in the PWG. I *strongly* urge you to look at the PWG web site (http://www.pwg.org/ipp/) or talk with some of the people in IBM doing work on IPP... > What I was attempting to point out is that we need to define > interfaces for standardization and to be able to allow extension. We > shouldn't be tied to the past with things such as PPDs or munging PPDs are still the ONLY common printer description format that is available. They also have the advantage of limiting the amount of special-case stuff you need (XML for Printer Driver ABC, PPD for PostScript Printer XYZ, etc.) just to support printing. > them so that we now become incompatible with applications that might > not know how to parse the data. An API needs to be defined with data If you do it right, any compliant PPD parser will ignore the extra attributes/comments. > structures, possibly XML, to isolate the application from having to > do the tedious work such as parsing information that may need to be > changed in the future. Methods and managing should be crisply defined > for the application via an API for capabilities support. The PWG (again) has a working group developing a common XML format for printer description information, which may be adopted widely enough to be useful. That said, any successful replacement for PPD will have to support a superset of what PPD does, and allow for automated conversion from PPD to XML (and perhaps back to PPD) -- ______________________________________________________________________ Michael Sweet, Easy Software Products mi...@ea... Printing Software for UNIX http://www.easysw.com |
From: Michael S. <mi...@ea...> - 2001-12-27 00:04:07
|
On Wednesday 26 December 2001 04:16 pm, Mark Hamzy wrote: > ... > of from the software printer driver. I need to reread all the IPP > documentation. However, if each printer driver is an IPP server, can > it handle that? Also, it defines the contents of the job as a block Yes. It can also handle multiple printers using the same "server" but using different URIs. More specifically, each printer is an object, which can be mapped to one or more actual servers. > of binary data. There are many steps in going from high level calls > to the printer control language that a printer driver and operating > system need. No, it defines the print data as a typed block of data, which can be "application/octet-stream" (auto-sense the type) or a specific format identified by MIME type. In the case of CUPS, we figure out the file type and then determine which filter(s) need to be run to make a printable version of it. The MIME type database is loaded at runtime from one or more config files, and the PPD files for printers supplement this information via the cupsFilter attributes. Finally, the filtered print data is piped into a backend process which communicates with the printer. > ... > language. For example, there is another subgroup that is talking > about printer capabilities. That should be included in what makes up > a printer driver. Also, drivers need to have translatable resources > such as form names that can be used to build a graphical > representation of itself. Should there be many different pieces of > software to install or protocols to > speak to be able to handle each of these? Again, in the case of CUPS we use PPD files with extra attributes (which are ignored by Windows and MacOS clients) that define the available capabilities, options, conflicts, and data for the driver and filters that determine what the driver ends up getting. Ultimately, you *really* want a static snapshot of what a driver can 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) > ... > The capabilities subgroup needs to query the printer driver at > runtime and not though a static file (like a PPD). Also, I believe > that applications will want to be able to select between different > print paths based on the printer's capabilities. This isn't Windows or OS/2. Applications will almost universally produce PostScript until another format is universally supported. Also, many PostScript apps already support PPD files, so it makes sense to try to support it (even if you add your own extended attributes which the standard apps ignore) Also, trying to get printer drivers and applications to talk to each other directly is a mistake. It doesn't scale. Better to have the driver maintain a snapshot of the current configuration than to introduce potentially long round-trip times which may require UI intervention ("your printer is not connected or turned off") or have to be postponed because the device is busy. > ... > A GUI application will need to query the printer driver for its > strings as well as hints as to how to display the information. Again, a *static* file makes this a lot easier. I'm not 100% happy that the PPD spec only allows a single language right now, but others have suggested a common translation catalog that covers common options... > ... > While inkjets may not need acceleration, there are other printers > that do. It is much more efficient to transfer a high level call like > drawing a rounded box than it is to transfer a bitmap image of that > box. Some examples of high level languages are: HP-GL/2, PCL6, and > even Postscript. Should there be two different code paths for > printing to an inkjet printer vs printing to a Postscript printer? HP-GL/2 is a waste of time. There are too many special cases and too many differences in appearance between models (even within HP models). PCL 6 is an option, but can be handled by existing software like Ghostscript without requiring the application to know about it. PostScript, with all its weaknesses, is still the defacto standard printing format for UNIX apps. Any printing solution will have to support it to be accepted, which is why CUPS includes a version of GNU Ghostscript for non-PS printers, and why we use PPDs. > ... > One example of reducing data that is sent to the printer driver is to > use device fonts that are resident in the printer. To achieve > WYSIWYG printing, > an application will have to query the printer driver for its font > metrics. The printer driver is not the right place for this; the printing system needs to manage fonts, and provide an API for drivers to register/retrieve them. > ... > something that the operating system should store and tell the > application and printer driver. The application should no nothing about what driver is being used, just what capabilities the printer has... -- ______________________________________________________________________ Michael Sweet, Easy Software Products mi...@ea... Printing Software for UNIX http://www.easysw.com |
From: Robert L K. <rl...@al...> - 2001-12-28 00:17:07
|
From: Michael Sweet <mi...@ea...> Date: Wed, 26 Dec 2001 19:05:00 -0500 Ultimately, you *really* want a static snapshot of what a driver can 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 generally in favor of a dynamic view of what the driver can do, because the constraints might be very complex, but this is an interesting thought. However, why do we need an actual file in the filesystem (as opposed to some virtualized way of getting a handle to a PPD file)? Do applications rely on open()/fopen() of PPD files, or is there some more abstract way of getting this information? > The capabilities subgroup needs to query the printer driver at > runtime and not though a static file (like a PPD). Also, I > believe that applications will want to be able to select between > different print paths based on the printer's capabilities. This isn't Windows or OS/2. Applications will almost universally produce PostScript until another format is universally supported. Also, many PostScript apps already support PPD files, so it makes sense to try to support it (even if you add your own extended attributes which the standard apps ignore) Extensions like this don't scale very well either; everybody will define their own extensions (look at what Cups-o-matic does; it uses structured comments in the PPD file to encode a perl data structure!). Also, trying to get printer drivers and applications to talk to each other directly is a mistake. It doesn't scale. Better to have the driver maintain a snapshot of the current configuration than to introduce potentially long round-trip times which may require UI intervention ("your printer is not connected or turned off") or have to be postponed because the device is busy. I don't think we should think in terms of a single-threaded server-based driver, but having some way of querying the driver (even if it's a different process) would be useful. I'm not convinced that we need to address this in the first go-round, but ultimately we will. > While inkjets may not need acceleration, there are other printers > that do. It is much more efficient to transfer a high level call > like drawing a rounded box than it is to transfer a bitmap image > of that box. Some examples of high level languages are: HP-GL/2, > PCL6, and even Postscript. Should there be two different code > paths for printing to an inkjet printer vs printing to a > Postscript printer? PostScript, with all its weaknesses, is still the defacto standard printing format for UNIX apps. Any printing solution will have to support it to be accepted, which is why CUPS includes a version of GNU Ghostscript for non-PS printers, and why we use PPDs. I agree wholeheartedly with this. Applications normally shouldn't generate raw printer data; Postscript is no worse of an IL than anything else. -- 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 |
From: Ben W. <be...@zo...> - 2002-01-08 11:25:45
|
> 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. <snip> > Also, trying to get printer drivers and applications to talk to > each other directly is a mistake. It doesn't scale. Better to I personally think this is completely wrong. I don't see how it doesn't scale at all. > have the driver maintain a snapshot of the current configuration > than to introduce potentially long round-trip times which may > require UI intervention ("your printer is not connected or turned > off") or have to be postponed because the device is busy. > I'm not a fan of this dropbox methodology that he is advocating. I agree that there is a problem if the printer or the printer is turned off we need to be able to provide the user with information in a timely manner but I still think that it needs to be provided by the drivers. > > ... > > A GUI application will need to query the printer driver for its > > strings as well as hints as to how to display the information. > > Again, a *static* file makes this a lot easier. I'm not 100% > happy that the PPD spec only allows a single language right now, > but others have suggested a common translation catalog that covers > common options... > > > ... > > While inkjets may not need acceleration, there are other printers > > that do. It is much more efficient to transfer a high level call like > > drawing a rounded box than it is to transfer a bitmap image of that > > box. Some examples of high level languages are: HP-GL/2, PCL6, and > > even Postscript. Should there be two different code paths for > > printing to an inkjet printer vs printing to a Postscript printer? > > HP-GL/2 is a waste of time. There are too many special cases and > too many differences in appearance between models (even within HP > models). > > PCL 6 is an option, but can be handled by existing software like > Ghostscript without requiring the application to know about it. > > PostScript, with all its weaknesses, is still the defacto standard > printing format for UNIX apps. Any printing solution will have to > support it to be accepted, which is why CUPS includes a version > of GNU Ghostscript for non-PS printers, and why we use PPDs. > What ever happend PDF 1.4. > > ... > > One example of reducing data that is sent to the printer driver is to > > use device fonts that are resident in the printer. To achieve > > WYSIWYG printing, > > an application will have to query the printer driver for its font > > metrics. > > The printer driver is not the right place for this; the printing > system needs to manage fonts, and provide an API for drivers to > register/retrieve them. Once again I think Michael and I differ here. I think that fonts should be part of the comabilities subsystem but I wasn't pushing that yet. -ben > > > ... > > something that the operating system should store and tell the > > application and printer driver. > > The application should no nothing about what driver is being used, > just what capabilities the printer has... > > -- > ______________________________________________________________________ > Michael Sweet, Easy Software Products mi...@ea... > Printing Software for UNIX http://www.easysw.com > > _______________________________________________ > printing-cap mailing list > pri...@fr... > http://freestandards.org/mailman/listinfo/printing-cap |
From: Michael S. <mi...@ea...> - 2002-01-08 13:56:56
|
On Monday 07 January 2002 06:44 pm, Ben Woodard wrote: > > 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. > > Also, trying to get printer drivers and applications to talk to > > each other directly is a mistake. It doesn't scale. Better to > > I personally think this is completely wrong. I don't see how it > doesn't scale at all. Ben, I've been doing this stuff for a *long* time. Sketch a quick design for an API that allows multiple applications (possibly from remote systems) to communicate with a driver directly, which then talks directly to the printing device. The bottleneck quickly becomes the printer and driver, which must multiplex status inquiries from multiple sources, and also somehow keep printing. The only way to support such a scenario is to keep an internal snapshot of the printer state and feed that to the "clients" when they ask for it. Guess what, you have a *static* representation of the printer, but rather than storing that representation someplace that can be quickly forwarded to the client, you are re-processing everything. On many printers this can mean handling a *lot* of information (hundreds of media sizes and types, not including resolution, quality, color, etc. modes) for no real benefit. If you do create a static snapshot that is quickly sent to the client, then you have *exactly* the mechanism provided by CUPS... > > have the driver maintain a snapshot of the current configuration > > than to introduce potentially long round-trip times which may > > require UI intervention ("your printer is not connected or turned > > off") or have to be postponed because the device is busy. > > I'm not a fan of this dropbox methodology that he is advocating. I > agree that there is a problem if the printer or the printer is turned > off we need to be able to provide the user with information in a > timely manner but I still think that it needs to be provided by the > drivers. 1. Printer configurations change infrequently. 2. Most conflicts between options can be stored statically; that is, duplex printing is *always* incompatible with transparency media, unless someone comes up with one-way ink :) Those that depend on a hardware feature (which type of ink cartridge is installed) can still be expressed statically, but depend on some dynamic info that the driver needs to update as needed. 3. You *must* design for the 100 (or more) people trying to monitor/print to a printer. See previous description of the problem. 4. There is a big difference between printer capababilities (that are provided to the user as a list of options) and printer state. If tray 4 is empty, does that mean that a user can't print to tray 4? Probably not. Printer caps and state should be treated separately. > ... > > PostScript, with all its weaknesses, is still the defacto standard > > printing format for UNIX apps. Any printing solution will have to > > support it to be accepted, which is why CUPS includes a version > > of GNU Ghostscript for non-PS printers, and why we use PPDs. > > What ever happend PDF 1.4. There are still a lot of problems with PDF in real-world printing. It works great if you want a document printed all on the same media, with the same options, but it still doesn't support the full range of printer options that PostScript does. Basically, all you get (if you have a compatible app, and Acrobat Reader doesn't even do this) are a series of job ticket attributes that can be applied globally or to individual pages, and unfortunately these attributes don't support anything as simple as media type, etc. See Adobe technote 5620, Portable Job Ticket Format. > ... > > The printer driver is not the right place for this; the printing > > system needs to manage fonts, and provide an API for drivers to > > register/retrieve them. > > Once again I think Michael and I differ here. I think that fonts > should be part of the comabilities subsystem but I wasn't pushing > that yet. Both Microsoft and Apple put the font handling in the API, not in the driver. Drivers are free to support some fonts directly, however all an app sees is a common set of fonts that are available. If a printer vendor provides a set of its own fonts, it must also include display fonts so they are available to the system as a whole. Then it simply becomes a matter for the app to choose a font it wishes to use; if the printer doesn't have that font, the driver can either download the font (PCL/PS drivers do this in the Windows world) or rasterize it at the printer's resolution. Not surprisingly, this is the functionality that GNOME provides, and KDE to a much lesser extent. CUPS 1.2 will understand all of the "required resource" stuff included with a PS file; when a file uses a font called "Foo-Roman", the CUPS filter can look in the PPD file to determine if the printer has that font, and if not embed the font automatically. CUPS already does this when printing text files... -- ______________________________________________________________________ Michael Sweet, Easy Software Products mi...@ea... Printing Software for UNIX http://www.easysw.com |
From: Robert L K. <rl...@al...> - 2002-01-09 01:26:23
|
From: Ben Woodard <be...@zo...> Date: Mon, 07 Jan 2002 15:44:42 -0800 > PostScript, with all its weaknesses, is still the defacto standard > printing format for UNIX apps. Any printing solution will have to > support it to be accepted, which is why CUPS includes a version > of GNU Ghostscript for non-PS printers, and why we use PPDs. What ever happend PDF 1.4. How many applications generate PDF 1.4? How many applications generate PostScript? -- 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 |
From: Raph L. <ra...@ca...> - 2001-12-28 01:33:13
|
On Wed, Dec 26, 2001 at 03:16:52PM -0600, Mark Hamzy wrote: > First, I would like to point out that I am not an IBM spokesperson. Don't > take my views as "IBM says you should do this." I am just someone who has > worked with printer drivers on multiple operating systems for ten years. Understood. > Second, this group came together to work on standards for Linux in the area > of printing. No one person should control it and everyone should come > together in agreement for what direction Linux should take. At this stage, > proposals should be announced. It shouldn't be one or another. We should > look at existing solutions and if they do not provide what we need, then we > should take the best ideas from everyone and create something new. I basically agree here. However, if creating something new means incompatibility with IJS, or reinventing most of IPP, I'm not sure that's a good thing. > IPP has looked at and standardized on many things that relate to printing. > However, they look at it from the view point of the physical printer > instead > of from the software printer driver. I need to reread all the IPP > documentation. However, if each printer driver is an IPP server, can it > handle that? Also, it defines the contents of the job as a block of binary > data. There are many steps in going from high level calls to the printer > control language that a printer driver and operating system need. Yes. I think IPP was designed to handle a number of scenarios, including physical devices implementing IPP and also print servers of various flavors. Certainly, the protocol emphasizes very different things than the IJS work. There is no doubt nontrivial work remaining to "profile" IPP to be most useful in Linux frameworks. The experience of the CUPS project will no doubt be extremely useful towards this goal. > I think that there are many different areas that make up a printer driver. > It is not just a filter to translate raster bitmap data into printer > control > language. For example, there is another subgroup that is talking about > printer capabilities. That should be included in what makes up a printer > driver. Also, drivers need to have translatable resources such as form > names that can be used to build a graphical representation of itself. > Should there be many different pieces of software to install or protocols > to > speak to be able to handle each of these? Bingo! This is the _real_ question. What is a printer driver? Presumably, in this context, most printer drivers will be shipped as RPM packages for some subset of Linux distributions. What should be in this package? I think we have very strong consensus that _one_ of the components should be an executable that does the raster to escape code translation, speaking some kind of IPC protocol with the module that actually provides the raster data. I think the questions about how to package the _other_ components of the printer driver are much more challenging. Perhaps we should try to pile as much of it into the IPC protocol as possible. I personally don't think this is the best solution. I believe there are some needed features that can't be implemented entirely within the IPC protocol (such as discovering the most appropriate driver for the printer), and others that would be better implemented using a combination of static data with IPC protocol assist for the parts that need to dynamic (capabilities and UI pieces). > All of the things that are considered as "the Omni group" put into PDC > should not be viewed as proprietary extensions. These are some of the > things > that I think are necessary as paradigms of common printer driver > information and setup. I have tried to design this to be as easy as > possible for other printer drivers to implement. There should be as much > information and routines as possible to be common for the best user > experience. > > Now that that was said, let me move on to the differences between PDC and > IJS. Thanks very much for this. I think it's extremely helpful for resolving the remaining technical issues. > Printer Capabilities > -------------------- > > The capabilities subgroup needs to query the printer driver at runtime and > not though a static file (like a PPD). Also, I believe that applications > will want to be able to select between different print paths based on > the printer's capabilities. I agree that dynamic printer capability reporting is important. That's why IJS contains support for enumerating and querying parameters. Some capabilities, such as duplexing and color support, are defined in the base IJS spec. Others will need to be defined as extensions. The latest rev of the spec also imports the PPD namespace for finishing options (the Finishing: prefix), and also reserves space for other PPD parameters. > Translatable Resources > ---------------------- > > A GUI application will need to query the printer driver for its strings as > well as hints as to how to display the information. I agree. However, I rather strongly believe that the rasterizer <-> driver IPC connection is the wrong place for it. For one, as far as I can determine, all of this information can be provided statically. Even in the case of dynamic capabilities, the strings and icons to represent these capabilities can be static. Second, GUI _applications_ should not be talking directly to the printer driver through an IPC channel. It is clear that another layer is needed. I don't see the value in having the rasterizer simply pass this information through. Third, not having the UI bits in the driver IPC protocol makes life easier for people packaging up printer drivers. In particular, it's possible to add strings, icons, etc., without having to mess with the driver executable itself. Lastly, coming up with a good standard for UI bits usable for all of the Linux desktop platforms is a formidable challenge. Perhaps it's one the Printing Working Group is willing to take on. It's not one I'm willing to take on with IJS. > High Level Device Acceleration > ------------------------------ > > While inkjets may not need acceleration, there are other printers that do. > It is much more efficient to transfer a high level call like drawing a > rounded box than it is to transfer a bitmap image of that box. Some > examples of high level languages are: HP-GL/2, PCL6, and even Postscript. > Should there be two different code paths for printing to an inkjet printer > vs printing to a Postscript printer? This is a good question, and I think the answer is "yes". That said, the current IJS proposal is in no way limited to raster data. I added the PageImageFormat parameter explicitly to allow compressed and higher level formats. Characterizing the command set of a printer is hard. PCL printers have notoriously wide variation in the exact PCL dialect implemented. I don't think the major/minor/micro version number is adequate. > Device Fonts > ------------ > > One example of reducing data that is sent to the printer driver is to use > device fonts that are resident in the printer. To achieve WYSIWYG > printing, > an application will have to query the printer driver for its font metrics. I believe that _accurately_ characterizing the fonts available on the printer to the client is a big giant can of worms. To get this right, you have to deal with font metrics, glyph complement, and encoding. That said, there's no reason why the IJS wire protocol can't accommodate this kind of information. > Constraints > ----------- > > In order to prevent printing duplex on transparencies, the application > should be told by the printer driver that this will cause a problem. A > printer driver writer will know what are the constraints that the device > places on the coder but there is no way to let an application know. IJS actually provides a way to address this: the server can make the Duplex enumeration report no duplexing when transparencies are selected. > Job id vs New Instance of Communications > ---------------------------------------- > > I believe that making the client allocate and keep track of job ids causes > extra complexity without any benefit. It is easier to start another > communications session to the printer driver. This way, the printer driver > does not have to keep track that id X is in page Y and band Z while id X' > has just started. Also, I don't see how the output from multiple > simultaneous jobs are kept separate. Hmm. This means that the printer driver must support listening for multiple connections. In addition, you have to standardize how clients can discover the various printer drivers with open ports, as well as nailing down how the driver does access control. Incidentally, I'm now thinking that "master" and "slave" are more appropriate names for the IJS roles than "client" and "server". This terminology is far more intuitive for describing a process which is both an IJS master and a server for some other protocol, for example IPP. Output can be kept separate by specifying finishing options. > Form Size vs Form Name > ---------------------- > > The form should be selected by the media name. First, there is a non-exact > conversion between inches and millimeters. Second, it is easier to > remember > the form name rather than the form size. For example, a non-US user wants > to print out on A3 paper. Is it easier to specify 11.69x16.53 or iso_A3? > While a table may help, if a new form comes out, then it will be unknown to > the application. Possibly. I'm not convinced. In any case, the IJS wire protocol can easily handle form names as an extension parameter. > Device Name > ----------- > > Printer drivers that handle many different categories of devices need to be > told unequivocally what the model name and device name is. It should not > have to do a bidirectional call to query the printer name (one reason why > would be printing to a file). I believe that this is something that the > operating system should store and tell the application and printer driver. This is an architectural question having to do with the way the driver is used. There's nothing about IJS that forces clients to query the device name. > All of the Job Properties > ------------------------- > > I think that the protocol should send every job property to the printer > driver. It should also, in the best case, set all of the job properties at > once. PDC tries to define a set of common job properties that are the same > between all drivers. It is difficult for the user to know that there is a > set of Ghostscript job properties (-sPAPERSIZE=a4, -r300) and a set of IJS > job properties (-dIjsDepth=24, -sIjsParam="..."). I'm afraid I simply don't understand this issue. > Printer Properties > ------------------ > > Printer properties are necessary to know things like 4Mb of memory is > installed and yellow paper is in tray 2. The printer driver will send > different commands to the printer based on what printer properties are set. I agree that such a thing is desirable. In the PostScript world, PPD files generally provide this functionality. To the extent that it should be implemented in the IPC protocol, I can see it implemented as sub-namespace of IJS parameters. This kind of thing seems potentially quite tricky to me: how does the print driver _know_ that tray 2 contains yellow paper? I am unaware of any printers that have colorimeters in their paper trays. I think it's possible to come to some closure here. The goal of IJS is basically to solve the easy problems needed to make inkjet printers work reasonably well in current Linux/Unix systems. It avoids the harder problems of parameterized UI bits, non-raster PDL and font characterization, driver selection for autosensed device ID's, and so on. These are important issues, and I truly wish the PWG<2> success in dealing with them. I believe that IJS is a useful starting point, and that it would be beneficial for users and driver developers alike to be able to implement a simple driver based on IJS at first, and add in PWG<2> enhancements as needed, and as they become standardized. I am open to suggestions on how to make IJS a suitable basis for this future work, particularly in terms of providing a robust extension mechanism. I personally do not have the time or energy to participate fully in a standards process for these rather tricky issues. Thus, in terms of process, I see myself pushing IJS to a 1.0 version in a relatively short timespan, then handing it over to another group (perhaps the PWG<2>) for future extensions. On the other hand, I'm not going to try to stop the PWG<2> from adopting an incompatible wire protocol if that's what they truly want to do. Raph |
From: Michael S. <mi...@ea...> - 2001-12-28 15:04:53
|
On Thursday 27 December 2001 08:31 pm, Raph Levien wrote: > ... > This kind of thing seems potentially quite tricky to me: how does > the print driver _know_ that tray 2 contains yellow paper? I am > unaware of any printers that have colorimeters in their paper trays. > ... Most laser printers that support the PostScript MediaColor attribute have a way to set the media color, type, and size for each tray from the control panel. Most current laser printers can detect media size automatically, so the type and color are the other attributes you have to setup manually on the printer. -- ______________________________________________________________________ Michael Sweet, Easy Software Products mi...@ea... Printing Software for UNIX http://www.easysw.com |
From: Michael S. <mi...@ea...> - 2001-12-28 14:58:44
|
On Thursday 27 December 2001 07:12 pm, Robert L Krawitz wrote: > ... > I'm generally in favor of a dynamic view of what the driver can do, > because the constraints might be very complex, but this is an > interesting thought. However, why do we need an actual file in the > filesystem (as opposed to some virtualized way of getting a handle to > a PPD file)? Do applications rely on open()/fopen() of PPD files, or > is there some more abstract way of getting this information? Well, the printing system layer could generate the file for the client, however I'm pretty sure all existing clients need to ultimately read the PPD file from an actual file, although the KDEprint stuff might be just loading from the HTTP data, I dunno... That said, there are enough existing apps that read PPDs directly from files (e.g. StarOffice) that we'll need to support a static snapshot file of some sort. *How* that file is generated is a design decision, however I know of two developers that are using a background device daemon that monitors the print devices and update the local PPD files for the current configuration. I suspect that this will remain the most flexible (i.e. least printing-system centric) design... > ... > Extensions like this don't scale very well either; everybody will > define their own extensions (look at what Cups-o-matic does; it uses > structured comments in the PPD file to encode a perl data > structure!). Well, for CUPS-based drivers at least it will work, and other apps will "see" the standard PPD file that will still work everywhere. As for CUPS-o-matic, the perl data will almost certainly stay as it is, but I'm pretty sure that the options can be updated to use the new CUPS naming without a lot of trouble... > ... > I don't think we should think in terms of a single-threaded > server-based driver, but having some way of querying the driver (even > if it's a different process) would be useful. I'm not convinced that > we need to address this in the first go-round, but ultimately we > will. The problem is that in most cases you can't query the printer while printing, and there are some major security issues with an app talking directly to a device. Better to define a common set of attributes (there are a lot of them defined by IPP already) that the driver can report to the printing system, which can be provided to a client on request. If you are monitoring the device when not printing, the scheduler status data can be updated on-the-fly... -- ______________________________________________________________________ Michael Sweet, Easy Software Products mi...@ea... Printing Software for UNIX http://www.easysw.com |
From: Robert L K. <rl...@al...> - 2001-12-28 16:12:56
|
From: Michael Sweet <mi...@ea...> Date: Fri, 28 Dec 2001 09:59:29 -0500 On Thursday 27 December 2001 07:12 pm, Robert L Krawitz wrote: > ... > I'm generally in favor of a dynamic view of what the driver can do, > because the constraints might be very complex, but this is an > interesting thought. However, why do we need an actual file in the > filesystem (as opposed to some virtualized way of getting a handle to > a PPD file)? Do applications rely on open()/fopen() of PPD files, or > is there some more abstract way of getting this information? Well, the printing system layer could generate the file for the client, however I'm pretty sure all existing clients need to ultimately read the PPD file from an actual file, although the KDEprint stuff might be just loading from the HTTP data, I dunno... It's a pity that UNIX domain sockets don't quite have plain-file semantics about open/read and the like; that would be a great way to emulate static files with dynamic semantics. That said, there are enough existing apps that read PPDs directly from files (e.g. StarOffice) that we'll need to support a static snapshot file of some sort. *How* that file is generated is a design decision, however I know of two developers that are using a background device daemon that monitors the print devices and update the local PPD files for the current configuration. I suspect that this will remain the most flexible (i.e. least printing-system centric) design... That would probably work, although applications would need to reread the PPD whenever they wanted to start a new print job. For that matter, so would CUPS. > Extensions like this don't scale very well either; everybody will > define their own extensions (look at what Cups-o-matic does; it uses > structured comments in the PPD file to encode a perl data > structure!). Well, for CUPS-based drivers at least it will work, and other apps will "see" the standard PPD file that will still work everywhere. I'm nervous about what this leads to. If CUPS has one set of extensions, another IPP-based system has another, and so forth, we get into trouble fast. > I don't think we should think in terms of a single-threaded > server-based driver, but having some way of querying the driver (even > if it's a different process) would be useful. I'm not convinced that > we need to address this in the first go-round, but ultimately we > will. The problem is that in most cases you can't query the printer while printing, and there are some major security issues with an app talking directly to a device. Better to define a common set of attributes (there are a lot of them defined by IPP already) that the driver can report to the printing system, which can be provided to a client on request. If you are monitoring the device when not printing, the scheduler status data can be updated on-the-fly... I certainly don't want applications talking directly to the printer. In my view, the driver handles all of this. Of course, "driver" means more than just the blitter (to use the OMNI terminology); it may well mean a few cooperating programs (the blitter, the option enumerator, and so forth). How those (hypothetical) programs (driver components) interact with each other is beyond the scope of what we're trying to do here. ================================================================ Of course, there's the whole issue of what we're really trying to accomplish; I think we're going around in circles. I'd rather understand specifically what IPP in general and CUPS specifically don't do that we need, and understand whether the problems are reasonably fixable, before going off to design yet another piece of middleware. While I like a dynamic view of the driver myself, it's unclear to me that this is the most important problem to solve. We can emulate dynamic semantics with PPD files, as you note; if applications will only read a PPD file once, it doesn't help. I don't think the weakest part of the UNIX printing system is at the blitter stage; we as a group (both the people on these lists and the free source community in general) are good at this kind of thing. The problem that all this points to, as I see it, is that the interface between applications and the printing system is weak. The traditional interface is a one-way pipe from application to printing command (lpr or lp). Postscript is a nice bolt-on that fits very well within this, as long as you don't try to do anything fancy (like understand what the printer can actually do beyond what /etc/printcrap is able to express). The problem is that modern printers (or drivers; it's completely irrelevant whether the printer can actually do something or the driver emulates it) are much more capable than the guys at Berkeley designed for back in the late 1970's, and applications are a lot more sophisticated. KDE and GNOME are at least asking some of the right questions, even if some of the answers might be a bit strange. The issue I noted about applications possibly not rereading PPD files really has little to do with the use of PPD files vs. any other mechanism. Using PPD files as an IL is probably fine. The problem is that each application takes its own view of the world, and takes a completely noninteractive view of printing (Netscape actually bothers to give you a popup with the output of the lpr command, which is better than a lot of things). It is my belief that we cannot fix things as long as this is the prevailing approach; we need to standardize something more powerful at this layer before it even makes sense to talk about the driver interface. -- 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 |
From: Michael S. <mi...@ea...> - 2001-12-28 17:22:00
|
On Friday 28 December 2001 11:01 am, Robert L Krawitz wrote: > ... > That would probably work, although applications would need to reread > the PPD whenever they wanted to start a new print job. I think this would be the case, even for a dynamic data interface. > For that > matter, so would CUPS. Yes, but the device daemons that are being used do this by telling CUPS to use the new PPD file (i.e. CUPS only re-reads the file as needed) > ... > Well, for CUPS-based drivers at least it will work, and other apps > will "see" the standard PPD file that will still work everywhere. > > I'm nervous about what this leads to. If CUPS has one set of > extensions, another IPP-based system has another, and so forth, we > get into trouble fast. Not to "toot our own horn" too much, but right now CUPS is the only IPP implementation that actually deals with printer drivers, options, etc. at this level. MS IPP and Novell IPP both still deal just with sending raw print data... :( Also, CUPS is already extending IPP by providing PPD files, drivers, etc. on top of IPP (documented and registered, of course, with the PWG), and anything we do to support printer drivers on top of IPP will be an extension... -- ______________________________________________________________________ Michael Sweet, Easy Software Products mi...@ea... Printing Software for UNIX http://www.easysw.com |