(OT) Open source PCL to PDF converters?

[Brian K. White]

----- Original Message ----- 
From: "Fairlight" <fairlite at fairlite.com>
To: "filePro" <filepro-list at lists.celestial.com>
Sent: Monday, March 12, 2007 2:21 PM
Subject: Re: (OT) Open source PCL to PDF converters?


> On Mon, Mar 12, 2007 at 01:52:18PM -0400, after drawing runes in goat's 
> blood,
> Walter Vaughan cast forth these immortal, mystical words:
>> I don't have a solution, but just a comment that we accept a system that
>> generates PCL5 code as "normal", but pdf creation as something "abnormal" 
>> and
>> needs a converter.
>>
>> What has happened to us to allow this as normal?
>>
>> Golly it's 2007. I accepted it in 1997. But come on, what happened to us?
>
> Blame Adobe.  The same was true of PostScript for years.  I remember when
> PS-enabled printers cost an extra $1k for the module that let them do it.
>
> Adobe came up with a new document format that has no relationship to the
> printer, and -something- has to sit as a shim between the PDF and the 
> print
> spool.  You don't have that problem with PCL5 because it can go directly 
> to
> the printer.  You did have that problem with PS because unless you had a
> PS-enabled printer, you needed something, again, to translate.
>
> Find a PDF-enabled printer, then.  I'd swear I've heard such creatures
> exist.  Goodbye problems.

Even if the printer could do it it's still better to not require it of the 
printer.

At one client there is a process that was created before I got there, which 
used PS to print bar codes to PS capable printers.
mostly HP 1320's to be exact. The process used ghostpcl to first convert the 
filepro plain text to ps, then appended a gnu barcode generator in ps and a 
couple of ps commands to use the generator code, and sent it all to the 
printer as a single ps job.

There was nothing inherently wrong with the process, which is why when I 
needed to start creating barcodes I used it.
But once in production it turned out the printer went from about 1 to 3 
seconds to print the form, to 10 to 15 seconds, and, around 10% of the 
sheets just never printed.
This is a point of sale type, highly streamlined and fixed kind of process, 
it's not simple for the user to get a reprint so both the speed and the 
reliability were big deals.

Again there was nothing inherently weak in the process being used. There was 
no reason it should have failed once in a while

I changed things around so that now it still uses that ps barcode program, 
but instead of converting the filepro pcl to ps and sending a ps job to the 
printer, now it uses gs (ghostscript now, not ghostpcl) to convert the ps 
bacode program to pcl, and sends a single pcl job to the printer.

It's printing exactly the same images on the paper but now it's as fast as 
it was originally and as reliable.

Moral: maybe the trend to dumb windows printers isn't so dumb because thats 
about what I did here. I traded having the printer do a lot of cpu work 
interpreting a ps program, for having the server do that, and sending a 
simpler print job to the printer, and the result was the print happens way 
faster, is way more reliable, and the printer could be cheaper, except in 
this case I think really the printer already is cheaper and just should 
never have advertised it could do ps.

I bemoan the loss of modems and printers and sound cards etc.. that have 
their own brains too but maybe that model just isn't actually the most 
efficient any more.
As the desktop and server cpus get ever faster, the amount of work required 
to render a print job or modulate/demodulate the data stream of a modem has 
not increased. So the percent of the cpu's capacity that a printer or a 
modem is robbing is dwindling down to insignificance, or at least less 
significance than the cost of making printers with cpus and mini os's and 
heavy weight rendering engines.

As for the other efficiency, sending masses of bitmap data over the wire vs 
nice tiny instructions and plain text, maybe pcl6/pxl is the answer to that.
It claims to be an efficient data stream. I would say maybe compression 
techniques are cheap enough and good enough to make up the difference for 
sending lots of low level raster data vs a little bit of high level 
instruction data, but if that were true then why is RDP so amazingly faster 
than VNC still? So I don't really have an answer for that. Maybe printers 
should all be dumb, and speak the same standard dumb language, and then 
maybe print servers should have the brains so that you can optionally add 
brains and network efficiency, and whatever kind of data compatibility like 
pdf or html, where needed?

woo, is that an untapped market for an appliance that no one has made yet? 
Between wine and ndiswrapper I bet the code mostly exists already to make an 
uber print server that runs linux or freebsd (they both have ndiswrapper and 
wine) and could operate any windows printer by using the actual windows 
drivers. A nice little web interface for installing the driver and away you 
go. You'd have to licence a more professional quality pcl rendering engine 
since ghostpcl really does have a lot of weaknesses. Or invest in improving 
ghostpcl. But good engines also already exist ready made. Vsifax uses 
TechKnow Systems and it's fast & light and available for linux and lots of 
other *nix and does an excellent job.
(run the pcltotif binary from a vsifax demo install and look at the 
resulting tiff in a text/hex editor. Dirty secret side note: you can get 
that binary to run without the rest of vsifax, beyond the length of the demo 
period when the vsifax server would stop working, and feed those tiffs right 
into hylafax. Free, vsifax-quality pcl faxing via hylafax. Now if I could 
just figure out the autotypes file in hylafax and make it transparent...)

Brian K. White    brian at aljex.com    http://www.myspace.com/KEYofR
+++++[>+++[>+++++>+++++++<<-]<-]>>+.>.+++++.+++++++.-.[>+<---]>++.
filePro  BBx    Linux  SCO  FreeBSD    #callahans  Satriani  Filk!