Windows 10 SCO Filepro issue
Bob Rasmussen
ras at anzio.com
Wed Oct 31 18:49:37 PDT 2018
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:
>>
>>> On 10/26/2018 12:51 AM, Brian White via Filepro-list wrote:
>>>>> I'm not talking about windows print screen, I'm talking about Hardcopy
>>>>> in filePro.
>>>>>
>>>> I don't know why hardcopy would be any different than any other printing
>>>> from fp.
>>>>
>>>> You also said something about a unix spool not passthrough print. If the
>>>> default printer in pfconfig is a unix lp command, then I don't see how
>>> the
>>>> server knows or cares what os the desktop is running.
>>>>
>>>> I think the setup is not described in enough detail.
>>>>
>>>> Log in from one of the win7 machines where printing works, and from the
>>>> win10 machine where printing doesn't work.
>>>>
>>>> Run "set |sort |less" on each. (if you don't have less installed, then
>>>> capture and view any other way. pg, more, vi/view etc...)
>>>>
>>>> Anything different that could affect printing? There are env variables
>>> that
>>>> affect both the spooler and fp's notions of default printer destination,
>>> or
>>>> could inadvertantly affect printing in some indirect way like, totally
>>>> contrived example:
>>>>
>>>> The env is set up to do passthrough after all, PFPT=on (or true or
>>>> whatever), and your fp/termcap has a scoansi entry that includes PN & PS,
>>>> abd only the scoansi entry has it, and TERM or PFTERM is set to scoansi
>>> on
>>>> most desks, but it's set to something else like xterm on the new desk.
>>>>
>>>> It's not literally exactly that, because the break key would not be Del,
>>>> and you couldn't miss that. It's an example only.
>>>>
>>>> Are you logging in as the same user on both working and non-working
>>> desks?
>>>> There is a gotcha with sco osr5 printing where a newly added user might
>>> not
>>>> have permission to use the printing system at all until you manually add
>>>> them in scoadm (or figure out how the default got changed and change it
>>>> back, I forget the details myself)
>>>>
>>>> It could be anything, until you describe the setup more, to remove some
>>> of
>>>> the infinite possibilities.
>>>>
>>>> Follow the trail from fp yo the printer. What is fp going to try to do
>>> when
>>>> you say Y to hardcopy? You have to look at all fp env vars to determine
>>>> that. For instance, the PFCONFIG var, if it exists, says where to load
>>> the
>>>> fp config file from, which may override the file pointed to by fppath
>>> vars.
>>>> So, it's possible for two different desks to load two entirely different
>>>> config fles, which may contain 2 entirely different sets of pfprinter and
>>>> other variables.
>>>>
>>>> Now you hopefully know what fp should try to do, next depends on what
>>> that
>>>> was. Was pfprinter the same fp printer name like printer1 on both? Was
>>> the
>>>> definition of printer1 the same on both? was PFPT either on or off or
>>>> absent the same on both? Was the defintion of printer1 a normal valid lp
>>>> command line? Can you successfully use that same lp command, as that same
>>>> user, from a shell prompt, on both?
>>>>
>>> Since this issue makes no since, I thought I would add some more to it.
>>> After Brian's suggestions, I decided to go back and start from the
>>> beginning and redo all my tests and the additional things he suggested
>>> to make sure I was not losing my mind. So here was my procedure and as
>>> a reminder what I am using:
>>>
>>> SCO 3.2.5.0.6 i386
>>> Filepro 4.05.08K7D4
>>> AlphaCom Terminal Emulation
>>> Windows 7 on all PCs except 1 which is Windows 10
>>> BTW, this is *not* a new user to the system.
>>>
>>> 1. Logged in as user on the W10 PC to the Unix system and into Filepro.
>>> Viewed a record in 3 or 4 different files and pressed H for hardcopy and
>>> nothing prints to the system printer. Pressed F to print a form,
>>> selected the form format that I wanted and it did not print to the
>>> system printer. AlphaCom has a printer icon where you can print what is
>>> on the screen to any printer that is defined on the PC. I printed to
>>> the system printer and to a local printer what was on the screen,
>>> essentially a hardcopy of the record on the screen. That's all fine and
>>> good but still unable to print the form.
>>>
>>> 2. Logged in as the same user on a W7 PC to the Unix system and into
>>> Filepro. Viewed a record in 3 or 4 different files and pressed H for
>>> hardcopy and it prints to the system printer as it should. Pressed F to
>>> print a form, selected the form format that I wanted and it printed to
>>> the system printer as it should. Used the AlphaCom printer icon and
>>> printed to the system printer and to a local printer what was on the
>>> screen, essentially a hardcopy of the record on the screen.
>>>
>>> 3. Per Brian's suggestion, I logged in on the Windows 10 PC to the Unix
>>> system and did a set|sort> env.txt. The list below is what I got back.
>>>
>>> Windows 10 Env User1
>>>
>>> 4. Per Brian's suggestion, I logged in on the Windows 7 PC to the Unix
>>> system, using the same user login, and did a set|sort> env.txt. The
>>> list below is what I got back.
>>>
>>> Windows 7 Env User1
>>>
>>> In this case the only difference I see is COLUMNS=80 and LINES=25. Bare
>>> in mind, that this is the same user on the system and depending on which
>>> system I log in from, W7 or W10, one prints one does not. Because I am
>>> logging into the same user account, I am using the same menus, the same
>>> config files, the same printers. Everything is exactly the same as far
>>> as Unix, filePro, and AlphaCom are concerned.
>>>
>>> What I have not done is use a different emulator on the W10 PC, simply
>>> ran out of time. I will be going back to the client on Monday to try
>>> that. If that does not work I am truly at a loss. I welcome any
>>> feedback that you may be able to offer.
>>>
>>> --
>>>
>>>
>>> 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/20181027/d7cf2ae8/attachment.html
>>>>
>>> -------------- next part --------------
>>> A non-text attachment was scrubbed...
>>> Name: bfgebbibijhpmbik.png
>>> Type: image/png
>>> Size: 33217 bytes
>>> Desc: not available
>>> URL: <
>>> http://mailman.celestial.com/pipermail/filepro-list/attachments/20181027/d7cf2ae8/attachment.png
>>>>
>>> -------------- next part --------------
>>> A non-text attachment was scrubbed...
>>> Name: coklkbdhmflahamg.png
>>> Type: image/png
>>> Size: 29467 bytes
>>> Desc: not available
>>> URL: <
>>> http://mailman.celestial.com/pipermail/filepro-list/attachments/20181027/d7cf2ae8/attachment-0001.png
>>>>
>>> -------------- 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/20181027/d7cf2ae8/attachment.bin
>>>>
>>> _______________________________________________
>>> Filepro-list mailing list
>>> Filepro-list at lists.celestial.com
>>> Subscribe/Unsubscribe/Subscription Changes
>>> http://mailman.celestial.com/mailman/listinfo/filepro-list
>>>
>>
>>
>> --
>> bkw
>> -------------- next part --------------
>> An HTML attachment was scrubbed...
>> URL: <http://mailman.celestial.com/pipermail/filepro-list/attachments/20181031/e8fd276c/attachment.html>
>> _______________________________________________
>> Filepro-list mailing list
>> Filepro-list at lists.celestial.com
>> Subscribe/Unsubscribe/Subscription Changes
>> http://mailman.celestial.com/mailman/listinfo/filepro-list
>>
>
> --
> Audio panton, cogito singularis.
> _______________________________________________
> Filepro-list mailing list
> Filepro-list at lists.celestial.com
> Subscribe/Unsubscribe/Subscription Changes
> http://mailman.celestial.com/mailman/listinfo/filepro-list
>
Regards,
....Bob Rasmussen, President, Rasmussen Software, Inc.
personal e-mail: ras at anzio.com
company e-mail: rsi at anzio.com
voice: (US) 503-624-0360 (9:00-6:00 Pacific Time)
fax: (US) 503-624-0760
web: http://www.anzio.com
street address: Rasmussen Software, Inc.
10240 SW Nimbus, Suite L9
Portland, OR 97223 USA
More information about the Filepro-list
mailing list