On Thu 18 Jan 2024 at 12:28:58 (+0100), hw wrote: > On Wed, 2024-01-17 at 23:08 -0600, David Wright wrote: > > On Tue 16 Jan 2024 at 11:47:53 (+0100), hw wrote: > > > On Mon, 2024-01-15 at 20:32 +0100, to...@tuxteam.de wrote: > > > > On Mon, Jan 15, 2024 at 08:08:36PM +0100, hw wrote: > > > > > > > > > > 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? > > > > > > > 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. > > > > > > I don't understand. > > > > > > > I proposed splitting off the "mux" functionality from the terminal > > > > emulator functionality, but I fully understand that phoebus phoebus > > > > favours the more "conservative" approach. > > > > > > > > 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. > > > > > > > > So the thing is just a natural evolution dating back to The Dinosaurs. > > > > > > 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 ... > > > > It isn't running on a terminal: tomas wrote "back then (TM), when > > terminals were real things". > > > > It's running on a Windows PC. Walk into many a shop and you can see > > the sort of setup, a PC and screen with a barcode scanner, keyboard, > > credit card reader, receipt printer, etc, all hanging off it. The > > server might be in an office, or perhaps at HQ or in the cloud. > > All perfectly normal. The import of the thread is Windows → Linux. > > Ok, and what's the problem? That the server wants to print to the > printer? That the application sends data to the "screen" (a terminal > emulator) instead of sending it to the printer? That it is necessary > to see the printer data displayed in a terminal emulator?
AIUI, put simply, bidirectional passthrough printing by the server. I spent a couple of decades writing software that output to a variety of dot-matrix and inkjet printers, but never had to bother about the printer answering back. If the printer ran out of paper, users had to recover their printout by replaying the spool file. That was a deliberate choice, as any peripheral failures like that were unimportant. Likewise networked output through NFS: no feedback as to whether the server was up or not. From a position of ignorance, I would have thought that serial pass-through printing is necessarily bidirectional, if only for flow-control, but UARTs can do that in hardware with RTS/CTS. So it's unlikely that that's enough to support what the OP wants, which is probably things like ink/paper supply or, when there's a cash drawer installed, drawer open/closed; typical POS stuff. And that's without taking into account the peripherals mentioned above. With free software, it might not be too costly to try out suggestions like Putty. But I speak as someone with a university background, not a company one. We might have had a bit more freedom to mess around, and even mess up. And a small base of sophisticated users rather than a large number of likely unskilled users. Cheers, David.
