Bug 686752

Summary: Ghostscript for ReproDesk
Product: Ghostscript Reporter: Dale Carlin <dcarlin>
Component: PDF InterpreterAssignee: Dan Coby <dan.coby>
Status: NOTIFIED FIXED    
Severity: normal    
Priority: P2    
Version: 8.00   
Hardware: PC   
OS: Windows XP   
Customer: Word Size: ---
Attachments: A7.3 - A - 2271 details 3 09_25a.pdf
Another Drawing

Description Dale Carlin 2003-02-28 12:34:17 UTC 
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
Comment 1 Jack Moffitt 2003-03-06 08:12:21 UTC 
We'll need the PDF file in order to try and reproduce your problem.  Please
attach it here.
Comment 2 Jack Moffitt 2003-03-18 11:34:33 UTC 
Created attachment 39 [details]
A7.3 - A - 2271 details 3 09_25a.pdf
Comment 3 Jack Moffitt 2003-03-18 11:40:05 UTC 
I can't see any gray background in the pdf when viewed with Ghostscript.  Can
you reproduce this with just Ghostscript?
Comment 4 Dale Carlin 2003-03-18 12:12:27 UTC 
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?
Comment 5 Dale Carlin 2003-04-10 12:13:34 UTC 
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
Comment 6 Dan Coby 2003-04-10 12:46:38 UTC 
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 ***
Comment 7 Dan Coby 2003-04-10 22:27:02 UTC 
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!
Comment 8 Dan Coby 2003-04-11 10:45:04 UTC 
Still investigating the ICC profile logic.
Comment 9 Dan Coby 2004-06-17 10:23:42 UTC 
The transfer function logic has been changed.

The accuracy of the ICC logic is bug 686750