<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:49 PM, Bob Rasmussen
via Filepro-list wrote:<br>
</div>
<blockquote type="cite"
cite="mid:alpine.DEB.2.10.1810311831390.14721@server-04">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.
<br>
<br>
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.
<br>
<br>
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.
<br>
<br>
On Wed, 31 Oct 2018, Fairlight via Filepro-list wrote:
<br>
<br>
<blockquote type="cite">Yeah, but what's weird then is the claim
that Win7's attempts go out the
<br>
system printer, rather than pass-through. If both are set to
PFPT=on, then
<br>
why would they act differently on the same software?
<br>
<br>
I suspect we haven't seen everything. Primarily differences in
client
<br>
configurations, as I alluded to last night.
<br>
<br>
m->
<br>
<br>
<br>
On Wed, Oct 31, 2018 at 08:12:44PM -0400, Brian White via
Filepro-list thus spoke:
<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>
--
<br>
bkw
<br>
<br>
On Sun, Oct 28, 2018 at 1:15 PM Rod Caddy via Filepro-list
<
<br>
<a class="moz-txt-link-abbreviated" href="mailto:filepro-list@lists.celestial.com">filepro-list@lists.celestial.com</a>> wrote:
<br>
</blockquote>
</blockquote>
</blockquote>
<br>
<blockquote type="cite"
cite="mid:alpine.DEB.2.10.1810311831390.14721@server-04">
<blockquote type="cite">
<blockquote type="cite">SNIP<br>
</blockquote>
</blockquote>
<br>
</blockquote>
<p>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.<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.ABA2F3F8.5ADCA30B@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>