<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">On 10/31/2018 8:43 PM, Rod Caddy via
Filepro-list wrote:<br>
</div>
<blockquote type="cite"
cite="mid:02556833-581d-839f-528c-66db2208e2cb@pro-set.com">On
10/31/2018 7:12 PM, Brian White via Filepro-list wrote:
<br>
<blockquote type="cite">Good grief... after all this time, I
finally look at the png screen
<br>
captures, and instantly what do I see? A variable that controls
filepro's
<br>
behavior exactly as I said since the beginning. PFPT=on tell fp
binaries to
<br>
try to use pathrough printing, by default, if possible. Both
clients are
<br>
setting PFPT=on, both clients are setting TERM=scoansi.
<br>
<br>
For passthrough printing from filepro to work, several things
must all be:
<br>
* The termcap entry that matches $TERM must include PN and PS
caps which
<br>
work on that terminal. In filepro, the termcap entry is built up
from two
<br>
files, /etc/termcap and $PFDATA/$PFDIR/fp/termcap (or could also
be
<br>
specified entirely in an environment variable $TERMCAP which
overrides the
<br>
termcap files)
<br>
<br>
* The terminal must actually recognize those escape codes from
the PN and
<br>
PS termcap caps, and do something with the data collected in
between the
<br>
printer-on and printer-off codes. IE, if the terminal software
has a config
<br>
option for what to do with passthrough print data, you might
have to
<br>
actively configure it to say what printer it should send the
print data to,
<br>
else it might simply eat the data and do nothing with it.
<br>
<br>
* The destination that the terminal software sends the data to,
must be
<br>
able to make sense of PCL5 data. There are a few different ways
to arrange
<br>
this. Sometimes there is an option you can set in the printer
driver
<br>
properties that says not to mess with the data, just forward it
to the
<br>
printer raw. That would/should work as long as the printer
itself actually
<br>
understands pcl5. Today, many don't. HP in particular confuses
things even
<br>
more by having printer drivers that sometimes silently translate
pcl5 from
<br>
an application into pcl6 for the printer, making you think the
printer
<br>
supports pcl5 when it really doesn't. In the case of HP, try to
look for
<br>
alternative versions of the printer driver, with PCL or PCL5 in
the
<br>
driver's name. Remove the currently installed driver and install
that
<br>
alternative, and that *might* make passthrough printing from
filepro
<br>
through that terminal start working. Alternatively, if the
"terminal
<br>
software" is AnzioWin, it has it's own built-in pcl interpreter,
and should
<br>
always work with any printer that any other Windows app can
print to, since
<br>
it interprets the pcl itself and renders it as graphics and
hands the
<br>
bitmap data to windows's native gdi printing interface for
windows to
<br>
print, without caring what kind of printer you have as long as
you have a
<br>
working windows driver for it, the same as any other windows app
does.
<br>
<br>
You could also try removing PFPT=on from the envirnment, which
will cause H
<br>
hardcopy to go to whatever printer is set as default in
pfconfig.
<br>
<br>
Also verify, HOW is TERM getting set to "scoansi"? (and how is
PFPT getting
<br>
set to on?)
<br>
Is it being hard-coded in .profile or /etc/profile? Or is it
coming from
<br>
the terminal emulator?
<br>
What I'm getting at is, are both terminal client apps really
configured to
<br>
emulate sco-ansi?
<br>
<br>
</blockquote>
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.
<br>
<br>
</blockquote>
<p><font face="Helvetica, Arial, sans-serif">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.</font><br>
</p>
<div class="moz-signature">-- <br>
<meta http-equiv="content-type" content="text/html; charset=utf-8">
<br>
<div class="moz-signature">
<meta http-equiv="content-type" content="text/html;
charset=utf-8">
<title></title>
<a href="www.pro-set.com"><img alt="Pro-Set Systems Logo"
src="cid:part1.0FD20D2D.8D5B7960@pro-set.com" align="left"
height="50" width="42" border="0"></a> Rod Caddy<br>
Pro-Set Systems<br>
<a class="moz-txt-link-abbreviated" href="mailto:rcaddy@pro-set.com">rcaddy@pro-set.com</a><br>
<small> The information in this e-mail is confidential and may
be privileged. If<br>
you are not the intended recipient, please destroy this
e-mail and <br>
notify the sender immediately. You should not retain, copy,
distribute <br>
or use this e-mail for any purpose, nor disclose any of its
contents to <br>
any other person.<br>
</small>
<pre class="moz-signature" cols="72">
</pre>
</div>
</div>
</body>
</html>