Skip to first unread message
fwinans
Aug 23, 2012, 12:24:52 PM8/23/12
to mvd...@googlegroups.com
'Slave' printing is where your terminal or term emulator software honors a pair of escape sequences that bracket printer data sent to your login session; this data gets diverted to a printer port on back of terminal or to some windows-connected printer. Logistically, it is a nice concept for roaming end-users that want hardcopy from their luggable printer in the hotel room, for example. It is so seldom used I put notes here for the distant future next time I need to set it up...
I've seen sites remarking that slave mode is 'a lousy way to print,' and is the choice of last resort. Dunno, I never use it.
Not all terminals offer this feature. If you see a port on back marked 'aux' it is probably a db25 serial printer
port. Wyse terminals have it, as I would guess do any foo-enh or foo-enhanced terminals {I think enhanced
refers here to having many neat features that wyse terminals offer.} X terms and at least the vt100, vtnnn series
of DEC ansi terminals have the feature, too. Linux text mode console has it, but is is not documented in the /etc/termcap
file or the terminfo directory tree for the TERM='linux' or similar linux-side choices. {Use char(27):"[5i" for on,
char(27):"[4i" for on when at text mode console screen or in accuterm on 'linux console' emulation. If you
forget these, see them as strings prtr_on and prtr_off of output of infocmp -L vt100 } Erm, on linux console, the data goes to default cups printer; do lpstat -d to see which that is.
The supplied codes for Wyse 60 in d3 don't look right to me; ct devices wy60 after sel-restoring that from the
d3 installation "dt" pseudo-floppy indicates that -17 slave on is X'12' which is a decimal 18 which is ^R, but at least
on my accuterm 2k2 wyse 60 emulation that makes the data go to _both_ slave printer and screen. The wyse 30 user's guide appendix C reinforces that interpretation, and shows ^X {char(24)} is the better choice. 24 decimal is X'18'
I've got no gripe about the listed -18 slave off setting of X'14' {decimal 20 which is ^T}. ^X and ^T worked ok in my
quick Accuterm wyse 60 mode test.
So if you walk a client through using slave printing, and they immediately state 'it did not work' since they see their
report 'printed' to the screen, make them go look on their printer, since a copy may be there too.
D3 has options in the SP-ASSIGN verb to turn on slave printing. SP-ASSIGN AS means "A" for slave mode,
"S" for suppress the spare copy that would have otherwise gone to whatever your printer form queue number is.
This should change your sp-assign ? flags from P to S A
I have some old notes that D3 sometimes prints sort/list headings on one page, then formfeeds, in error, before the body of the report when doing slave printing. The workaround was to do term ,,,,0 instead of the more usual ,,,,1
but make sure that doesn't also mess up your report by keeping it from putting start of each heading line at start
of a new sheet of paper. Not sure how common this problem ever was, or if the ,,,,0 was that hard to live with.
Erm, on the linux side, /bin/echo -en '\E]5i' is the correct syntax for coughing out a 'printer on' code.
Just echo '\E]5i' , or /bin/echo without the -en, will fail to honor the \E syntax and also slap a linefeed on the end.
I've seen sites remarking that slave mode is 'a lousy way to print,' and is the choice of last resort. Dunno, I never use it.
Not all terminals offer this feature. If you see a port on back marked 'aux' it is probably a db25 serial printer
port. Wyse terminals have it, as I would guess do any foo-enh or foo-enhanced terminals {I think enhanced
refers here to having many neat features that wyse terminals offer.} X terms and at least the vt100, vtnnn series
of DEC ansi terminals have the feature, too. Linux text mode console has it, but is is not documented in the /etc/termcap
file or the terminfo directory tree for the TERM='linux' or similar linux-side choices. {Use char(27):"[5i" for on,
char(27):"[4i" for on when at text mode console screen or in accuterm on 'linux console' emulation. If you
forget these, see them as strings prtr_on and prtr_off of output of infocmp -L vt100 } Erm, on linux console, the data goes to default cups printer; do lpstat -d to see which that is.
The supplied codes for Wyse 60 in d3 don't look right to me; ct devices wy60 after sel-restoring that from the
d3 installation "dt" pseudo-floppy indicates that -17 slave on is X'12' which is a decimal 18 which is ^R, but at least
on my accuterm 2k2 wyse 60 emulation that makes the data go to _both_ slave printer and screen. The wyse 30 user's guide appendix C reinforces that interpretation, and shows ^X {char(24)} is the better choice. 24 decimal is X'18'
I've got no gripe about the listed -18 slave off setting of X'14' {decimal 20 which is ^T}. ^X and ^T worked ok in my
quick Accuterm wyse 60 mode test.
So if you walk a client through using slave printing, and they immediately state 'it did not work' since they see their
report 'printed' to the screen, make them go look on their printer, since a copy may be there too.
D3 has options in the SP-ASSIGN verb to turn on slave printing. SP-ASSIGN AS means "A" for slave mode,
"S" for suppress the spare copy that would have otherwise gone to whatever your printer form queue number is.
This should change your sp-assign ? flags from P to S A
I have some old notes that D3 sometimes prints sort/list headings on one page, then formfeeds, in error, before the body of the report when doing slave printing. The workaround was to do term ,,,,0 instead of the more usual ,,,,1
but make sure that doesn't also mess up your report by keeping it from putting start of each heading line at start
of a new sheet of paper. Not sure how common this problem ever was, or if the ,,,,0 was that hard to live with.
Erm, on the linux side, /bin/echo -en '\E]5i' is the correct syntax for coughing out a 'printer on' code.
Just echo '\E]5i' , or /bin/echo without the -en, will fail to honor the \E syntax and also slap a linefeed on the end.
Ed Clark
Aug 23, 2012, 5:26:15 PM8/23/12
to mvd...@googlegroups.com
On Aug 23, 2012, at 12:24 PM, fwinans <fwi...@sbcglobal.net> wrote:
> 'Slave' printing is where your terminal or term emulator software honors a pair of escape sequences that bracket printer data sent to your login session; this data gets diverted to a printer port on back of terminal or to some windows-connected printer. Logistically, it is a nice concept for roaming end-users that want hardcopy from their luggable printer in the hotel room, for example. It is so seldom used I put notes here for the distant future next time I need to set it up...
Slave printing is especially useful when an application uses carbon copy forms on dot matrix printers, or some other type of special forms. you make use of cheap convenient printers without having to complicate the printing of normal jobs on a spool printer.
>
> I've seen sites remarking that slave mode is 'a lousy way to print,' and is the choice of last resort. Dunno, I never use it.
>
> Not all terminals offer this feature. If you see a port on back marked 'aux' it is probably a db25 serial printer
> port.
God help anyone still using an actual dumb terminal rather than an emulator. There's no help at all for anyone using a terminal so dumb that doesn't support aux printing.
> I've seen sites remarking that slave mode is 'a lousy way to print,' and is the choice of last resort. Dunno, I never use it.
>
> Not all terminals offer this feature. If you see a port on back marked 'aux' it is probably a db25 serial printer
> port.
> Wyse terminals have it, as I would guess do any foo-enh or foo-enhanced terminals {I think enhanced
> refers here to having many neat features that wyse terminals offer.} X terms and at least the vt100, vtnnn series
> of DEC ansi terminals have the feature, too. Linux text mode console has it, but is is not documented in the /etc/termcap
> file or the terminfo directory tree for the TERM='linux' or similar linux-side choices. {Use char(27):"[5i" for on,
> char(27):"[4i" for on when at text mode console screen or in accuterm on 'linux console' emulation. If you
> forget these, see them as strings prtr_on and prtr_off of output of infocmp -L vt100 } Erm, on linux console, the data goes to default cups printer; do lpstat -d to see which that is.
>
> The supplied codes for Wyse 60 in d3 don't look right to me; ct devices wy60 after sel-restoring that from the
> d3 installation "dt" pseudo-floppy indicates that -17 slave on is X'12' which is a decimal 18 which is ^R, but at least
> on my accuterm 2k2 wyse 60 emulation that makes the data go to _both_ slave printer and screen. The wyse 30 user's guide appendix C reinforces that interpretation, and shows ^X {char(24)} is the better choice. 24 decimal is X'18'
> I've got no gripe about the listed -18 slave off setting of X'14' {decimal 20 which is ^T}. ^X and ^T worked ok in my
> quick Accuterm wyse 60 mode test.
> So if you walk a client through using slave printing, and they immediately state 'it did not work' since they see their
> report 'printed' to the screen, make them go look on their printer, since a copy may be there too.
>
> D3 has options in the SP-ASSIGN verb to turn on slave printing. SP-ASSIGN AS means "A" for slave mode,
> "S" for suppress the spare copy that would have otherwise gone to whatever your printer form queue number is.
> This should change your sp-assign ? flags from P to S A
>
> I have some old notes that D3 sometimes prints sort/list headings on one page, then formfeeds, in error, before the body of the report when doing slave printing. The workaround was to do term ,,,,0 instead of the more usual ,,,,1
> but make sure that doesn't also mess up your report by keeping it from putting start of each heading line at start
> of a new sheet of paper. Not sure how common this problem ever was, or if the ,,,,0 was that hard to live with.
>
> Erm, on the linux side, /bin/echo -en '\E]5i' is the correct syntax for coughing out a 'printer on' code.
you mean [5. not ]5
> The supplied codes for Wyse 60 in d3 don't look right to me; ct devices wy60 after sel-restoring that from the
> d3 installation "dt" pseudo-floppy indicates that -17 slave on is X'12' which is a decimal 18 which is ^R, but at least
> on my accuterm 2k2 wyse 60 emulation that makes the data go to _both_ slave printer and screen. The wyse 30 user's guide appendix C reinforces that interpretation, and shows ^X {char(24)} is the better choice. 24 decimal is X'18'
> I've got no gripe about the listed -18 slave off setting of X'14' {decimal 20 which is ^T}. ^X and ^T worked ok in my
> quick Accuterm wyse 60 mode test.
> So if you walk a client through using slave printing, and they immediately state 'it did not work' since they see their
> report 'printed' to the screen, make them go look on their printer, since a copy may be there too.
>
> D3 has options in the SP-ASSIGN verb to turn on slave printing. SP-ASSIGN AS means "A" for slave mode,
> "S" for suppress the spare copy that would have otherwise gone to whatever your printer form queue number is.
> This should change your sp-assign ? flags from P to S A
>
> I have some old notes that D3 sometimes prints sort/list headings on one page, then formfeeds, in error, before the body of the report when doing slave printing. The workaround was to do term ,,,,0 instead of the more usual ,,,,1
> but make sure that doesn't also mess up your report by keeping it from putting start of each heading line at start
> of a new sheet of paper. Not sure how common this problem ever was, or if the ,,,,0 was that hard to live with.
>
> Erm, on the linux side, /bin/echo -en '\E]5i' is the correct syntax for coughing out a 'printer on' code.
> Just echo '\E]5i' , or /bin/echo without the -en, will fail to honor the \E syntax and also slap a linefeed on the end.
>
>
>
> You received this message because you are subscribed to
> the "Pick and MultiValue Databases" group.
> To post, email to: mvd...@googlegroups.com
> To unsubscribe, email to: mvdbms+un...@googlegroups.com
> For more options, visit http://groups.google.com/group/mvdbms
Tony Gravagno
Aug 23, 2012, 6:53:12 PM8/23/12
to mvd...@googlegroups.com
From: Ed Clark
time.
Since you're being picky:
> char(27):"[5i" for on, char(27):"[4i" for on ...
should be: char(27):"[5i" for on, char(27):"[4i" for OFF
T
> > Erm, on the linux side, /bin/echo -en '\E]5i' is the
correct syntax
> for coughing out a 'printer on' code.
>
> you mean [5. not ]5
That is The Most Awesome moment of GEEK that we've had here in a Long
correct syntax
> for coughing out a 'printer on' code.
>
> you mean [5. not ]5
time.
Since you're being picky:
> char(27):"[5i" for on, char(27):"[4i" for on ...
should be: char(27):"[5i" for on, char(27):"[4i" for OFF
T
Rex Gozar
Aug 24, 2012, 8:30:57 AM8/24/12
to mvd...@googlegroups.com
add it to PickWiki.com ...
Reply all
Reply to author
Forward
0 new messages