Re: Postscript printing in QuarkXpress
Re: Postscript printing in QuarkXpress
- Subject: Re: Postscript printing in QuarkXpress
- From: Ken Grimm <email@hidden>
- Date: Fri, 28 Sep 2001 21:06:41 -0500
On 9/26/01 8:54 AM, David Walsh at email@hidden didst forever and
always commit to the digital human communication archive:
>
Hi When i run the script below pointing to the local path reference in the
>
second line everything works fine. But when I set it up to reference the
>
folder on a network server in the third line it generates a -48 error in
>
QuarkXpress. Hope someone can help.
It's a very well-known bug, as Shane pointed out.
However, I have not been able to reliably print to the root folder of the
startup drive! *Regardless* of Desktop Printer setup and directions on where
to print, (believe me, I've tried every single suggestion sent to me and the
"solutions" I could find on the QXP support forums) I have found the
generated .ps files on any given mounted disk! I cannot for the life of me
find a pattern to this.
I did learn a few things though, and it may help others.
SAVE the document before you print it. QXP gets very confused about where it
happens to be pointing on the network at any given time. I have found that
under script control it will save things (documents, .ps files, eps files,
etc.) wherever it last got an imported graphic or text file. I have been
able to reproduce this reliably at work with a hodge-podge mix of Apple and
NT Servers, but can't reproduce it at my house with a G4 and multiple hard
drives (IDE and SCSI) attached to the same computer though PCI cards and
Firewire. It seems to be a network thing only. Saving the document before
printing, exporting, or other activity reduces this phenomenon.
I tried to set up a Desktop Printer as a PostScript translator, but every
single attempt with this setup under script control, regardless of where I
set the target folder to, gave the dreaded -48 error.
The only thing that has worked so far is to print to a Desktop Printer that
has background printing disabled. Where the .ps file finally winds up is a
roll of the dice.
I learned to test for things that I expected to be there after a portion of
script was executed. It takes time for the network to respond to printing,
saving, moving things around, and initial scripts did not take this into
account. The scripts executed WAY too fast, never pausing until a function
was actually COMPLETELY completed. Tests for existence failed immediately,
because the files hadn't made it to their locations yet, but were in the
process of getting there.
One solution that worked was to set up a repeating forever loop after the
printing portion of the script, testing for the existence of the .ps file
generated on every single mounted network volume. When the test returns
true, then it copies the found .ps file to the hot folders of our RIP
stations. All of the copying and printing had to be wrapped in timeout
blocks to work.
Very, very strange brew.
Ken Grimm
Prepress Manager
San Angelo Standard-Times
email@hidden