OT: skinflinter printing

[Brian K. White]

----- Original Message ----- 
From: "Bob Rasmussen" <ras at anzio.com>
To: "FilePro Mailing List" <filepro-list at lists.celestial.com>
Sent: Thursday, April 14, 2005 10:13 AM
Subject: Re: OT: skinflinter printing


> On Wed, 13 Apr 2005, Jean-Pierre A. Radley wrote:
>
>> Mailing an invoice or other document consumes postage stamps.
>> Faxing also costs a few pennies.
>>
>> For those of my correspondents who are 'net-connected, I eschew such
>> picayune disbursements of pennies: using uucp over tcp/ip, I print the
>> output on a printer near the desk of the person who should receive it.
>> ...
>
> Your approach will work if you have control over, and knowledge of, the
> entire network. In other situations, it has shortcomings. What if you need
> to print fancy, but you don't know what kind of printer they have?
>
> Let me suggest another approach, which is rapidly gaining popularity.
> Generate a PDF, and then email it to the intended recipient. Note that
> Print Wizard is able to generate PDFs. We're working on adding an
> automatic email capability. This appeoach has these advantages:
>
> 1. You can use all kinds of printcodes, including those that generate form
> overlays, barcodes, picture inclusions, orientation settings, paper size,
> etc.
>
> 2. You don't care (or need to know) what kind of printer the user has.
>
> 3. The user can view the software before printing it.
>
> 4. The user can work on any of several OS platforms.
>
> 5. There is no need for static IPs.
>
> 6. It is not blocked by firewalls.
>
> I could go on...
>
> Regards,
> ....Bob Rasmussen,   President,   Rasmussen Software, Inc.


I'm working on something right now where our app will send emails that are 
only html, and so they display immediately, right in the mail client, no 
acrobat.

I discovered that there is a css mechanism for pagination and as long as I 
don't print very wide lines, it works great. If I print wide lines, then 
when the user prints the email the right hand side gets chopped off.

What I am able to do though, is print most plain text reports and forms to a 
file, and build an email file that has both text and scanned images (invoice 
followed by scanned, signed  proof of delivery, followed by another invoice, 
followed by more scanned docs...) and it all pops up right in the mail 
client. The images aren't even attachements. They actually are, but it's my 
choice by twiddling a mail header whether they show up as attachments or not 
in the mail client.

The images are just png files, not pdf.

I'll send you 50 pdf emails and 50 plain emails, and you tell me which type 
you want to get 50 of every day.
I'd pull my hair out if any regular, important mail came to me in pdf form.

UNLESS, someone writes an email client that can directly render pdf.
Then I do a 180 and want everything in pdf.

EXCEPT, it costs my server utterly miniscule resources to generate one of 
these html/mime/base64 email files.
it costs significant resources to generate the same pdf.

An email that has 2 pages of plain text and 10 full letter size 100dpi, 8bit 
grayscale, jpeg (avg 100k/page)
or 200dpi, 1bit b&w, png (avg 40k/page) takes my server about 1/10th of a 
second total real time (timed with "timex" command) to assemble the mail 
file and submit it to sendmail.
This includes runing the pcl report file through a couple of sed scripts to 
strip out pcl codes and convert ibm graphics to plain ascii, and running 
base64 on all the image files.
This is while the system is busy with about 100 users logged in running 
filepro and various other apps. (vsifax, pcmiler, web server)

I can't time creating the same pdf at the moment as I don't have a working 
ghostscript, which imagemagick uses to convert jpg tp pdf, but the last time 
I did it took 10 to 30 seconds to do one page on a new, idle, box. Also, it 
creates huge temp files in /usr/tmp, that on some boxes with small root 
filesystems, fills up the root fs and the job crashes and sometimes the temp 
files are left behind, and a full root fs is a big problem. Generating the 
html mail with base64 uses no space other then the output file itself and I 
decide where that is created and it is nowhere near the size of those IM 
temp files.



A similar html file that has no mime and no base64, just html and links to 
images (or links to cgi commands with encrypted query strings that will 
display the images without giving the user access to or knowledge of the 
underlying filesystem layout) will not only paginate correctly when printed, 
but can also be made to pop up the print dialog on page load. So it can be 
generated in tmp and popped up via winstart on the fly as a new print option 
in the application. From the users point of view, they choose the print 
option, and a second later a web page pops up and a windows print dialog 
pops up over top of it. They hit OK and it prints to their default printer, 
and it can be any kind of printer including the cheapest windows-only 
inkejets.

This is NOT as good as printwizard or (presumably, I haven't tested it) the 
anzio web print object, because the web browser is doing the printing and by 
default it shrinks the image a little and adds a .5" or .75" margin on all 
sides, and adds a one line header and footer to every page.

But it's good enough for a surprising number of cases, requires not a shred 
of setup or installation on the PC beyond the terminal emulator which is 
already there just to log in to the app anyways, and is of course all made 
of free stuff plus my own elbow grease on the server side. Rather than 
thinking "unprofessional printing from a web browser" think "professional 
sticking to a least common denominator that will work everywhere" Example: 
UPS on line shipping label printing. This doesn't require activex or 
javascript or any other plugin, but it does require a browser that 
understands CSS.

Any time you get into these print-to-other-than-printer plans, you have to 
be aware of the potential scale-up problems. If it takes 10 seconds of 100% 
cpu load to generate one single page of pdf, what happens when 45 users are 
logged in, and half of them are causing an email to get sent every few 
minutes and several times a day someone or some cron job, runs a report that 
generates hudreds or throusands of such emails (or faxes, or web accessible 
content).  Before this, you never had to worry about that because filepro 
generating print data directly and feeding it to lp uses just about 0 
resources even for the hugest report.

That would be one reason to accept something like printwizard on the PC, 
Then the server would be doing almost 0 work to generate pwml right from 
filepro and the pc would do the work of rendering it into a pdf or to the 
windows-only printer driver. But that's only good for interactive immediate 
printing. You can't use that to have the server send out monthly statements 
from a cron job unless you want to get into setting up a special dedicated 
"printwizard server" windows box.

Brian K. White  --  brian at aljex.com  --  http://www.aljex.com/bkw/
+++++[>+++[>+++++>+++++++<<-]<-]>>+.>.+++++.+++++++.-.[>+<---]>++.
filePro BBx  Linux SCO  Prosper/FACTS AutoCAD  #callahans Satriani