|
From: Daniel J S. <dan...@ie...> - 2005-08-18 17:25:50
|
Ethan Merritt wrote: > On Thursday 18 August 2005 09:04 am, Daniel J Sebald wrote: > >>I think it can't, but let's continue to hash this out... >>Image data sent to a plotting device, like a PostScript interpretter, >>is a rectangular matrix--essentially a uniform sampling of intensity >>(light, field strength, temperature, etc.). >>There is no way to include in that data individual information about >>a pixel, say, pixel 25 should be only 0.67 the size of the uniform >>sampling interval. > > > Bad example. PostScript support for explicit clipping is very straightforward. > You set the clipping boundary first, and then draw your big "pixels" without > any special processing. PostScript itself will clip them to fit within the > requested clipping boundary. > > The real problem comes from the drivers with external libraries that are > too stupid to clip -- libpdf being the prime offender. That is my point. PostScript is very capable of dealing with this, just as you describe. It effectively draws a portion of a pixel. And as you point out with libpdf, there appears to be no universal solution to this. I'm arguing that we should not limit the PostScript or X11 drivers because other less-intelligent drivers have no good solution. If libpdf is incapable, then it should be at the driver level that a decision is made to toss out some pixels that partially extend outside the viewable range, i.e., further refinement by possible shrinking the image by one pixel per edge. You agree that PostScript should be allowed to have negative numbers for an image location then? (Or does PostScript always have a greater than zero offset for the origin of the plot area?) Dan |