New printer prints blank pages

[Brian K. White]

On 5/17/2017 4:41 PM, Bob Rasmussen wrote:
> See bottom post.
>
> On Wed, 17 May 2017, Brian K. White via Filepro-list wrote:
>
>> On 5/17/2017 11:22 AM, scooter6--- via Filepro-list wrote:
>>> So a GDI printer, while it can print a test page in Linux via CUPS,
>>> filePro
>>> is not able to send data to this type of printer successfully I
>>> assume is
>>> what you're saying?
>>
>> Yes, and no.
>>
>> If a printer works with any other app on linux, (or any *ix), then it
>> works with filepro, if you want it to.
>>
>> Linux applications generally only output postscript or pdf, and the
>> only way "linux" prints to such printers, is because the print
>> spool/queue is configured to invoke a postscript-to-foo or pdf-to-foo
>> converter. (various common image formats are handled too, like you can
>> "lpr file.jpg", but that's not how most applications print to print
>> spoolers)
>>
>> You could set up a printer driver that converts pcl-to-foo exactly the
>> same way if you wanted. It's just a matter of digging in to cups
>> configuration a little more than usually needed, because filepro does
>> not output postscript or pdf directly.
>>
>> One way to go is, you could have filepro execute a pcl-to-postscript
>> conversion in it's own printer config so that the print spooler
>> receives postscript the same as from any other app.
>>
>> Or you can add a pcl filter to cups so cups can accept pcl in addition
>> to postscript.
>>
>> I don't have a nice write-up of what exact steps to take. From a
>> little googling, it looks like you have to touch a few different
>> things. Create a pcltops or pcltopdf filetr, add a mime-type for pcl
>> in a couple places, and probably specify that mime-type on the lpr
>> command line rather than rely on automatic detection.
>> (like: # grep '\<pcl$' /etc/mime.types
>> application/vnd.hp-pcl pcl
>> So:
>> lpr -d printername -o document-format=application/vnd.hp-pcl file.pcl)
>>
>> It looks like it would take a fair amount of trial & error to get it
>> working the first time, but after that it would be an easy recipe to
>> reproduce. It would be useful for all of us.
>>
>> Given the above, maybe the simpler way is just make a simpler script
>> that just converts pcl to ps, and invoke that as part of the printer
>> config in filepro, and that way you avoid having to get into the guts
>> of cups. You'd be feeding PS to cups, which it handles already.
>>
>> Although, this is all for when, for whatever reason, you can't simply
>> use a printer that takes pcl5 or lower natively. It's both more
>> efficient (in cpu/memory/disk/network) and more reliable to simply use
>> lpr -o raw and a printer that supports pcl. I would always do THAT
>> when you have any choice.
>>
>> But, it's not really true to say "linux can print to this printer but
>> filepro can't?" No. filepro can actually print to a pcl6 or gdi
>> printer exactly as well as any other linux application, because none
>> of them prints to those printers either. They are all printing PS or
>> PDF or plain text, and cups is converting on the fly. It could do
>> exactly the same for PCL and it wouldn't be any different.
>>
>> --
>> bkw
>
> Brian, I think you're saying filepro PCL printing on Linux could be MADE
> to work, theoretically, NOT that it DOES work. Am I right? If so, let me
> point out that writing a PCL to PS (or to PDF) translator is a very
> large undertaking.

I'm saying we already have a pcl-to-foo translator (imperfect as it may 
still be even after so many years), and it's no different to make cups 
use ghostpdl to convert pcl-to-foo, than the way it already uses 
ghostscript and a plethora of other special purpose converters to 
convert ps-to-foo.

I say it as "it already works" in the sense that, in a way, it's merely 
a config issue. No one has to write or invent anything, merely specify 
them in a few config files. It's just a bit more involved than usual, 
because you have to edit config files that you normally don't have to 
edit. But they ARE configurable files meant to be customized just for 
this reason.

I *think* the total amount of steps will turn out to be actually fairly 
small. Like adding one line to maybe two different files, and possibly 
copying one script and swapping out a gs command line for an almost 
identical pcl6 commandline, just to convert pcl to ps. Then, if the 
other configs were set correctly, cups would automatically do the rest.

You specify the input mime-type for "pcl" on the lpr command line, and 
cups sees that it has a converter for that mime-type, and automatically 
uses it in whatever chain of filters is needed to go from that to the 
actual printer, for any printer that cups supports.

It may take a little poking to figure out what the least amount of 
manual actions are needed, but that all falls under what I would call 
merely configuration, if a bit more advanced config than usual.

No printer works before you configure it. You have to install the right 
filter driver and PPD file for cups to use it. So, if you are willing to 
say that any printer "works" from any other app, even though they do not 
until after you configure it, then the same is true for filepro.

If you want to say that ghostpdl is not a complete pcl5 interpreter, 
sure I agree, but so what? It certainly handles 99.99% of filepro jobs 
I've ever run through it in 15 years and thousands of users, which have 
included various embedded graphics, soft fonts for MICR and barcodes, 
and custom hpgl forms, as well as every print code in the filepro 
hplaser*.prt files themselves. The job is getting done, and what else is 
there?

The ghostpdl package even already includes both pcl2ps and pcl2pdf 
scripts, which both take either filenames or stdin/stdout.

In fact you could probably just drop that right into a printer config 
definition in filepro right now without touching cups.

Where you currently have:
■lpr -d laser1 -o raw■

Probably just change it to:
■pcl2ps |lpr -d laser1■

So, that would be a different place where it took nothing but a config 
setting, but it's a filepro config setting instead of a cups config setting.

... a quick test confirms that this syntax of using a pipe inside the 
print destination field works. fp is piping the print data in to the 
first thing on the line, rather than appending any temp filename 
arguments to the end.

I don't have a local system with a gdi printer configured, so I wrote it 
to a temp file instead, but I did it using the tee command so that I 
could avoid using any ">" shell redirection. the tee command takes an 
output filename as a commandline argument, the same way lpr takes the 
printer destination as a commandline argument.

So I made a printer in filepro that said this:
■pcl2ps |tee /tmp/print.pdf■

And then just did a hardcopy from rcabe.

And it made a good pdf of the process table in /tmp/print.pdf

That means you could do exactly the same, with an lpr command instead of 
the tee command. And unlike pcl, both ps and pdf data are reliably 
detectable by cups, so you wouldn't have to use the special -o option to 
specify the mime-type. Just print away.

You *don't* want to use "-o raw" in this case. You *want* cups to detect 
and convert the incoming data in this case.

-- 
bkw