Home > Archive > PostScript > March 2005 > Why does ghostscript "image" operator use vector drawing rather than raster
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Why does ghostscript "image" operator use vector drawing rather than raster
|
|
| Jonathan Kamens 2005-03-15, 4:03 am |
| Greetings,
I'm using ghostscript 7.07 to render to a Dell 3000cn color printer
which supports PCLXL. I'm using ghostscript's pxlcolor driver
(gdevpx.c).
Ghostscript produces absolutely *huge* PCLXL files when I print images.
I found this surprising, since I figured that the images should be
rendered using PCLXL raster graphics and should get at least
rudimentary run-length encoding to shrink them down, so I dug around a
bit in the source code.
To my surprise, I found that, at least in the pxlcolor driver, type-1
images are rendered not as raster graphics but as vector graphics, with
individual commands sent to the printer for each contiguous section of
identically colored pixels on each row of the image being rendered.
I'm not familiar enough with the ghostscript code to be able to
determine easily whether this is true for type-1 images with all
drivers or just with the pxlcolor driver.
It does appear that type-3 images are rendered as raster graphics, but
I'm not sure how to test that because I don't think I have any
software which knows how to generate PostScript with type-3 images in
it.
Is there a good reason why images are rendered this way with this
driver, perhaps something about the PostScript language I'm missing (I
haven't done any PostScript coding in years, and even when I did, I
didn't really do anything with images), or is this something that could
be considered a bug in ghostscript?
Thanks for your time.
| |
| Ken Sharp 2005-03-15, 8:58 am |
| In article <d15kpc$vv$1@jik.kamens.brookline.ma.us>,
jik@kamens.brookline.ma.us says...
> It does appear that type-3 images are rendered as raster graphics, but
> I'm not sure how to test that because I don't think I have any
> software which knows how to generate PostScript with type-3 images in
> it.
>
> Is there a good reason why images are rendered this way with this
> driver, perhaps something about the PostScript language I'm missing (I
> haven't done any PostScript coding in years, and even when I did, I
> didn't really do anything with images), or is this something that could
> be considered a bug in ghostscript?
Its probably due to masked images and image masks. These types of images
have 'transparent' areas. Areas where the image doe not mark the page.
I'm not familiar enough with PCL to be sure but it seems likely that the
language does not support this.
Thus the only way to deal with this easily is to do the process you've
described.
Ken
| |
| Jonathan Kamens 2005-03-15, 3:59 pm |
| Ken Sharp <ken@spamcop.net> writes:
>Its probably due to masked images and image masks. These types of images
>have 'transparent' areas. Areas where the image doe not mark the page.
>I'm not familiar enough with PCL to be sure but it seems likely that the
>language does not support this.
I think you got it backwards. Type-1 images don't have image
masks. Type-3 images do. So if the interpreter needed to
render masked images the inefficient way (i.e., with rectanble
fill commands rather than raster graphics), it would be the
type-3 images that were rendered that way and not the type-1
images, when the reverse appears to be the case.
Or, at least, that's how it seems to me. Perhaps I
misunderstood your point?
| |
| Ken Sharp 2005-03-15, 3:59 pm |
| In article <d16pm2$meg$1@jik.kamens.brookline.ma.us>,
jik@kamens.brookline.ma.us says...
> Ken Sharp <ken@spamcop.net> writes:
>
> I think you got it backwards. Type-1 images don't have image
> masks. Type-3 images do. So if the interpreter needed to
> render masked images the inefficient way (i.e., with rectanble
> fill commands rather than raster graphics), it would be the
> type-3 images that were rendered that way and not the type-1
> images, when the reverse appears to be the case.
>
> Or, at least, that's how it seems to me. Perhaps I
> misunderstood your point?
No, you are correct, I answered the question without reading the spec,
and assumed my memory was correct because it fitted the described
situation.
In fact I can't think of any reason for rendering type 1 opaque images
as a series of rectangles, unless the source was a transparent PDF file.
Ken
| |
| Ken Sharp 2005-03-19, 8:56 am |
| In article <423b60d3$0$23770$ed2e19e4@ptn-nntp-reader04.plus.net>,
r.daykin@pindar.com says...
> Ken Sharp wrote:
>
>
> driving a pen plotter?
Its a series of filled rectanlges, is that easier to render on a plotter
than an image ?
Note that according to the OP type 3 images, which one might expect to
be done like this, aren't....
| |
| Jonathan Kamens 2005-03-21, 3:59 pm |
| Rob Daykin <r.daykin@pindar.com> writes:
>Ken Sharp wrote:
>driving a pen plotter?
Even if you're right that this type of rendering would be easier on
pen plotters, it's foolish to optimize for that case, since the vast
majority of printers being driven by ghostscript are not pen plotters,
they're lasers, inkjets, bubblejets or dot-matrixes. As far as I
could tell from examining the code, rectangle fill commands are being
used to render type-1 images for *all* printers.
And I don't even think you're right, because I don't think the code is
smart enough to send all the rectangles of a single color together --
it just goes through the image sequentially row by row sending the
apporpriate rectangle fill commands for each row. So the pen plotter
would still have to switch pens for every rectangle. I imagine it
would take days, if not w s, for it to draw a simple photo :-).
|
|
|
|
|