Windows 10 SCO Filepro issue

[Rod Caddy]

On 10/31/2018 8:49 PM, Bob Rasmussen via Filepro-list wrote:
> Mark, I suspect you're right. I think the print jobs are going from 
> filePro on the server, through passthrough print to the terminal 
> software, to that software's configured printer (via Windows), and in 
> the working case at least, to the so-called "system printer", which is 
> probably a network printer that can be fed by many paths.
>
> Rod, you can verify that passthrough print is happening if you run 
> Anzio Lite or AnzioWin as your terminal emulator, and turn on Debug 
> Printing (in the Printer Setup dialog), then do a print job. If 
> passthrough print is happening, a debug dialog will pop up, and may 
> give additional clues.
>
> So what makes the difference between it working on Windows 7 and not 
> working on Windows 10? It likely boils down to the printer driver used 
> in Windows, by the emulator. Not all printer drivers can do low-level 
> print.
>
> On Wed, 31 Oct 2018, Fairlight via Filepro-list wrote:
>
>> Yeah, but what's weird then is the claim that Win7's attempts go out the
>> system printer, rather than pass-through.  If both are set to 
>> PFPT=on, then
>> why would they act differently on the same software?
>>
>> I suspect we haven't seen everything.  Primarily differences in client
>> configurations, as I alluded to last night.
>>
>> m->
>>
>>
>> On Wed, Oct 31, 2018 at 08:12:44PM -0400, Brian White via 
>> Filepro-list thus spoke:
>>> 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?
>>>
>>> -- 
>>> bkw
>>>
>>> On Sun, Oct 28, 2018 at 1:15 PM Rod Caddy via Filepro-list <
>>> filepro-list at lists.celestial.com> wrote:

>>> SNIP
>
Bob, strangely this makes sense what you are saying even though a 
printer is not set in the emulator it is still getting there by default.

-- 

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/20181101/232255f2/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/20181101/232255f2/attachment.bin>