Sorry about the de-threading, but my posting host doesn't
have the current replies, and my reading host is broken
for posting.
Let me clarify to say that whether the PS is ROM, PROM,
or downloadable EPROM doesn't matter to me, as long as
the RIP is being done inside the printer, and has direct
access to the marking engine.
And further, I'm only discussing PS as a second PDL.
Printers that are strictly host-RIP PS only, are not the
topic here.
It absolutely does if you are running on a host OS not
supported by the software RIP. In the case of my present
inkjet printer, for example, the "ps" version of it does
not include RIP code for Linux.
Even if we presently have a supporting host OS, what are
the odds that the printer maker will continue to supply
updates for new OS'es coming along? How many existing
Win32 host RIPs will get Win64 releases when XP64 arrives?
(How many ever got Win64 for IA-64?)
Printers tend to last far longer than major OS releases. My
laser printer is over 10 years old, and still going strong,
even though now probably off the maker's support life.
The maker's driver updates ended some 8 years ago, but I
can still print to it using either the native PDL or PS.
The job gets to the interpreter; the interpreter rasterizes
the job and sends the raster data to the marking engine.
With host RIP, the question becomes: How?
The data has to go from the RIP host to the printer via the
normal I/O connection, and in some data format.
What is that data format?
Chances are, the RIP is translating the PS to the native PDL
or some subset of it.
If the translation is to high-level native PDL, you have
PDL dependencies. If, for example, the native PDL has a
defect, printing in PS mode may or may not work around it.
If the translation is to the PDL's raster object syntax,
you could suffer from sloggy I/O performance, because the
data objects will be huge, and/or experience some loss of
some finesse in the engine (like font smoothing).
Now, the native PDL may have some extensions that provide a
more primitive access to the engine. Or the printer may have
some alternative mini-PDL that similarly provides low-level
access to the marking engine. If so, the vendor needs to tell us.
If the host RIP is sending high-level PDL to the printer, the
workflow may be little different than Distilling the PS to PDF
on the host, and printing that.
If the RIP is sending nearly pure raster to the printer, that
may be little different than the "print as graphics" option some
drivers have. Huge data objects, and on my inkjet, unimpressive
page quality. I wouldn't expect a host RIP to be so marginal,
but unless the maker tells us how it works, I'm nervous.
And if the printer maker won't explain the details of what
is crossing the I/O port, I assume that the RIP is merely a
PS to PDL translator. If, for example, I already own
the full Acrobat product, what's the point?
You apparently had some problems with a RIP that sat
under different covers than the marking engine, and
now you've decided that it's the arrangement of RIP
and marking engine that was to blame.
Nope. I've just always had a policy of avoiding host RIP.
The main reason I want PS in a printer is to have a second
host-independent printer-resident PDL, that will have a
useful life equal to that of the print engine,
and host RIP just doesn't deliver that.
