From: <dn...@le...> - 2000-11-08 21:56:37
|
On "The need for a printing system", I have a few suggestions: o Filter pipelines: Creating a pipeline to avoid re-spooling thru temporary files is a good idea for efficiency. Unfortunately, classic Unix pipelines are unidirectional. But some filters in a pipeline will need to directly query the device for capabilities or settings, such as the alignment values of each cartridge/head in an inkjet. There should also be a way for each filter to immediately notify the print subsystem that a problem has occurred. Or said another way, the print subsystem needs to be able to immediately detect a (possibly recoverable), detect which filter in the pipeline had a problem, and what that problem was. These problems do not preclude the concept of a non-spooling pipeline, but would tend to imply that the implementation will require more than just a classic Unix pipeline of processes connected together with pipe()s. o Plain text and other non-PostScript input such as PCL: The current design seems to imply that all original data will be PostScript. This is true for most desktop apps, but not so for classic business apps (which tend to generate plaintext). Given that many modern printers can use PJL commands to control printer attributes in a way that is independent of the datastream type, gnulpr should support non-PostScript datastreams. (Many businesses use this capability in Lexmark's Unix laser drivers.) The primary problem here is to find a datastream-independent replacement for PPDs; we've been watching the UPnP group to see if their XML-based printer schema would fit the bill. o Concurrent management of local-attach printers: Many printers provide a way to get synchronous or asynchronous printer status and to set default attributes, e.g. via PJL or NPA. There needs to be a way to multiplex management commands and print path data over a single connection (which implies only local-attach printers, since networked printers can do SNMP concurrently over a separate port/connection than the print path data). Hope this helps. Best regards, -david David Nessl Lexmark International, Inc. |
From: Ben W. <be...@va...> - 2000-11-09 00:50:15
|
> On "The need for a printing system", I have a few suggestions: > > o Filter pipelines: Creating a pipeline to avoid re-spooling thru > temporary files is a good idea for efficiency. Unfortunately, > classic Unix pipelines are unidirectional. But some filters in a > pipeline will need to directly query the device for capabilities or > settings, such as the alignment values of each cartridge/head in an > inkjet. Your point is very valid. I realized that early on. Actually in my prototype implementaion, I use unix domain sockets rather than pipes. However, this does create some problems for filters. They have to pass data both ways rather than just one. This is more than most filter scripts can do. I have some ideas how to work around this but I haven't settled on one idea yet. Do you have any ideas about how to work around this? I really think that for the first version bidirectional pipelines will only work in certain circumstances. Everything will be connected by sockets and so the infrastructure will be there but it will take time and experimentation to determine what is needed. Some areas which I think it will work will be: 1) direct to printer 2) last filter on the pipeline is talking directly to a printer over a bidirectional connection. > There should also be a way for each filter to immediately notify the > print subsystem that a problem has occurred. Or said another way, > the print subsystem needs to be able to immediately detect a > (possibly recoverable), detect which filter in the pipeline had a > problem, and what that problem was. These problems do not preclude > the concept of a non-spooling pipeline, but would tend to imply that > the implementation will require more than just a classic Unix > pipeline of processes connected together with pipe()s. I was thinking about out of band data on stderr for the filters. This would mean that I would need a small program for shell scripts which could take care of this for them but it shouldn't be a big problem. > o Plain text and other non-PostScript input such as PCL: The current > design seems to imply that all original data will be PostScript. > This is true for most desktop apps, but not so for classic business > apps (which tend to generate plaintext). Given that many modern > printers can use PJL commands to control printer attributes in a way > that is independent of the datastream type, gnulpr should support > non-PostScript datastreams. (Many businesses use this capability in > Lexmark's Unix laser drivers.) The primary problem here is to find > a datastream-independent replacement for PPDs; we've been watching > the UPnP group to see if their XML-based printer schema would fit > the bill. I wasn't assuming that the original input would always be PS. My thought was that in most cases the first filter would be a local dereference filter which handles printing by reference. The second filter could potentially be a internet dereference filter and the third filter would be a type identification filter. The fourth would be a type conversion filter. The type conversion filter would take the information it knows about the type of input from the previous filter and the information it knows about the printer from the spooling system and create create a small pipeline where the file is converted to a format that the printer understands. > o Concurrent management of local-attach printers: Many printers > provide a way to get synchronous or asynchronous printer status and > to set default attributes, e.g. via PJL or NPA. There needs to be a > way to multiplex management commands and print path data over a > single connection (which implies only local-attach printers, since > networked printers can do SNMP concurrently over a separate > port/connection than the print path data). Good point. I think that the way that I would handle this is I would make the last filter in the pipeline be somewhat intellegent. In addition to sending the print data through, it would provide a network socket where it could recieve status queries or printer commands. Another related project that we are working on is libprinterconf. Right now the only thing that it does is detect printers on over the network and on the parallel port. However, the plan is to add more features for querying and configuring network printers. I could invision using a connection to the last filter as a means to implement the same API for direct connected printers. > Hope this helps. Best regards, > -david > > David Nessl > Lexmark International, Inc. > > > _______________________________________________ > Lpr-discuss mailing list > Lpr...@li... > http://lists.sourceforge.net/mailman/listinfo/lpr-discuss |
From: Thomas H. <thu...@co...> - 2000-11-09 15:14:12
|
dn...@le... wrote: > The primary problem here is to > find a datastream-independent replacement for PPDs; we've been watching the UPnP > group to see if their XML-based printer schema would fit the bill. Is this the same thing as UPDF or is it a different XML-based schema? We have discussed adding UPDF functionality to libppd (obviously, a name change would be desirable at that point!). Currently, it looks as if UPDF is still not mature, but it appears to have a very good potential. -- Thomas Hubbell CompuMetric Labs, Inc. thu...@co... |