printing to file

scooter6 at gmail.com scooter6 at gmail.com
Thu Nov 4 12:27:54 PDT 2010


  Thanks for the email Brian -- and for the stuff on your site - I actually
went in a little bit different direction on this.

  Basically, I downloaded reptmail and am creating a script that will run
after these specific reports run.
  I have the report printing to a file now, then I'm using reptmail to email
it to recipients and then removing the file afterwards.

  I still have other considerations I'm making on some things, so that's all
whiteboard stuff for me to figure out first but I'm
  headed in the right direction.  I also downloaded your ghostpdl so I can
convert the report file to pdf in the event we have
  any client requirements that would rather have pdf attachments instead.

  So far so good in my testing - I have used both reptmail and pcl2pdf
smoothly this morning - now I'm just doing some
  scripting and figuring out which reports, etc I'm going to run thru one of
these scripts or the other......pretty cool stuff you've
  done - thanks a ton!!!

  I will advise if  I need any more 'steering in the right direction' with
what I'm doing.......

  Thanks again

  Scott

On Thu, Nov 4, 2010 at 3:10 PM, Brian K. White <brian at aljex.com> wrote:

>  On 11/4/2010 12:07 PM, scooter6 at gmail.com wrote:
> > I am trying to diminish some of the paper we're using here and am trying
> to
> > divert certain reports, etc to be printed to a file rather than printed
> to a
> > printer.
> >
> > This is my first attempt at doing this, so forgive my ignorance to a
> degree
> > ha
> > In looking at the filePro manual, you should enter:
> >
> > printer file "/tmp/output"<--- as path to where you want the output
> > directed to
> > printer reset<---- to reset all printer functions back to where they
> > started before processing started
> >
> > So, I have a report called recap for a file called PDMbal
> >
> > So, in output processing for 'recap', I do one simple looking to grabt
> the
> > value of a dummy field
> >
> > Then: lookup sta = filename k=16     i=A   -nx
> > Then: aa(4,allup)=sta(2)
> >
> > Then: printer file "/tmp/output"
> > Then: printer reset
> >
> > It DOES create /tmp/output, however it appears all it captures in that is
> > the print code hex values or something....
> > If I look at the output of /tmp/output, using vi:
> > ^[%100^[(10OU^O^[E
> >
> > The actual report then does print (kind of) to my system default printer,
> > but prints it in 2 pages, the first page looks normal like it should,
> > then it prints the 2nd record on a 2nd page, with much larger print
> > type....(there are only 2 records on this report, and when printed
> > 'normally' it prints both records out in condensed print style just as
> I've
> > asked it to.
> >
> > I also even tried putting the printer commands above in a -v processing
> > table, but that had no effect and I got the same results.
> >
> > What am I missing here???
> >
> > BTW this is SCO OpenServer 5.0.5 w/filePro 5.6.07R4
>
> There are some differences between clerk & report, so talking report
> only here.
>
> Assuming you want to control the filename dynamically from processing
> (meaning, using the command line arguments would be inconvenient)
>
> You're probably best off putting -p /dev/null -pc nocodes on the command
> line
> (to prevent any printer init codes or anything at all from going
> anywhere before you reach the point in processing where you've set a
> filename)
>
> Then in processing, in @once, do
>
> @once:
> x = rand("-1")
> of = /tmp/@fi{"_"{getenv("LOGNAME"){"_"{rand(){".pcl"
> printer file of
> printer type "hplaser"
> end
>
> Ideally you should also dispose of the file before exiting if possible,
> just to keep things self contained.
>
> @done:
> printer flush
> printer reset
> to = "someone at somewhere.com"
> system "emailscript < to < of
> x = remove(of)
> end
>
> Also, if you don't do it this way, you'll have to work around
> permissions problems which I've avoided here by ensuring 3 things agree
> with each other.
> 1) since I allowed fp to create the file with "printer file ...",
> and 2) since the external command that uses the file only needs to
> _read_ it,
> and 3) I used fp again to delete the file with remove() (not say, an rm
> command in the system command).
>
> If you wanted to run the report to file and then not use the file until
> after exiting rreport, then you don't need anything in the @done. No
> printer reset, no system, no remove().
>
> In the above example, the only reason I have the printer reset there is
> because you have to have at least a printer flush to ensure the data is
> all written to the file before some other process tries to read the
> file. Preferably a printer reset which actually releases all hold on the
> file.
>
> A lot depends on what you want to do with the file at the end.
> Do you want to write it to a permanent archive directory tree that users
> can browse later at will? How, by http? cgi? direct samba file share
> access?
> Do you want to email it or ftp it somewhere?
> Do you want to display it to the users screen on the spot and don't want
> to keep it any longer than necessary to get it into their web browser or
> pdf viewer?
>
> That last is probably the most useful in most cases. We do _all_ our
> printing that way and it's great. But to do that relaibly and
> conveniently you need to set up some things at the system level to make
> things possible, even easy, in filepro. That would be a whole email by
> itself.
>
> --
> bkw
>  _______________________________________________
> Filepro-list mailing list
> Filepro-list at lists.celestial.com
> Subscribe/Unsubscribe/Subscription Changes
> http://mailman.celestial.com/mailman/listinfo/filepro-list
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.celestial.com/pipermail/filepro-list/attachments/20101104/4cdc3ab8/attachment.html 


More information about the Filepro-list mailing list