[Desktop_printing] Deprecate IJS? GhostScript with only "opvp"
as output device?
till.kamppeter at gmx.net
Mon May 15 16:28:37 PDT 2006
I also did not want to simply take it away, but simply hear opinions. We
must at first observe how well the new opvp is going and perhaps see in
real live were it needs to be improved. One thing which opvp most
probably does not have yet is KRGB, which is important for economic
handling of black and colored ink or toner.
Vector drivers are most interesting for laser printers who do not do
PostScript but do another high-level language (PCL for example, but also
the ESC/Page of the Epson EPL non-"L" and AcuLaser printers).
For inkjet printers and fax machines raster drivers based on IJS or CUPS
raster are just fime. Raster devices are probably not accelerated by
using opvp. Here the only benefit is reducing the number of different
So for now it is perhaps best to keep the three interfaces and observe
there developemt and drop only GhostScript built-in. Perhaps it should
also be avoided to make a raster driver CUPS-raster-only but better let
it have both the CUPS raster and opvp or IJS interface as BSD and
Solaris do not use CUPS as default spooler.
Oleinik, John H wrote:
> At the Printing Summit we agreed on 3 standard interfaces: IJS, opvp, and
> CUPS Raster. It seems premature to talk about deprecating IJS.
> We are looking at how our customer needs might be met by CUPS Raster and
> opvp, but currently our customers are well-served by IJS. HPLIP, which of
> course uses IJS, now supports over 1,000 HP Printer models. IJS is a
> well-tested interface, it is not currently under development because it
> works very well. Who benefits from deprecating IJS?
> We are also trying to understand how opvp benefits our customers, but this
> is not yet clear to us. Who benefits from the adoption of opvp? We have
> only heard anecdotal information about performance improvements for a
> small set of very old printers. We have not heard this from our Linux
> Printing Support forums, but from supporters of the opvp standard.
> Michael Sweet raises an issue that is also very important to us at HP. We
> will be using our IJS-based software to enable printing on non-CUPS
> environments. There are a large number of Linux and Unix customers who
> value this flexibility and freedom to configure their printing
> environments. Again, I find it premature to set a standard to restrict
> this flexibility.
> John Oleinik
> HP Linux Printing Program Manager
> -----Original Message-----
> From: desktop_printing-bounces at lists.osdl.org
> [mailto:desktop_printing-bounces at lists.osdl.org] On Behalf Of Till
> Sent: Monday, May 15, 2006 2:04 PM
> To: Michael Sweet
> Cc: printing-architecture; desktop_printing at osdl.org
> Subject: Re: [Desktop_printing] Deprecate IJS? GhostScript with only
> "opvp"as output device?
> Importance: Low
> Michael Sweet wrote:
>>Both Gutenprint and HPLIP have CUPS native interfaces that are better
>>suited to pure-raster printing.
> I do not want to deprecate CUPS raster (CUPS raster is probably the second
> reason to deprecate IJS), it is probably the better choice in terms of
> color management and clean job canceling than OpenPrinting vector.
> When will HP's rastertohplip be published?
>>>And with the OpenPrinting vector interface one would even be able to
>>>modularize out all the GhostScript output devices and leave
>>>GhostScript with "opvp" as the only output device. So also the
>>>problem of the X11 output drivers in the GhostScript implementation
>>>of distributions and using GhostScript on X-less servers would get
>>We still need to ensure that the new interface is compatible on all of
>>the current operating systems; for us that means: AIX, HP-UX, IRIX,
>>Linux, MacOS X, Solaris, and *BSD.
> If an OS does not provide any possibility for dynamic linking like libdl
> under Linux, we must fall back to a separate process, where the driver
> library is statically linked to the server executable.
>>Also, the X11 problem is already solved by the dynamic module support,
> Yes, but this solution seems not to be overtaken by upstream (AFPL/GPL)
> Desktop_printing mailing list
> Desktop_printing at lists.osdl.org
More information about the Printing-summit