Windows 10 SCO Filepro issue

Wed Oct 31 17:48:59 PDT 2018

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.