On Sun, Jan 21, 2024 at 10:44:35PM +0000, phoebus phoebus wrote:
A filter in between that in response to escape-code-1 starts sending data to the serial port instead of the terminal application and switches back to the terminal application on receiving of escape-code-2. Development of a transparent and responsive intermediate filter to ensure a smooth user experience. This filter must handle incoming and outgoing commands without disruption.
This is old, old, old tech. The suggestion early on to use screen was one reasonable answer, xterm is another. Solutions exist for this, the main problem is dusting off documentation old enough to be aware this functionality exists. (As seen by so many of the responses here, which are apparently unaware that at one time an actual terminal--the hardware device with a screen and a keyboard that a "terminal emulater" emulates--had a serial connection to a server and could also have a second serial connection to a printer, and escape sequences were used to switch the server output from screen to printer and back.) This isn't functionality that has to be developed, it was written long ago and simply isn't used much anymore. You'll have to find old code, because newer terminal emulators don't bother implementing this since not many people are asking for it (and those that do, can simply use the old code and probably aren't as interested in compositor transparency effects).
Waiting for Returns: The filter remains attentive to returns of information coming from the serial printer. These returns may include information about the printing status, errors, or other relevant data.
This is where things go off the rails--"other...data". Most of the unix terminal emulators use the ANSI escape sequences which, as far as I know, had unidirectional printing. The datastream coming from the server had escape sequences to change output from screen to printer, but the printer had no way to interrupt that and talk back to the server. The documentation about "passthrough printing" you've referenced several times *does not* describe any capability for doing this. (In fact, the capability described involves a pipe and can't possibly be bidirectional.) There were escape sequences the server could use to query specific things about the printer (like "printer ready"; and, as far as I know, that was it). I have no idea whether any of the terminal emulators do much or anything with the status sequence, as they mostly expect to pipe output and aren't actually written to directly connect to a serial printer and check its status lines. (In an actual terminal/printer situation the query would report the status of DTR or CTS or whatever the specific hardware was using to communicate printer status.) In theory it would be a relatively trivial addition to tie the "printer status" escape code to something that queries printer status, if it's possible to do so and it's not already implemented in a terminal emulator that does support printing. But that's still not communication of arbitrary data.
Now VT100 wasn't the only terminal out there. For example, Wyse was a big name in terminals, and they used a completely different set of escape codes. One of theirs enabled a bidirectional mode, used for things like connecting an optical barcode scanner at a library checkout desk to the minicomputer in the back. I don't know of many open source wyse emulators, and none that implement this. IBM had their own proprietary terminals and control mechanisms, like the 3270 or 5250, with another set of capabilities. Again, I don't know of many open source emulators, and those that I am aware of had limited functionality. If this is the sort of thing you're talking about, you'd get much further searching for information about wyse terminal emulators (or whatever terminal language your software uses--there were far more than DEC VT or Wyse or IBM) rather than an open ended question about printing. (In reality, the bidirectional peripheral control might have been lumped into the printer escape sequences in terminal manuals and might have connected via the port labeled "printer", but wasn't ever really about printing because printing is unidirectional. This is obviously confusing to people not aware of the jargon.) I would not expect to find much open source software in this space because it's very niche and basically requires expensive proprietary software to test against if the goal is to run expensive proprietary software correctly. This is literally tech from the 1970s, so without the right keywords you're going to mostly find unrelated but newer and higher-ranked stuff that's not what you're looking for.
