printing to windows spooler - width of doc problem

[Dennis Malen]

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.

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

Regards,

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


>
> ----- Original Message ----- 
> From: "Dennis Malen" <dmalen at malen.com>
> To: <filepro-list at lists.celestial.com>
> Sent: Friday, April 01, 2005 11:34 AM
> Subject: Fw: printing to windows spooler - width of doc problem
>
>
>>I posted this yesterday. Anyone have an asnswer for me or can you put me 
>>in the right direction.
>>
>> Dennis
>>
>>
>> ----- Original Message ----- 
>> From: "Dennis Malen" <dmalen at malen.com>
>> To: <filepro-list at lists.celestial.com>
>> Sent: Thursday, March 31, 2005 5:02 PM
>> Subject: printing to windows spooler - width of doc problem
>>
>>
>>>I have redefined the printer on the UNIX side to be set up as a generic 
>>>printer in my definition as a remote printer.
>>>
>>> The windows spooler seems to recognize the font code I am using but does 
>>> not recognize filePro's width of page.
>>>
>>> Can anyone suggest a fix for this? I have the report defined as an HP-4+ 
>>> in filePro. Is there code that I can include in the HP-4+ definitions in 
>>> filePro that would solve the width problem?
>>>
>>> The document prints fine except for the width.
>
> The problem is you haven't answered the questions people have asked.
>
> How, _exactly_, are you sending the jobs to windows? And how is the 
> printer configured in windows? ie: any non-default options played with in 
> the printer properties, specifically, the spool settings?
>
> When I define a printer in windows and don't touch the spool settings, the 
> print processor is always RAW.
> When I then share the printer and print to it via facetwin, it's like 
> printing to a direct parallel port printer.
> The data I generate on unix (be it from filepro or touched up by the unix 
> print spooler interface scripts) goes to the printer unmolested in any 
> way, and so all I need to do to have perfect printing is to generate the 
> right data in the first place, which is a simple matter of:
> * configure the printer in unix to use a interface script that has an 
> option for raw mode "HPLaserJet" (raw mode = don't touch the data, ie: 
> don't add a form feed, don't prepend printer setup codes, etc...)
>   In the case of facetwin you don't do this in scoadmin but with: 
> "fct_rlpadmin [options] -m HPLaserJet [options]"
> * use the appropriate print code table in filepro  "hplaser"
> * use the aforementioned "raw" option on the lp command line in fp print 
> config. "lp -d fct_billing -o raw -s"
>
> Sending via Samba instead of facetwin is more complicated to set up, but 
> also results in perfect printing.
> It's slightly possible you have VisionFS instead of either FacetWin or 
> Samba. That works too, but I've used that enough to decide I'd rather use 
> facetwin or samba and never touch it again, and have done so, and so I 
> can't help much with that because I don't have it installed any where and 
> it's usage details are no longer day to day working knowledge for me.
>
> I have used the "print services for unix" that 2K and XP have a few times, 
> which is a way for windows to accept the job via lpr/lpd instead of smb. 
> (actually it doesn't disable smb, so I should say in addition to smb)
> When you define a printer in unix to use lpr, it means selecting "remot 
> printer" in scoadmin, and in that case it doesn't matter what model 
> (interface script) you use because unix doesn't use an interface script 
> for lpr jobs, It's like having -o raw all the time without asking. By 
> default that is. There are /etc/printcap options that can cause the data 
> to be modified on the way out, but none are used by default.
> "man printcap" for details. I have noticed a couple times that printing 
> via lpd/lpr to windows print services for unix, that the print jobs 
> weren't 100% perfect, but I can't help with the fix, because a) because of 
> that very fact, I don't use that method for printing except as a last 
> resort, and I'm very good at never having to resort to my last resort :) 
> and b) sometimes there is no problem, or, the problem was easily corrected 
> by some small change that affects all jobs like a printcap adjustment or a 
> print code table tweak and it was easy to spot the problem and the fix by 
> seeing the first printout.
>
> The "real" answer is to buy a good hp print server and set up netcat 
> printing and stop wasting your time playing with windows. The ones who can 
> provide the best help don't really want to waste their time helping you 
> waste your time to do something they wouldn't even do themselves. The 
> next-best answer (in my opionion) is to use FacetWin, but only if you 
> already have it for other reasons. A single seat licence costs more than a 
> far superior one-port hp print server.
>
> Brian K. White  --  brian at aljex.com  --  http://www.aljex.com/bkw/
> +++++[>+++[>+++++>+++++++<<-]<-]>>+.>.+++++.+++++++.-.[>+<---]>++.
> filePro BBx  Linux SCO  Prosper/FACTS AutoCAD  #callahans Satriani
>
> _______________________________________________
> Filepro-list mailing list
> Filepro-list at lists.celestial.com
> http://mailman.celestial.com/mailman/listinfo/filepro-list
>
>
>