Wednesday, May 23, 2012 9:32 PM
I have an .eps file that I insert with insert image.
I go to print to any postscript driver I have, and it resizes the image instead of showing the cropped image.
PCL drivers print correctly.
Friday, May 25, 2012 7:15 AM
Saturday, May 26, 2012 10:54 PM
I'm using PDF redirect, Cute PDF, as well as some HP Postscript printer drivers, and the same happens when creating a PDF through Adobe Acrobat X.
In 2003 it works fine.
Friday, August 17, 2012 5:22 PM
We are having a similar issue, if not the same at our firm. Here is a decription from one of our users:
"In any Office program, EPS files that are cropped using the crop tool will render improperly when printed to a Postscript printer. The crop setting s will be ignored, and the graphic will resize to fit inside the crop box, no matter how odd the shape. The problem is not evident when using a PCL driver, just a PostScript driver. The problem was not evident in 2003, so some groups like Consulting have many files with cropped EPSs in them which now do not print correctly."
This happens in Office 2010 on Win7. Is there a resolution?
Saturday, August 18, 2012 8:24 AM
The simple answer is that you cannot crop EPS data (at least not when printing them on a postscript printer). The EPS image data that gets sent to a postscript printer consists of postscript commands embedded in the original EPS file that know nothing of cropping that wasn't done beforehand - all you can do is scale them. Because PCL printers cannot process postscript commands, what gets sent to them is the preview image (which you can crop). Generally speaking, the reason for using EPS is to send high-quality output to a postscript device, with the image displayed in the document being only a relatively low-resolution version of what will be printed.
In the final analysis, there is no benefit in using EPS images if you're sending them to non-postscript printers or you want to alter them in any way in Word, etc.
[MS MVP - Word]
Monday, August 20, 2012 1:38 PMThanks for the info Macropod. While i certainly understand why this is the case, I want to go back to my users and state that this is what MS officially states. Can a MS Engineer officially validate the statement above by Macropod? Id rather not open a premier support call.
Monday, August 20, 2012 1:49 PMOn reflection, IIRC this behaviour first arose with Word 97 and was supposed to have been fixed way back then. I'm surprised it's been resurrected. In theory, all Word needs to do is to supply a mask for the cropped area, so to tell the postscript printer to erase it before outputting to the page. Not that difficult, really.
[MS MVP - Word]