[gs-devel] GS & ImageMagick - making CMYK work...

[Dan Coby]

Thomas,

>BTW: While searching the archives, I've heard about a potential bug,
>resulting in GS not being able to interpret EPS images generated by
>Photoshop. Funny enough, at the moment I'm also having no luck in
>interpreting sample images from Photoshop (no error message but also no
>output file generated). Is this a known limitation? I've found nothing
>regarding this in the docs.

This is actually one of our most common questions.  If it is not in
the documentation then it is probably because no one can figure out
where to put it.  Maybe we need to add a FAQ document.

EPS files do not contain a "showpage" operator.  This is what tells
Ghostscript that a page is finished.  This is when the page is
usually written to the output file.

Most of the viewers which are built around Ghostscript check for this
case.  (For example gsview.)

Try something like:
	gs filename.eps -c showpage

Dan


-----Original Message-----
From: Thomas Kaiser [mailto:Thomas.Kaiser at phg-online.de]
Sent: Friday, June 07, 2002 2:50 AM
To: Dan Coby; Leonard Rosenthol; gs-devel at ghostscript.com
Subject: Re: [gs-devel] GS & ImageMagick - making CMYK work...


Dan,

>> If I want to use GS to produce another file format (eg. bitcmyk or tiff),
how
>> can I get an output file with exactly 100 x 150 pixels and every pixel
>> identical to the ones in the source file?
>
> The short response:  Not easily.  Not with the current output devices.

That's what I expected :-\

> Basically this is not what Postscript and PDF are designed to do.

Yeah, I know. But there is one scenario where EPS in this limited
implementation (storing just one single image object) makes sense: It's the
lowest common denominator for images with clipping paths.

> Instead they are designed to take text, graphics, and images and place
them
> together on a page.  Since the images may have many different resolutions,
and
> the output devices may have its own different resolution, the process of
> converting an image's resolution is an inherent part of this process.

Ok -- understood.

> The device API for Ghostscript does have both low level and high level
> interface routines.  The low level routines, which are the ones used by
most
> output devices, deal in pixels and raster lines.  However the high level
> routines do interface at the text, font, image, and other high level
> component
> level.  You could create a "high level" device which works with the high
> level component types and puts out whatever you want.  The best example
> of a device like this is the pdfwrite device.

Ahh. Okay. A device that examines the one image object in such an EPS
(looking at color spaces, resolution, aspect ratio and so on) and creates an
output image based on this image object?

Such an examination would also be helpful for checking the contents of an
EPS file (differentiating between real 'high-level' EPS and plain 'one image
object only' EPS). At the moment, IMs 'identify' command just calls GS and
examines the pnmraw file (RGB, 72 dpi), GS spits out. Many metadata of the
original image will get lost during this conversion.

Unfortunatley my coding skills are absolutely limited :-(

BTW: While searching the archives, I've heard about a potential bug,
resulting in GS not being able to interpret EPS images generated by
Photoshop. Funny enough, at the moment I'm also having no luck in
interpreting sample images from Photoshop (no error message but also no
output file generated). Is this a known limitation? I've found nothing
regarding this in the docs.

Thanks for your advices,

Thomas