Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #265809 > unrolled thread

Seeking a Terminal Emulator on Debian for "Passthrough" Printing

Back to article view | Back to linux.debian.user

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Seeking a Terminal Emulator on Debian for "Passthrough" Printing phoebus phoebus <frphoebus@yahoo.fr> - 2024-01-12 01:40 +0100
    Re: Seeking a Terminal Emulator on Debian for "Passthrough" Printing Stefan Monnier <monnier@iro.umontreal.ca> - 2024-01-12 02:00 +0100
      Re: Seeking a Terminal Emulator on Debian for "Passthrough"  Printing phoebus phoebus <frphoebus@yahoo.fr> - 2024-01-12 14:30 +0100
    Re: Seeking a Terminal Emulator on Debian for "Passthrough" Printing Geert Stappers <stappers@stappers.nl> - 2024-01-12 07:30 +0100
      Re: Seeking a Terminal Emulator on Debian for "Passthrough"  Printing phoebus phoebus <frphoebus@yahoo.fr> - 2024-01-13 02:00 +0100
        Re: Seeking a Terminal Emulator on Debian for "Passthrough" Printing John Hasler <john@sugarbit.com> - 2024-01-13 03:50 +0100
          Re: Seeking a Terminal Emulator on Debian for "Passthrough"  Printing phoebus phoebus <frphoebus@yahoo.fr> - 2024-01-13 09:50 +0100
            Re: Seeking a Terminal Emulator on Debian for "Passthrough"  Printing Trish Fraser <trish@thefrasers.org> - 2024-01-13 10:40 +0100
              Re: Seeking a Terminal Emulator on Debian for "Passthrough"  Printing phoebus phoebus <frphoebus@yahoo.fr> - 2024-01-13 12:10 +0100
            Re: Seeking a Terminal Emulator on Debian for "Passthrough"  Printing debian-user@howorth.org.uk - 2024-01-13 14:00 +0100
              Re: Seeking a Terminal Emulator on Debian for "Passthrough"  Printing phoebus phoebus <frphoebus@yahoo.fr> - 2024-01-13 15:10 +0100
        Re: Seeking a Terminal Emulator on Debian for "Passthrough" Printing hw <hw@adminart.net> - 2024-01-15 20:10 +0100
          Re: Seeking a Terminal Emulator on Debian for "Passthrough" Printing Stefan Monnier <monnier@iro.umontreal.ca> - 2024-01-15 20:30 +0100
          Re: Seeking a Terminal Emulator on Debian for "Passthrough" Printing <tomas@tuxteam.de> - 2024-01-15 21:10 +0100
            Re: Seeking a Terminal Emulator on Debian for "Passthrough" Printing hw <hw@adminart.net> - 2024-01-16 11:50 +0100
              Re: Seeking a Terminal Emulator on Debian for "Passthrough" Printing David Wright <deblis@lionunicorn.co.uk> - 2024-01-18 06:10 +0100
                Re: Seeking a Terminal Emulator on Debian for "Passthrough" Printing hw <hw@adminart.net> - 2024-01-18 12:30 +0100
                  Re: Seeking a Terminal Emulator on Debian for "Passthrough" Printing Greg Wooledge <greg@wooledge.org> - 2024-01-18 13:20 +0100
                    Re: Seeking a Terminal Emulator on Debian for "Passthrough" Printing hw <hw@adminart.net> - 2024-01-18 15:30 +0100
                      Re: Seeking a Terminal Emulator on Debian for "Passthrough"Printing gene heskett <gheskett@shentel.net> - 2024-01-21 02:00 +0100
                        Re: Seeking a Terminal Emulator on Debian for "Passthrough"Printing <tomas@tuxteam.de> - 2024-01-21 07:50 +0100
                          Re: Seeking a Terminal Emulator on Debian for "Passthrough"Printing gene heskett <gheskett@shentel.net> - 2024-01-21 13:50 +0100
                        Re: Seeking a Terminal Emulator on Debian for "Passthrough"Printing "Roy J. Tellason, Sr." <roy@rtellason.com> - 2024-01-21 19:40 +0100
                    Re: Seeking a Terminal Emulator on Debian for "Passthrough" Printing Max Nikulin <manikulin@gmail.com> - 2024-01-21 11:10 +0100
                      Re: Seeking a Terminal Emulator on Debian for "Passthrough" Printing <tomas@tuxteam.de> - 2024-01-22 07:00 +0100
                      Re: Seeking a Terminal Emulator on Debian for "Passthrough" Printing Max Nikulin <manikulin@gmail.com> - 2024-01-22 16:10 +0100
                        Re: Seeking a Terminal Emulator on Debian for "Passthrough" Printing <tomas@tuxteam.de> - 2024-01-22 16:30 +0100
                          Re: Seeking a Terminal Emulator on Debian for "Passthrough" Printing Stefan Monnier <monnier@iro.umontreal.ca> - 2024-01-22 16:40 +0100
                            Re: Seeking a Terminal Emulator on Debian for "Passthrough" Printing <tomas@tuxteam.de> - 2024-01-22 18:50 +0100
                              Re: Seeking a Terminal Emulator on Debian for "Passthrough"Printing gene heskett <gheskett@shentel.net> - 2024-01-23 04:00 +0100
                              Re: Seeking a Terminal Emulator on Debian for "Passthrough" Printing Max Nikulin <manikulin@gmail.com> - 2024-01-24 18:10 +0100
                            Re: Seeking a Terminal Emulator on Debian for "Passthrough" Printing Max Nikulin <manikulin@gmail.com> - 2024-01-23 18:10 +0100
                              Re: Seeking a Terminal Emulator on Debian for "Passthrough" Printing David Wright <deblis@lionunicorn.co.uk> - 2024-01-23 18:20 +0100
                                Re: Seeking a Terminal Emulator on Debian for "Passthrough" Printing Max Nikulin <manikulin@gmail.com> - 2024-01-24 17:50 +0100
                                  Re: Seeking a Terminal Emulator on Debian for "Passthrough" Printing David Wright <deblis@lionunicorn.co.uk> - 2024-01-24 20:50 +0100
                      Re: Seeking a Terminal Emulator on Debian for "Passthrough" Printing Michael Stone <mstone@debian.org> - 2024-01-26 06:50 +0100
                  Re: Seeking a Terminal Emulator on Debian for "Passthrough" Printing David Wright <deblis@lionunicorn.co.uk> - 2024-01-19 03:00 +0100
                    Re: Seeking a Terminal Emulator on Debian for "Passthrough"  Printing phoebus phoebus <frphoebus@yahoo.fr> - 2024-01-21 02:40 +0100
                  Re: Seeking a Terminal Emulator on Debian for "Passthrough"  Printing phoebus phoebus <frphoebus@yahoo.fr> - 2024-01-20 23:20 +0100
                Re: Seeking a Terminal Emulator on Debian for "Passthrough"  Printing phoebus phoebus <frphoebus@yahoo.fr> - 2024-01-20 23:00 +0100
              Re: Seeking a Terminal Emulator on Debian for "Passthrough"  Printing phoebus phoebus <frphoebus@yahoo.fr> - 2024-01-20 22:20 +0100
            Re: Seeking a Terminal Emulator on Debian for "Passthrough"  Printing phoebus phoebus <frphoebus@yahoo.fr> - 2024-01-20 21:20 +0100
              Re: Seeking a Terminal Emulator on Debian for "Passthrough" Printing "tomas@tuxteam.de" <tomas@tuxteam.de> - 2024-01-21 07:50 +0100
          Re: Seeking a Terminal Emulator on Debian for "Passthrough"  Printing phoebus phoebus <frphoebus@yahoo.fr> - 2024-01-20 20:00 +0100
    Re: Seeking a Terminal Emulator on Debian for "Passthrough" Printing Dan Ritter <dsr@randomstring.org> - 2024-01-12 12:30 +0100
      Re: Seeking a Terminal Emulator on Debian for "Passthrough" Printing Tixy <tixy@yxit.co.uk> - 2024-01-12 13:20 +0100
        Re: Seeking a Terminal Emulator on Debian for "Passthrough"  Printing phoebus phoebus <frphoebus@yahoo.fr> - 2024-01-13 02:30 +0100
          Re: Seeking a Terminal Emulator on Debian for "Passthrough" Printing <tomas@tuxteam.de> - 2024-01-13 08:40 +0100
            Re: Seeking a Terminal Emulator on Debian for "Passthrough" Printing Greg Wooledge <greg@wooledge.org> - 2024-01-13 16:10 +0100
              Re: Seeking a Terminal Emulator on Debian for "Passthrough" Printing Richard Hector <richard@walnut.gen.nz> - 2024-01-13 16:50 +0100
              Re: Seeking a Terminal Emulator on Debian for "Passthrough"  Printing Charles Curley <charlescurley@charlescurley.com> - 2024-01-13 17:00 +0100
                Re: Seeking a Terminal Emulator on Debian for "Passthrough" Printing <tomas@tuxteam.de> - 2024-01-13 17:10 +0100
                  Re: Seeking a Terminal Emulator on Debian for "Passthrough" Printing gene heskett <gheskett@shentel.net> - 2024-01-13 19:20 +0100
                    Re: Seeking a Terminal Emulator on Debian for "Passthrough" Printing Larry Martell <larry.martell@gmail.com> - 2024-01-14 20:00 +0100
                Re: Seeking a Terminal Emulator on Debian for "Passthrough"  Printing debian-user@howorth.org.uk - 2024-01-13 17:20 +0100
              Re: Seeking a Terminal Emulator on Debian for "Passthrough"  Printing Charles Curley <charlescurley@charlescurley.com> - 2024-01-13 23:50 +0100
                Re: Seeking a Terminal Emulator on Debian for "Passthrough" Printing Greg Wooledge <greg@wooledge.org> - 2024-01-14 01:50 +0100
                  Re: Seeking a Terminal Emulator on Debian for "Passthrough"  Printing debian-user@howorth.org.uk - 2024-01-14 14:40 +0100
                Re: Seeking a Terminal Emulator on Debian for "Passthrough" Printing Stefan Monnier <monnier@iro.umontreal.ca> - 2024-01-14 06:30 +0100
              Re: Seeking a Terminal Emulator on Debian for "Passthrough" Printing <tomas@tuxteam.de> - 2024-01-14 08:20 +0100
                Re: Seeking a Terminal Emulator on Debian for "Passthrough" Printing "tomas@tuxteam.de" <tomas@tuxteam.de> - 2024-01-14 11:40 +0100
      Re: Seeking a Terminal Emulator on Debian for "Passthrough"  Printing phoebus phoebus <frphoebus@yahoo.fr> - 2024-01-12 14:50 +0100
    Re: Seeking a Terminal Emulator on Debian for "Passthrough" Printing Anssi Saari <anssi.saari@debian-user.mail.kapsi.fi> - 2024-01-12 15:00 +0100
      Re: Seeking a Terminal Emulator on Debian for "Passthrough"  Printing phoebus phoebus <frphoebus@yahoo.fr> - 2024-01-12 17:10 +0100
    Re: Seeking a Terminal Emulator on Debian for "Passthrough" Printing Loïc Grenié <loic.grenie@gmail.com> - 2024-01-15 11:20 +0100
      Re: Seeking a Terminal Emulator on Debian for "Passthrough"  Printing phoebus phoebus <frphoebus@yahoo.fr> - 2024-01-15 18:20 +0100
        Re: Seeking a Terminal Emulator on Debian for "Passthrough" Printing Loïc Grenié <loic.grenie@gmail.com> - 2024-01-15 23:20 +0100
    Re: Seeking a Terminal Emulator on Debian for "Passthrough" Printing Eduardo M KALINOWSKI <eduardo@kalinowski.com.br> - 2024-01-22 14:20 +0100
      Re: Seeking a Terminal Emulator on Debian for "Passthrough" Printing Stefan Monnier <monnier@iro.umontreal.ca> - 2024-01-22 15:00 +0100
        Re: Seeking a Terminal Emulator on Debian for "Passthrough" Printing Eduardo M KALINOWSKI <eduardo@kalinowski.com.br> - 2024-01-22 15:30 +0100

Page 3 of 4 — ← Prev page 1 2 [3] 4  Next page →

#266334 — Re: Seeking a Terminal Emulator on Debian for "Passthrough" Printing

Hello,

>>> I don't understand why you involve a terminal emulator in the process.
>>> Do you need to see the data that goes through the COM port displayed
>>> in a terminal (like minicom)?
>>
>> People interact with the (remote) application by means of the terminal
>> emulator. Things get sent to/from the printer based on escape sequences
>> initiated by the application.

>Desktop sharing works fine with gnome these days.  Why not interact
>with the application through that kinda locally?

You suggest an interesting alternative by using the desktop sharing feature available with GNOME to interact with the application remotely. I was not aware of this particular use of the GNOME feature; I primarily knew it for remote control and screen sharing purposes. At this stage, I am not yet familiar enough with GNOME to provide a comprehensive opinion on this approach.
However, I want to emphasize that within the scope of the mission I have been entrusted with, I do not have the authority to modify the server application's functionalities. I am subject to the constraints and decisions of the project team. Therefore, implementing this suggestion goes beyond the boundaries of my current responsibilities.


>> In the original (proprietary) application, the dispatching functionality
>
> Dispatching functionality?
>
>> is integrated in the terminal emulator, so it is understandable that
>> pheoebus phoebus wants to keep that structure in the replacement.

In this project to migrate the application server from Unix to Linux, the primary objective was to maintain the stability and functionality of the server component, while the client side (the terminal) underwent an evaluation to explore open-source alternatives to the proprietary terminal emulator solution, all while preserving the existing functionality.


> Well, I'd have to be quit a bit older to have experienced "real"
> terminals like that.  I do remember printers accepting some escape
> sequences to control their functionality, though.
>
> If this application is running on such a terminal, maybe it's time to
> find a more modern und thus more feasible replacement ...  An ancient
> terminal may cease to work eventually and be very difficult to repair
> once it does ...

This application does not run on a physical "real terminal" but on a terminal emulator, which is software running on a Windows-based workstation (Wyse). Currently, there are various hardware options available for this, including proprietary solutions with newer versions of Wyse and proprietary terminal emulators, as well as Android-based devices that can fulfill the task with proprietary emulators.

However, as someone working with Linux and for whom open source and freedom have significance in my profession, I proposed to explore if there might be open-source solutions that can meet this requirement. If there are none available at this time, then so be it, but at least considering this option in our evaluation is an important step for us when it's feasible.

Regards,
Thierry

[toc] | [prev] | [next] | [standalone]

#266329 — Re: Seeking a Terminal Emulator on Debian for "Passthrough" Printing

Hello,

>> People interact with the (remote) application by means of the terminal
>> emulator. Things get sent to/from the printer based on escape sequences
>> initiated by the application.
>>
>> In the original (proprietary) application, the dispatching functionality
>> is integrated in the terminal emulator, so it is understandable that
>> pheoebus phoebus wants to keep that structure in the replacement.

I want to emphasize that your response reflects a clear understanding of our specific needs and the constraints we are facing in this project.

>> I proposed splitting off the "mux" functionality from the terminal
>> emulator functionality, but I fully understand that phoebus phoebus
>> favours the more "conservative" approach.

The use of a terminal emulator in passthrough mode is tied to our existing infrastructure and the way our application was originally designed. Within the scope of the ongoing project, which involves migrating our application from Unix to Linux, it is not within the migration's scope to alter this particular aspect, as it is both critical and sensitive. While I have some leeway to propose technical enhancements and changes, this specific area is off-limits due to its significant impact on a crucial functional aspect from both a business perspective and certain certification standards under which our POS system is certified.

>> By the way -- back then (TM), when terminals were real things, it was
>> not unheard of that they came with an attached printer and some bar
>> code scannery -- all handily multiplexed over the RS-232 (or something
>> more monstruous), orchestrated via intricate escapery.

Yes, that's indeed how it used to work. In our case, the complex escapery you mentioned, for instance, involves the printing process using the ESC/POS printer control language.

>> So the thing is just a natural evolution dating back to The Dinosaurs.

While it may seem unusual and archaic by today's standards, this approach has proven to be an effective solution for addressing the needs of our business. It has been thoughtfully evaluated and retained because it ensures the efficient execution of our application while aligning with our business requirements. Just like certain evolutionary traits persist over time in the process of Darwinism, this approach endures, indicating that the choice isn't as misguided as it may appear.

Regards,
Thierry

[toc] | [prev] | [next] | [standalone]

#266353

[Multipart message — attachments visible in raw view] — view raw

On Sat, Jan 20, 2024 at 08:11:25PM +0000, phoebus phoebus wrote:
> Hello,
> 
[...]

> I want to emphasize that your response reflects a clear understanding of our specific needs and the constraints we are facing in this project.

Thanks to confirming my mental model :-)

[phoebus phoebus]

> Yes, that's indeed how it used to work. In our case, the complex escapery you mentioned, for instance, involves the printing process using the ESC/POS printer control language.
> 
> >> So the thing is just a natural evolution dating back to The Dinosaurs.
> 
> While it may seem unusual and archaic by today's standards, this approach has proven to be an effective solution for addressing the needs of our business. It has been thoughtfully evaluated and retained because it ensures the efficient execution of our application while aligning with our business requirements. Just like certain evolutionary traits persist over time in the process of Darwinism, this approach endures, indicating that the choice isn't as misguided as it may appear.

Don't get me wrong: I'm not criticising your decision process.
I'm long enough in this business to know that technical processes
are evolutory. You change a few things and keep most of the rest
(because that "rest" is so overwhelmingly complex and huge that
you have to).

Which parts to keep and which to change is a tough decision which
IMO has to be taken by the people involved. Things like "disruption"
are, in my view,just empty marketing terms :-)

So no, I don't believe your choice is misguided. Who am I to.

I still believe you'll have an easier (technical) life if you
separate the terminal and the "dispatching" process (now talking
about UNIX processes) -- the latter might be minicom or something
in its class, or something written in C, Python or Perl or whatever
your folks are comfortable with. The fact that both have a separate
address space is hidden in the "Linux box", which may well be a
Raspi or something similar.

But I'm aware that I might well be wrong: if one of us is wrong,
then it's me :-)

Cheers
-- 
t

[toc] | [prev] | [next] | [standalone]

#266327 — Re: Seeking a Terminal Emulator on Debian for "Passthrough" Printing

Hello,

>> I don't understand why you involve a terminal emulator in the process.
>> Do you need to see the data that goes through the COM port displayed
in a terminal (like minicom)?

The existing solution is designed in that manner. We migrated our application from AIX to Linux, and this is the approach that has been historically used. On the client-side, we are exploring if there's an open-source alternative to the proprietary solution that fulfills the necessary functions.

>> I do not understand what you are trying to do at all.  Are you trying
>> to print to a remote printer that has a serial port?  For that,
>> perhaps you could use a printserver with a serial port (if you can
>> find one) or a printserver and an adapter from parallel to serial.

In our POS system, the printer is located at the POS station so that our customers can have their prints quickly and in front of them. Printing from the server in this POS context doesn't make sense for us in this scenario.

>> If you're trying to create a two-way communication between a remote
>> server and a remote client, with the client sending and receiving the
>> data through its COM port (for some weird reason), you could do that
>> over ethernet, using your own protocol or an existing one (maybe even
>> xmpp).

We already utilize the TCP protocol for communication over Ethernet, as the transparent printing flow is encapsulated within the encrypted SSH stream. Depending on the ASCII control codes, the data either displays on the terminal screen or gets printed on the connected printer. So, we are already leveraging Ethernet and TCP for this purpose.

>>Unfortunately, COM ports have become quite rare :(

In the retail environment, COM ports are still quite common, especially in equipment such as POS printers.

Regards,
Thierry

[toc] | [prev] | [next] | [standalone]

#265820

phoebus phoebus wrote: 
> Dear members of the Debian community,
> 
> I am currently on the lookout for a terminal emulator on Debian that can handle controlled printing from a remote server often referred to as "passthrough" printing. Our specific requirement is the ability to select the printing device using a specific method, either the physical COM port or the virtual COM port (emulated by a USB device).
> 
> To be more precise, we want the terminal emulator to transmit data exactly as it is received from a remote server (which is a Linux server) when it attempts to print data through a set of escape sequences to send text in transparent mode. This transmission should be directed to the COM device without any modifications.
> 
> Our application runs on Linux and needs to communicate with a specialized serial printer by sending data directly to it through a terminal emulator on a client machine (with the printer connected to the client machine's serial port).


Would it be correct to say that you don't care about the
"terminal emulator" at all, and merely need a way for the Linux
server to send data over the network to a serial port on a
remote Debian machine which is attached to a printer?

If so, I direct you to the sredird package.

-dsr-

[toc] | [prev] | [next] | [standalone]

#265821

On Fri, 2024-01-12 at 06:08 -0500, Dan Ritter wrote:
> Would it be correct to say that you don't care about the
> "terminal emulator" at all, and merely need a way for the Linux
> server to send data over the network to a serial port on a
> remote Debian machine which is attached to a printer?
> 
> If so, I direct you to the sredird package.

I've always used 'ser2net' for that for of thing, mostly with single-
board computers attached via serial ports on a remote machine. But it
doesn't matter what the device is, it's a dumb pipe to transfer bytes
to/from a serial port on another computer.


-- 
Tixy

[toc] | [prev] | [next] | [standalone]

#265859 — Re: Seeking a Terminal Emulator on Debian for "Passthrough" Printing

Hello,

>> I've always used 'ser2net' for that for of thing, mostly with single-
>> board computers attached via serial ports on a remote machine. But it
>> doesn't matter what the device is, it's a dumb pipe to transfer bytes
>> to/from a serial port on another computer.


Thank you for indicating the use of 'ser2net'. I appreciate your suggestion and the information you provided. However, in our specific infrastructure, the terminal emulator plays a central role due to the way our users access the application and reauthenticate for printing purposes. This interaction is seamless for our users and the terminal emulator serves as a crucial component in managing the communication between the server and the various devices, including the printer and others.

While 'ser2net' may be a valuable tool for certain purposes, it doesn't align with our specific requirements. Nevertheless, I'm grateful for the insight and knowledge you've shared.

Best Regards,
Thierry

[toc] | [prev] | [next] | [standalone]

#265870

[Multipart message — attachments visible in raw view] — view raw

On Sat, Jan 13, 2024 at 01:20:46AM +0000, phoebus phoebus wrote:
> Hello,
> 
> >> I've always used 'ser2net' for that for of thing, mostly with single-
> >> board computers attached via serial ports on a remote machine. But it
> >> doesn't matter what the device is, it's a dumb pipe to transfer bytes
> >> to/from a serial port on another computer.
> 
> 
> Thank you for indicating the use of 'ser2net'. I appreciate your suggestion and the information you provided. However, in our specific infrastructure, the terminal emulator plays a central role due to the way our users access the application and reauthenticate for printing purposes. This interaction is seamless for our users and the terminal emulator serves as a crucial component in managing the communication between the server and the various devices, including the printer and others.
> 
> While 'ser2net' may be a valuable tool for certain purposes, it doesn't align with our specific requirements. Nevertheless, I'm grateful for the insight and knowledge you've shared.

Hi,

to me it's difficult to follow the discussion. Perhaps it is
because traditionally, in UNIX, the TTY functionality and
terminal emulators s are separated entities, whereas in the
DOS/Windows world both functionalities are often conflated.

Have you had a look at minicom? You can give it a PTY at
start (this would take care of the "serial over network"
part, since your end will most probably a PTY) and you can
give it a capture file (which might be what you're looking
for, if I understood correctly).

You run minicom "in" a terminal emulator, which may be
xterm, the linux console or some of those fancy shmancy
things desktop environments come with.

Besides minicom there are other, less featureful, similar
things. They don't count as "terminal emulators" in our
strange unixy world, but they might be the missing piece
you are looking for.

Cheers
-- 
t

[toc] | [prev] | [next] | [standalone]

#265882

On Sat, Jan 13, 2024 at 08:36:57AM +0100, tomas@tuxteam.de wrote:
> On Sat, Jan 13, 2024 at 01:20:46AM +0000, phoebus phoebus wrote:
> > While 'ser2net' may be a valuable tool for certain purposes, it doesn't align with our specific requirements. Nevertheless, I'm grateful for the insight and knowledge you've shared.
> 
> to me it's difficult to follow the discussion. Perhaps it is
> because traditionally, in UNIX, the TTY functionality and
> terminal emulators s are separated entities, whereas in the
> DOS/Windows world both functionalities are often conflated.
> 
> Have you had a look at minicom?

The real problem here is that we're all blind men trying to grasp
the elephant.

Every time someone offers a suggestion, the OP responds with "No, that
won't work, because..." and reveals another piece of the elephant.
Unfortunately, at no time has the OP ever defined the entire problem.

Here's what I've managed to piece together:

1) The OP currently has a working solution using proprietary software
   under Microsoft Windows, but would like an open source solution.

2) The problem involves at least four distinct pieces of equipment:

   * A server, accessed by telnet or by ssh (preferred).
   * A client PC, which accesses the server over the network.
   * A "printer" which is connected to the PC by serial(?) port.
   * Another device, not named, which is connected to the "printer"
     by some unnamed method.

3) Apparently, the client PC is supposed to initiate a connection to
   the server, to run some interactive application.

4) At some point, the application will initiate a communication session
   to the "printer" and to the "other device" THROUGH the "printer",
   all tunneled THROUGH the telnet or ssh session using "bidirectional
   passthrough printing".

5) This "bidirectional passthrough printing" (which I've never heard of)
   apparently allows the server application to perform data transfers
   between itself and the "other device", all while perhaps printing
   literal ink-on-paper on the "printer", all while still allowing
   the interactive application to run seamlessly on the client PC.

I have dealt with terminals with passthrough printers before, but it
was three decades ago, and I've certainly never heard of a printer
communicating *back* to the host over this channel, let alone a printer
having some other devices hanging off of it.  (This makes me think the
"printer" is not actually what we'd call a printer, but of course we
haven't been told any of the details.)

[toc] | [prev] | [next] | [standalone]

#265887

On 14/01/24 03:59, Greg Wooledge wrote:
> I have dealt with terminals with passthrough printers before, but it
> was three decades ago, and I've certainly never heard of a printer
> communicating *back* to the host over this channel

I've also set up passthrough printers on terminals - which were hanging 
off muxes ... it's a serial connection, so bidirectional commumination 
should be fine, and more recent printers would make use of that.

And in fact, when we ran out of mux ports, we even hung an extra 
terminal off the passthrough port, so bidirectional worked :-)

These were physical serial terminals, of course - I don't remember 
having to get a terminal emulator to do this. It also wasn't on Linux - 
some were on SCO, and the others might have been on some kind of 
mainframe - a government department. We weren't involved in that side of it.

Richard

[toc] | [prev] | [next] | [standalone]

#265888 — Re: Seeking a Terminal Emulator on Debian for "Passthrough" Printing

On Sat, 13 Jan 2024 09:59:48 -0500
Greg Wooledge <greg@wooledge.org> wrote:

> The real problem here is that we're all blind men trying to grasp
> the elephant.

A good summary of what we know so far. I suspect that the OP should
question whether it's time to scrap the elephant entirely, and re-think
the problem de novo. Remember that an elephant is a horse designed by a
committee.

-- 
Does anybody read signatures any more?

https://charlescurley.com
https://charlescurley.com/blog/

[toc] | [prev] | [next] | [standalone]

#265890

[Multipart message — attachments visible in raw view] — view raw

On Sat, Jan 13, 2024 at 08:55:22AM -0700, Charles Curley wrote:
> On Sat, 13 Jan 2024 09:59:48 -0500
> Greg Wooledge <greg@wooledge.org> wrote:
> 
> > The real problem here is that we're all blind men trying to grasp
> > the elephant.
> 
> A good summary of what we know so far. I suspect that the OP should
> question whether it's time to scrap the elephant entirely, and re-think
> the problem de novo. Remember that an elephant is a horse designed by a
> committee.

The elephant would disagree.

Ported back from the metaphor this means that there are two sides to
this story and we might learn something new by trying to take up the
OP's point of view.

My guess was that the functionality exists in the Unix-y world, but the
building blocks might be called differently.

See, back then, Unix-y was "the mainframe" and PCs often played the
terminals (reflected on the serial ports, back then when PCs had some:
they have a terminal's gender).

This was what led me to minicom (and friends): what did one use back
then to talk to a modem?

Sadly the OP hasn't had a look into that, so I won't know ;-)

(To be fair: so many proposals to choose from, the OP has to prune
things to come to an end).

Cheers
-- 
t

[toc] | [prev] | [next] | [standalone]

#265899

On 1/13/24 11:10, tomas@tuxteam.de wrote:
> On Sat, Jan 13, 2024 at 08:55:22AM -0700, Charles Curley wrote:
>> On Sat, 13 Jan 2024 09:59:48 -0500
>> Greg Wooledge <greg@wooledge.org> wrote:
>>
>>> The real problem here is that we're all blind men trying to grasp
>>> the elephant.
>>
>> A good summary of what we know so far. I suspect that the OP should
>> question whether it's time to scrap the elephant entirely, and re-think
>> the problem de novo. Remember that an elephant is a horse designed by a
>> committee.
> 
> The elephant would disagree.
> 
> Ported back from the metaphor this means that there are two sides to
> this story and we might learn something new by trying to take up the
> OP's point of view.
> 
> My guess was that the functionality exists in the Unix-y world, but the
> building blocks might be called differently.
> 
> See, back then, Unix-y was "the mainframe" and PCs often played the
> terminals (reflected on the serial ports, back then when PCs had some:
> they have a terminal's gender).
> 
> This was what led me to minicom (and friends): what did one use back
> then to talk to a modem?
> 
I go back even further than that, Tomas, on a color computer I used 
either supercom or vt220, a terminal emulator that I made out of Brian 
Marquettes vt100, middle to later 80's time. The color computers had an 
aftermarket os called os9, was a microware supplied mini-unix that ran 
on a machine with only 64k of memory, 50+ years ago.

Anybody here remember that?

The 6809 cpu in the coco was first with program counter independant 
code, put it anyplace in memory and it just ran, so we showed the pc's 
of the day a much shorter, faster way home. But I've Been Moved chose 
intel 8088's and dos and had a bigger advertising budget.  That and 
nobody ever got fired for buying IBM.

> Sadly the OP hasn't had a look into that, so I won't know ;-)
> 
> (To be fair: so many proposals to choose from, the OP has to prune
> things to come to an end).
> 
> Cheers

Cheers, Gene Heskett.
-- 
"There are four boxes to be used in defense of liberty:
  soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
  - Louis D. Brandeis

[toc] | [prev] | [next] | [standalone]

#265948

[Multipart message — attachments visible in raw view] — view raw

On Sat, Jan 13, 2024 at 1:14 PM gene heskett <gheskett@shentel.net> wrote:

> > The 6809 cpu in the coco was first with program counter independant
> code, put it anyplace in memory and it just ran, so we showed the pc's
> of the day a much shorter, faster way home. But I've Been Moved chose
> intel 8088's and dos and had a bigger advertising budget.  That and
> nobody ever got fired for buying IBM.


After writing 8080 assembly code the 6809 was a breath of fresh air. Then
the 68000, I think the first microprocessor Unix was ported to.

>

[toc] | [prev] | [next] | [standalone]

#265891 — Re: Seeking a Terminal Emulator on Debian for "Passthrough" Printing

Charles Curley <charlescurley@charlescurley.com> wrote:
> On Sat, 13 Jan 2024 09:59:48 -0500
> Greg Wooledge <greg@wooledge.org> wrote:
> 
> > The real problem here is that we're all blind men trying to grasp
> > the elephant.  
> 
> A good summary of what we know so far. I suspect that the OP should
> question whether it's time to scrap the elephant entirely, and
> re-think the problem de novo. Remember that an elephant is a horse
> designed by a committee.

AIUI a camel is a horse designed by committee (possibly said by
Issigonis).

An elephant is supposedly a mouse designed by committee (particularly
an American committee IMHO :)

[toc] | [prev] | [next] | [standalone]

#265906 — Re: Seeking a Terminal Emulator on Debian for "Passthrough" Printing

On Sat, 13 Jan 2024 21:32:44 +0000 (UTC)
phoebus phoebus <frphoebus@yahoo.fr> wrote:

> I have a client workstation with a proprietary terminal emulator
> running on Windows. This PC is connected to a POS printer via a COM
> serial port. The client workstation along with the printer and other
> connected devices, forms the client-side of our Point of Sale (POS)
> system.

…

> The printer model is a Thermal Line Dot Printing type and it supports
> the ESC/POS command system, created by Epson, which provides
> efficient and functional commands for communication with the printer.
> For more information on ESC/POS, please refer to this site:
> https://download4.epson.biz/sec_pubs/pos/reference_en/escpos/index.html

This article was very helpful.

> Our objective is to explore open-source solutions for this
> configuration as we aim to replace the proprietary software.

I take it that by "the proprietary software" you mean the proprietary
terminal emulator running on the client PC.

One thing you might be able to do quickly is establish an SSH tunnel
between the PC and the server, then route the proprietary terminal
emulator telnet traffic through the tunnel. That, at least, will get
you a more secure connection between the PC and the server.

If I understand things correctly, the server sends all sorts of
information to the proprietary terminal emulator. Most of that gets
displayed on the emulator. But, given one VT escape code, the emulator
sends the subsequent data off to the printer, until it gets the other
VT escape code. The printer may then return a response.

If that understanding is correct, I suggest you grab an existing open
source terminal program that supports VT escape codes:

1) Modify how it handles those two escape codes.

2) Modify it to listen to the printer for responses, encode those
appropriately, and ship them to the server.

I haven't worked with VT escape sequences in decades. If I recall
correctly, some escape sequences cause the terminal to send information
back to the server. In that case, you may need to synchronize return
information from the printer with other return information.

-- 
Does anybody read signatures any more?

https://charlescurley.com
https://charlescurley.com/blog/

[toc] | [prev] | [next] | [standalone]

#265909

On Sun, Jan 14, 2024 at 12:31:57AM +0000, phoebus phoebus wrote:
> Yes, that's the basic concept, but it's even more intricate. The application continuously monitors what it receives from the terminal with regular interval checks (in milliseconds) and makes decisions based on rules. These decisions include sending commands to the printer, analyzing the responses, taking user actions, and even restricting user input in certain menu or submenu areas of the screen. However, I have a high-level understanding of this process as I'm not part of the application development team to delve into the finer details.

More elephant parts. *shakes head*

At this point, I don't think you're talking to the right mailing list.
We're just Debian users.  Clearly we don't know of any terminal
emulators that do what you want.  (I assume you've already looked at
kermit, and found it lacking... yes?  OK then.)

If you need new features to be added to an existing Free terminal
emulator, or even to have a whole new one developed from the ground up,
this is not the mailing list for that.  Find the project that comes
closest to your needs, and talk to the developers of that project.

[toc] | [prev] | [next] | [standalone]

#265929 — Re: Seeking a Terminal Emulator on Debian for "Passthrough" Printing

phoebus phoebus <frphoebus@yahoo.fr> wrote:
> Hello,
> 
> >> Clearly we don't know of any terminal
> >> emulators that do what you want.  (I assume you've already looked
> >> at kermit, and found it lacking... yes?  OK then.)  
> 
> I want to express my sincere gratitude for pointing me to this
> project. I wasn't familiar with the Kermit terminal emulator before
> but after looking at their website, I believe that Kermit 95's
> feature set should address my needs. The features such as:
>  * Copy/paste, print, searching, and bookmarks in the scrollback
> buffer
>  * Host-directed and local printing
>  * Versatile printer control, including bidirectional printers and
> built-in Text/PostScript conversion seem to align with my
> requirements.
> 
> I also explored E-Kermit (Kermit for Embedding) since we were asked
> if there was an emulator that could perform these functions in an
> embedded environment. However, based on what it does not do, it
> doesn't seem to be the solution I was hoping for. Regarding the
> purely Linux/Unix C-Kermit, it appears to be less feature-rich
> compared to Kermit 95, so it may not be the best fit for my
> requirements.

You don't mention it, but did you look at CKW (C-Kermit 10.0 for
Microsoft Windows)?

In any event it seems it might be worth your time to contact the kermit
developers as well as the putty developers.

[toc] | [prev] | [next] | [standalone]

#265913

> Thank you for your suggestion. As I mentioned earlier, our development team
> primarily focuses on the server-side application and is not competent to
> modify the client-side emulator, which is crucial in our case. They have
> already examined the PuTTY source code and confirmed that this type of
> development is beyond their expertise.

The description of what the terminal emulator is expected to do is
reasonably simple that anyone who has a bit of familiarity with the
implementation of a terminal emulator should be able to add such
a feature fairly quickly.

Admittedly, the bidirectional part means there can be tricky issue when
the user hits keys at the same time as the printer sends information
back, but I'd suggest you try and contact various terminal emulator
teams to see if someone would be interested (I'm thinking of people who
worked on PuTTY or derivatives (Le PuTTY and TuTTY seem quite relevant,
for example), or things like libvterm, ...).  Even if the corresponding
doesn't necessarily make it upstream, it's probably a better investment
than paying for the license of a proprietary product which will force
you into the same problem again a few years down the road.


        Stefan

[toc] | [prev] | [next] | [standalone]

#265914

[Multipart message — attachments visible in raw view] — view raw

On Sat, Jan 13, 2024 at 09:32:44PM +0000, phoebus phoebus wrote:
> Hello,
> 
> I understand that the situation may seem complex and i apologize if my previous messages did not provide a clear overview of the problem. Allow me to summarize our current situation.
> In this response, I will incorporate the various comments made by Greg, Charles Tomas, and incorporate a significant portion of Greg's excellent summary.

[...]

Thanks for the detailed explanation -- and no need to apologize.

Elephants are complex beasts :-)

This was to me at least a delightful example of trying to come to
a common understanding "Ah, yes, you're right: this feels like a
trunk!". Thank you for your patience, too.

One viable approach is the one proposed by Stefan et al (modify an
existing terminal emulator). I'd tend to separate concerns and just
write the application part as a separate process accepting a bidi
connection to SSH, one to a terminal emulator, and one to the serial
port (OK, some error and diagnostic logging too). The classical
thing built around a select() loop, with some extended state
automaton in it.

And this is where I disagree with Greg (what doesn't happen very
often). Some of us do love elephants :-)

Cheers
-- 
t

[toc] | [prev] | [next] | [standalone]

Page 3 of 4 — ← Prev page 1 2 [3] 4  Next page →

Back to top | Article view | linux.debian.user

csiph-web