printing to windows spooler - width of doc problem

[Brian K. White]

----- Original Message ----- 
From: "Dennis Malen" <dmalen at malen.com>
To: "Brian K. White" <brian at aljex.com>; "filePro mailing list" 
<filepro-list at seaslug.org>
Sent: Friday, April 01, 2005 5:47 PM
Subject: Re: printing to windows spooler - width of doc problem


> Brian,
>
> Thanks for your response. Let's see if I can explain it to you properly:
>
> The windows server has print services for UNIX running so that jobs are 
> printed through lpd /lpr. The printer is a shared printer on the windows 
> server and it defined as an HP1200 printer using RAW in spooling.

Ok that *should* all be good.
I can tell you this much, we have a lot of unix boxes out there printing to 
a lot of 1200's plugged in to windows boxes. The printer and unix and 
filepro definitely all work fine with each other.
But they are all using facetwin to do it unfortunately.

On the other hand, I do have 2 sites I can think of right off, where this is 
exactly how all of their main printing goes to their main printer. In both 
cases I couldn't go on-site to figure out why facetwin wouldn't work, and 
the guy on site was less than amazing as a diagnoser, so I abandoned the 
mystery of windows authentication difficulties and talked them through 
getting print services for unix going on the pc and luckily it worked and 
now it's been that way for a year.
One of those sites has a big lexmark the size of a washing machine and 
approximately 20 users and a busy 24/7 trucking/warehouse/dispatch office 
and the printer is always busy. The other is more like 5 or 6 users and 
regular weekday hours.

Their forms are typical hplaser forms that use all the common escape codes, 
landscape, compressed, font changes, bold, positioning, etc...
So I do know that it at least CAN work. That is, that there is nothing 
inherent in the windows or unix spoolers that says that it will never work.
So it's reasonable to stick with it and uncover the glitch I guess. In a 
way. Kinda.
I don't know off hand if either of those sites has any forms with raster 
graphics (letterhead logos) on them but I think so.

> The only thing we need to know is what codes to send the printer in order 
> to go beyond 80 character.

3 things to verify.......

1) verify that the print code table that will be in effect at print-time has 
a print code number 13 defined as:
13      °   $1b ( s 16.6 H           °   Set 16.7/17.1 pitch

2) In the output format for the printer, F8 options, change the width of the 
page to whatever you need greater than 80.

3) In the output format, at the top-left corner of the header or full page 
form, press F5 and insert a print code 13

now sequence of tests.......

** Print to file and verify the file has an <esc>(s16.6H in it.
If that doesn't work then something is wrong in fp land.

** Send a small job completely manually, through your existing printer setup 
in unix, but not from filepro.
echo "\033E\033(s16.6Hthis is a test.\r\nis it compressed?\r\n\f\c" |lp -d 
hp1200

You should get 2 lines and they should be in compressed print.
If it works, this also shows the problem is somewhere in filepro.
If it doesn't work, the problem is in the unix spooler or in the windows 
spooler.

** In my case my next test (after verifying that the save print file really 
DOES have escape(s16.6H in it) would be to use rlpr to send the saved print 
file to the windows box without involving the unix print spooler.
rlpr -H host -P printer filename

If that works, then it was the unix spooler and I'd google up the directions 
for using netcat to print on sco, only use "rlpr -H host -P printer" as a 
drop-in replacement for "nc -h host -p port"
You'll still be using the unix spooler, but not the lpr/lpd parts, it'll be 
like any other directly attached printer.
If it doesn't work, then the problem is in the windows spooler or printer 
driver.

Unfortunately I'm pretty sure you don't have rlpr.
Fortunately rlpr is free and compiled sco binaries available on my webt 
site.
Unfortunately you may need to install at least one library update pack 
before the binary will work on your box.
Fortunately that is also free and well tested by now so I can say it's not 
dangerous to install.
I think all you'll need is oss646c, and then only if your box is 5.0.6 or 
less.
You might also need gwxlibs. The only problem with installing these is I've 
seen a lot of boxes where / is so small that there is no room to install 
some of these larger updates!
I've munkied around and moved things that I knew I wouldn't need in 
single-user/emergency/maintenance mode onto /u through the 
magic^H^H^H^H^Hsmoke & mirrors of symlinks,
but no way could I suggest that. If your / has more than a couple hundred 
free megs then it's no problem (run "dfspace" to see). oss646c doesn't 
require a lot of room and you may only need that. It's only an issue if you 
need gwxlibs, and even then, I could just send you the individual library 
files to make rlpr work rather than requiring the whole package.

Good luck :)

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