Menu
▾
▴
[Omniprint-user] Re: Taking a step back
|
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/ |
