Convert large raster graphics image(bitmap, PNG, JPEG, etc) to non-vector postscript

How to convert an large image and embed it into postscript?

I used to convert the bitmap into HEX codes and render with colorimage. It works for small icons but I hit a /limitcheck error in ghostscript when I try to embed little larger images. It seem there is a memory limit for bitmap in ghostscript.

I am looking a solution which can run without 3rd party/pre-processing other then 开发者_Python百科ghostscript itself.

Convert from ImageMagick reads the encoded image data line by line it seems. Try it on an example image and read the PS output.

The freeware vector graphics program InkScape will convert your bitmap into easily understandable code embedded with the converted graphic.

We recently had a problem where we were sending postscript code from our mainframe to a printer. We tried converting it with ImageMagik and got the result to work in GhostScript but the mainframe language we use had mainframe to printer transmission problems with the code. The InkScape conversion was much simpler, much more basic and we were able to easily identify and remove the extemporaneous code. What had been a 2 month struggle with the graphic from the ImageMagik converter was resolved in 3 hours with the new InkScape graphic.

I think that you will be happy with the results from InkScape, regardless of whether you want to convert an image or have an example of some simple working Postscript graphics. Also, if you are building a converter, InkScape is open source!

There's no memory limit in Postscript for images per se; but most Postscript interpreters use a 16-bit field for the size of a composite object, thus all strings and arrays (and probably dicts too) are limited to 65536 entries.

For thus reason, a common trick (which Adobe themselves showed us in the Blue Book) is for the image (or colorimage) data-acquisition procedure to read-ahead from the source file and spoon-feed the data in smaller strings. But you can use 65536 string (maybe a little lower, to be "safe") to shovel more data per call.

The Green Book is the best Adobe source for the things to think about when designing your PS program for speed or size (rather than just "making it work right"). If you've got more processing power and narrower bandwidth maybe you should compress everything and decompress in data-acquisition procedure.