RE: HP 10ps buying info
RE: HP 10ps buying info
- Subject: RE: HP 10ps buying info
- From: Henrik Holmegaard <email@hidden>
- Date: Wed, 28 May 2003 11:38:06 +0200
Graeme Gill <email@hidden> wrote:
>The limitations it has are unnecessary. Provide
>the sensor readings as absolute, and it's dead easy to subtract
>out the paper value. Subtract it out in the printer, and
>the information is lost.
>The chart recognition seems so fussy that it won't
>work unless the printer response is within very tight bounds.
>adding this feature (and a great idea it is), but haven't gone
>the last 10% needed to make it useful to external RIPs.
First, I like the idea that every device should have associated with it
a calibration capability.
Second, I like the idea that the calibration capability should be built
into the device itself.
Hence the support for the Monitor Calibration Framework introduced in
ColorSync 2.5. Similarly with the embedding of a calibration sensor,
not only in the 10ps but in all DesignJet printers. The idea here is to
ensure that manufacturer and similar third party papers work on the
device, and that two devices work the same.
Practically, the sensor technology has been evolving since before the
introduction of six ink models. The sensor in the 10/20/50 is not the
same as the sensor embedded in earlier models, but one that is
calibrated to other specifications.
I believe the specification sheet at one time or another said that
print-to-print and device-to-device tolerances using this sensor were
less than two deltaE with manufacturer media. Whether you want to use
manufacturer media is another matter, of course.
Technically, the sensor is neither a spectrophotometer, nor a
colorimeter, nor a full-blown densitometer. The sensor solution and
printer intelligence are designed to facilitate some idea of the state
of a remote device when two devices are intended to print the same on
the same media, though to be honest I don't know whether this is
implemented in any software.
Why raise this at all? Simple, since Acrobat InProduction and DRUPA
2000 it has been clear that printer technology, printer software and
what has been called dumbed down PDF are going to have to fuse into
serviceable solutions for remote proofing. There are going to be lots
of solutions on a broad continuum, but the hostility shown to the very
idea of remote proofing has to go away, because we are going to need it
as applications with native PDF libraries and standards-based export
presets replace Distiller which from my point of view is a crutch for
those applications which are only able to generate PostScript (: with
device dependent parameters, one application in particular coming to
mind).
Henrik
_______________________________________________
colorsync-users mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/colorsync-users
Do not post admin requests to the list. They will be ignored.