Windows 10 SCO Filepro issue

[Rod Caddy]

On 10/31/2018 8:43 PM, Rod Caddy via Filepro-list wrote:
> On 10/31/2018 7:12 PM, Brian White via Filepro-list wrote:
>> Good grief... after all this time, I finally look at the png screen
>> captures, and instantly what do I see? A variable that controls 
>> filepro's
>> behavior exactly as I said since the beginning. PFPT=on tell fp 
>> binaries to
>> try to use pathrough printing, by default, if possible. Both clients are
>> setting PFPT=on, both clients are setting TERM=scoansi.
>>
>> For passthrough printing from filepro to work, several things must 
>> all be:
>> * The termcap entry that matches $TERM must include PN and PS caps which
>> work on that terminal. In filepro, the termcap entry is built up from 
>> two
>> files, /etc/termcap and $PFDATA/$PFDIR/fp/termcap (or could also be
>> specified entirely in an environment variable $TERMCAP which 
>> overrides the
>> termcap files)
>>
>> * The terminal must actually recognize those escape codes from the PN 
>> and
>> PS termcap caps, and do something with the data collected in between the
>> printer-on and printer-off codes. IE, if the terminal software has a 
>> config
>> option for what to do with passthrough print data, you might have to
>> actively configure it to say what printer it should send the print 
>> data to,
>> else it might simply eat the data and do nothing with it.
>>
>> * The destination that the terminal software sends the data to, must be
>> able to make sense of PCL5 data. There are a few different ways to 
>> arrange
>> this. Sometimes there is an option you can set in the printer driver
>> properties that says not to mess with the data, just forward it to the
>> printer raw. That would/should work as long as the printer itself 
>> actually
>> understands pcl5. Today, many don't. HP in particular confuses things 
>> even
>> more by having printer drivers that sometimes silently translate pcl5 
>> from
>> an application into pcl6 for the printer, making you think the printer
>> supports pcl5 when it really doesn't. In the case of HP, try to look for
>> alternative versions of the printer driver, with PCL or PCL5 in the
>> driver's name. Remove the currently installed driver and install that
>> alternative, and that *might* make passthrough printing from filepro
>> through that terminal start working. Alternatively, if the "terminal
>> software" is AnzioWin, it has it's own built-in pcl interpreter, and 
>> should
>> always work with any printer that any other Windows app can print to, 
>> since
>> it interprets the pcl itself and renders it as graphics and hands the
>> bitmap data to windows's native gdi printing interface for windows to
>> print, without caring what kind of printer you have as long as you 
>> have a
>> working windows driver for it, the same as any other windows app does.
>>
>> You could also try removing PFPT=on from the envirnment, which will 
>> cause H
>> hardcopy to go to whatever printer is set as default in pfconfig.
>>
>> Also verify, HOW is TERM getting set to "scoansi"? (and how is PFPT 
>> getting
>> set to on?)
>> Is it being hard-coded in .profile or /etc/profile? Or is it coming from
>> the terminal emulator?
>> What I'm getting at is, are both terminal client apps really 
>> configured to
>> emulate sco-ansi?
>>
> I get what you are saying with PFPT=on but then why does it work on 
> the W7 box using the same login and settings?  I'm sorry if I'm being 
> thick but that makes no sense to me.
>
First, I must apologize for the delay in finishing this post off but I 
have been dealing with a family illness, again my apologies. Second, 
thanks to all who responded and put your 2 cents in on my issue, it was 
quite a learning experience for me.  It is true that during logon the 
PFPT=on was set and initially it made no sense to me why it would allow 
printing to the main system printer under Windows 7 and not under 
Windows 10 when nothing else other than the OS had changed.  While I do 
not pretend to understand, in minute detail,  the inner workings of how 
all the pieces that are involved work together, I now understand why it 
can react differently.  For that, I especially want to thank Bob, Mark, 
and Brian.  I did resolve this by commenting out PFPT=on in the .profile 
of the user.  While it eliminates the ability to local print this is not 
a big issue.  Thank all of you for your time and dedication to helping 
us all, even when it seems that the answer is obvious.

-- 

Pro-Set Systems Logo <www.pro-set.com>  Rod Caddy
   Pro-Set Systems
   rcaddy at pro-set.com
The information in this e-mail is confidential and may be privileged. If
   you are not the intended recipient, please destroy this e-mail and
   notify the sender immediately. You should not retain, copy, distribute
   or use this e-mail for any purpose, nor disclose any of its contents to
   any other person.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.celestial.com/pipermail/filepro-list/attachments/20181130/3a0214be/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: lglogo3.ico
Type: image/x-icon
Size: 6862 bytes
Desc: not available
URL: <http://mailman.celestial.com/pipermail/filepro-list/attachments/20181130/3a0214be/attachment.bin>