possibly bad sreening PS in Freehand 7.0.1 
Author Message
 possibly bad sreening PS in Freehand 7.0.1

I have what seems to be a problem with the PS that Freehand 7.0.1
generates to set a screen. It does this with

63.25 18.43 currentscreen exch pop exch pop setscreen

(to set a screen with the same spot function as before, a
frequency of 63.25 lpi, and an angle of 18.43 degrees).

But the Red Book says that if the previous screen was set
with sethalftone, then currentscreen will return

60 0 halftone_dict

and the Freehand PS will not change the angle or ruling,
which is exactly what I'm seeing, on a RIP where the
default screen is established with a sethalftone.

Can anyone confirm that this is a bug? (The only way I
can see it not being one is if some PS earlier in the job
that would do setscreen is not being called, for some
RIP-dependent reason - but maybe I've missed another
possibility).

Does anyone know if other versions of Freehand
have the same problem (if it is a problem)?

Thanks,

S.



Sun, 26 Nov 2000 03:00:00 GMT  
 possibly bad sreening PS in Freehand 7.0.1

Quote:

>I have what seems to be a problem with the PS that Freehand 7.0.1
>generates to set a screen. It does this with

>63.25 18.43 currentscreen exch pop exch pop setscreen

>(to set a screen with the same spot function as before, a
>frequency of 63.25 lpi, and an angle of 18.43 degrees).

>But the Red Book says that if the previous screen was set
>with sethalftone, then currentscreen will return

>60 0 halftone_dict

>and the Freehand PS will not change the angle or ruling,
>which is exactly what I'm seeing, on a RIP where the
>default screen is established with a sethalftone.

Supplements state that if you call

a b dict sethalftone

and that dict is a type 1 halftone dictionary, then a and b are
applied to the dictionary. However this doesn't apply in other
halftone types, and there may be RIPs in which this does not take
place.

Quote:

>Can anyone confirm that this is a bug? (The only way I
>can see it not being one is if some PS earlier in the job
>that would do setscreen is not being called, for some
>RIP-dependent reason - but maybe I've missed another
>possibility).

So - if a non-type 1 halftone dictionary is installed, it may well be
"sticky" for applications that do not use sethalftone. Bug? Maybe.
----------------------------------------

Visit http://www.*-*-*.com/ ,
PSAlter, psalters, tea, and small {*filter*} animals. And stuff.  


Sun, 26 Nov 2000 03:00:00 GMT  
 
 [ 2 post ] 

 Relevant Pages 

1. freehand to ps to pdf

2. Pull Bad-Password-Time and Bad-Password-Count

3. Bad website or bad browser?

4. convert ps to pdf gives dead-bad-picture-quality

5. convert ps to pdf gives dead-bad-quality

6. Word 97 bad PS output

7. bad scaling of PS files

8. PS, HP5M and duplexing ?bad code?

9. PS tax forms are bad too -- Re: Acrobat reader won't print IRS tax forms

10. Bad PS output from Word 6.0 through Linotronic driver

11. Solution: bad ps grayscale

12. Help: Bad color shift in cross-platform Freehand -> postscript

 

 
Powered by phpBB® Forum Software