using pcl2pdf macro in AIX

[Brian K. White]

On 11/10/2010 2:56 PM, daN baueR wrote:
> On Wed, Nov 10, 2010 at 2:27 PM, Kenneth Brody<kenbrody at spamcop.net>  wrote:
>> (Top-posting corrected.)
>>
>> On 11/10/2010 1:22 PM, daN baueR wrote:
>>>>
>>>> Can pcl2pdf take the PCL from stdin?
>>>>
>>> That I don't know.  I tried piping a file to it, and here's the
>>> resulting error message.
>>>
>>> /home/filepro/appl/fpmerge-->newwood | pcl2pdf
>>
>> I'm not sure I get what, exactly, you typed at the command line.
>>
>>> usage: pcl2pdf.sh<INPUTFILENAME>    <OUPUTFILENAME>
>>>    e.g. pcl2pdf.sh filename.prt filname.pdf
>>> sh: newwood:  not found.
>>
>> [...]
>>
>> Many utilities accept "-" as a filename to mean "use stdin".
>>
>> --
>> Kenneth Brody
>
>
> at the prompt I entered this:
>
> # newwood | pcl2pdf
> and that returned an error message saying the correct syntax was
>   pcl2pdf file.pcl file.pdf


You probably don't need the script. Rather than try to work out what the 
script does and how it differs from mine or the one that ships with 
GhostPDL, you can just put the pcl6 command line directly in the printer 
definition:

"pcl6 -dNOPAUSE -dBATCH -sDEVICE=pdfwrite -sOutputFile=$outfile -"

That final "-" tells ghostpdl (pcl6 is the binary for the package called 
ghostpdl, also formerly called ghostpcl)

$outfile you will have to set yourself however you want.

The really good way though is to switch from printing to printers 
defined in the printer config, to printing to file and calling a 
separate print destination program. It's a fair amount of work at first, 
but it gets easier and easier to use once you've got the basic stuff in 
place and start converting your most-used print operations to work the 
new way.

We do it like this:
First write a stand-alone program that:
* expects a file name via command line argument or environment variable
  o or write it as a call table and it expects a declare extern long 
filepro variable
* expects that file to be a pcl file that was generated by printing to 
file using hplaser print code table.
* offers a list of choices what to do with the file
  o print -> select a printer -> lp or rlpr or netcat command to print it
  o pdf -> pcl2pdf -> htdocs/tmp/file -> winstart http://host/tmp/file
  o fax -> fax cover page & number lookup/entry screen -> sendfax/vsifax 
command
  o email -> email cover page & address lookup/entry screen -> email command

Have it loop back and keep displaying that menu after each action, so 
that a user can run a 15 minute report once, but viw it, fax it, email 
it, more than once without having to regenerate it. Always keep the 
original temp file it was given untouched, only read it every time an 
action is chosen, and write out new temp files from it and delete those 
after each action. IE, the program is handed foo.pcl, it reads foo.pcl 
many times and never erases it. But for example for the email option, it 
reads the file.pcl, generates a file.eml from that, and deletes the 
file.eml immediately after using it, then re-displays the menu.

Next write a generic print-defaults gosub which you can F8 paste into 
multiple tables. This gosub will define a unique temp file using several 
variables from filepro and the environment, and rand(), and (re)set some 
filepro printer commands and set any environment variables that your 
printer program above might want, like, suggested default fax numbers or 
email addresses that would make sense for this document in this context.
something like
PRTINI:
declare extern printfile
printfile = "/tmp/"{@fi{@rn{@id{rand(){".pcl"
printer file printfile
printer type "hplaser"
return

Next write a little gosub to run the printer program:
MPRINT:
call "lib/mprint"
x = remove(xf)
return

Finally, wherever you used to have form "formname", just wrap that in 
the two gosubs.

gosub prtini ; form formname ; gosub mprint

the gosubs are generic and can be simply F8 copied onto the end of any 
other table, and inserting the gosub commands around the form commands 
is pretty easy usually. And no other, no exotic changes to your existing 
code. All the fancy work is in the separate printing program where it's 
easier to start simple and grow it to be more sophisticated over time, 
and every little enhancement you make in that one table,  immediately 
applies to every other place in your whole app for free.

In our case the print destination program is written in filepro, but we 
wrapped that in a shell script to make it a stand-alone util that can be 
used in pretty much any context and can accept std-in so you can even 
use it as a magic filepro printer, but running it from a system command 
is better since it lets you control it more. You can set environment 
variables and/or command line arguments to suit the particular job. 
Like, you can give it options to run non-interactively and pre-load the 
menu choices instead of having the print/fax/email menu appear etc.
I showed a call table example here because I'm trying to minimize the 
details since it's all new to you. Using this for rreport (vs rclerk as 
in this example) is different but no harder, but again, I'm trying not 
to write a book all in one email.

-- 
bkw