I have a PDF file that was produced by Vectorworks V10 program (MAC). The issue that I have is when I place this PDF into RD using any version of Ghostscript (currently 8.00) raster images placed in Vectorworks when printed out thru RD it places a light grey screen behind the image. The PDF can print to our HP1050 without any problems from Adobe. I've never used this site before and don't classify myself as a programmer. If you need the actual PDF file I can forward at your request. Dale Carlin 604-714-3299 x107
We'll need the PDF file in order to try and reproduce your problem. Please attach it here.
Created attachment 39 [details] A7.3 - A - 2271 details 3 09_25a.pdf
I can't see any gray background in the pdf when viewed with Ghostscript. Can you reproduce this with just Ghostscript?
Created attachment 40 [details] Another Drawing Look at this PDF it is much more obvious. The process I'm using is a program called Reprodesk (or Apprentice) uses Ghostscript to rip the PDF into a TIF from within ReproDesk. How are you testing this? Should I try your method?
I have know idea what is happening??? has this been looked at and do we know what this issue is... me or the ghostscript?? Please get in contact with me if you can this issue needs to be solved or dealt with. Thanks Dale
This is an apparent duplicate of bug #650802. The fix for this problem is described in: http://www.ghostscript.com/pipermail/gs-cvs/2003-April/003131.html *** This bug has been marked as a duplicate of 650802 ***
A quick solution to this problem is to comment out the lines shown below. The file is lib/gs_init.ps and the comments start at line 1335 (in the current version of the file.) The commented out lines are those lines below which begin with a '%" (per cent) sign. /.sethiresscreen { % <dpi> .sethiresscreen .sethireshalftone % pushes true if a screen halftone used % Stack: doscree { % Set the transfer function to lighten up the grays. % We correct at the high end so that very light grays % don't disappear completely if they darken <1 screen pixel. % Parameter values closer to 1 are better for devices with % less dot spreading; lower values are better with more spreading. % The value 0.8 is a compromise that will probably please no one! % % Because of a bug in FrameMaker, we have to accept operands % outside the valid range of [0..1]. { dup dup 0.0 gt exch 1.0 lt and { 0.8 exp % dup 0.998 lt % 254.5 / 255 % { % Keep at least one halftone dot if not saturated color % .currentscreenlevels 1 sub dup 1 sub exch div % .min % } % if } if } } This file uses an index colr space with an ICC base space. THe ICC transforms are (at least as done by gs) converting 1, 1, 1 to slightly less than that. The transforms need to be checked!
Still investigating the ICC profile logic.
The transfer function logic has been changed. The accuracy of the ICC logic is bug 686750