In the IPP world - what keyword for "Tractor"

[RolandHughes]

I'm looking at 6.3.1.17 in this document. If I'm looking at the wrong spec please point me to correct spec.
Updating some legacy PPD based code which has this enum.
enum InputSlotId { Upper, Lower, Middle, Manual, Envelope, EnvelopeManual, Auto, Tractor, SmallFormat, LargeFormat, LargeCapacity, Cassette, FormSource, MaxPageSource, // Deprecated, kept for compatibility to QPrinter CustomInputSlot, LastInputSlot = CustomInputSlot, OnlyOne = Upper };

Contrary to what they younger generation(s) may wish to believe, tractor feed printers are still in wide use. Newegg even has a lot of them. There are business/legal requirements where one must print on pre-printed multi-part forms rather than multiple copies of single part laser/ink-jet printed forms. Weigh tickets, customs forms, even the loved-hated 1099. Yes, many companies and people use the laser versions, but they hold their breath hoping nobody they paid cheats on their taxes landing them in an audit. The multi-part holds up better. Actually good impact printer explanation found here.

At any rate, is there a way in this new IPP universe to determine a tractor feed printer? "main" isn't good enough because my HP OfficeJet returns "main." Sorry I don't have an older dot-matrix to test with. Got rid of my last one two years ago.

Are tractor feed printers supposed to return "main-roll"?

Identifying Tractor/Continuous feed is important because there are situations where one needs to back up the form. You can't do that with ink-jet and laser (at least I don't know how) but you can with tractor feed and drum/wheel/friction feed printers.

Thanks in advance.

[tillkamppeter]

@michaelrsweet could you help here?

[michaelrsweet]

@RolandHughes So from an IPP/SNMP MIB standpoint, “tractor” is an attribute/property of the paper path but doesn’t identify a media source. “main” is the correct source/keyword for the primary (tractor) feed, with “alternate” if you had a secondary feed (i.e., a printer with two tractor feeds).

The “main-roll” and “alternate-roll” sources are for un-cut continuous media (think photo media or labels on a continuous backing medium) while tractor fed media is almost always fanfold perforated at sheet boundaries.

[RolandHughes]

@michaelrsweet Thank you for your response. Is there a "paper path" tag (I'm not in my office now) where I can pull "tractor" and "friction" from? Most of the tractor fed printers made in the last 40 years (for PC use) provide both "main" tractor feed and "alternate" friction feed. My OfficeJet Pro (from the 2012-2013 era) also has those two paper sources yet it feeds from a tray without a manual feed option that I've ever found.

Possibly better question about same thing. When Apple shafted the known universe switching from stable, mature, well supported PostScript to PDF without warning did they also well and truly shaft "live logging?" This is the required-by-law real-time logging to paper where the ability to backup form to "header" and print ending time-stamp/event-count on same line with beginning pair for page. Both the header and footer have the same range pair so when put into binders

one can quickly fan through to find the page with the event(s) in question.

Been quite a while since I've had to write code like that but I know it is still a requirement. Due to the extremely high failure rate of magnetic media (in the early days) and its extreme succeptability of EMP (Electro Magnetic Pulse) that may exist even today with SSD logging to paper first, real-time, was codified. Many of these Decwriter III (LA120) printer-terminals are still in use for the task.

Serial paper terminal from 1970s but built like a tank primarily for this and system console purposes which is why they are still around.

It's not the same question but tied to it. How does the new new new IPP universe handle serial connection bi-directional ASCII printers built prior to Unix getting into the wild? The "modern" dot-matrix sold today have network add-ons and support IPP out of the box. Those printers also won't survive in the industrial/scientific settings where the LA36 and LA120 printers are still in use. Can someone point me to a documentation link on how IPP Cups handles physically connected dumb printers?

Yes, I'm old. This was current tech when I started in the field.

https://bitsavers.trailing-edge.com/magazines/RSTS_Professional/RSTS_Professional_V03_N01_198103.pdf

Technically I started on an 11/70 which came out before these.

Thanks

[michaelrsweet]

@RolandHughes I’m not going to get into the debate over what format/language is better.

WRT the paper path of a typical impact printer, the choice of friction or tractor feed is normally accomplished via a lever on the feed mechanism. From the standpoint of the printer, there is either paper there or not, and the printer does not report which feed mechanism is in use, nor does it provide a PDL command to set or require a particular feed mechanism. Thus, from the standpoint of a driver/printer application for an impact printer, the same ‘main’ media-source value is used. The media-type attribute can be used to specify the type of media (sheet or fanfold media of some variety) but even that information is not passed to the printer since there is no command for it.

In short, the driver/printer application should just report a single media-source (‘main’), a single media-type (‘stationery’ for plain paper), and the appropriate media sizes that the printer supports.

WRT logging information on printed pages, IPP relegates that to the client software preparing the content for pages that are sent to the printer. Even the native PDL of these printers can’t do it for you - that is a function of the software preparing the data that is send to the printer.

[RolandHughes]

@michaelrsweet

Oh, you misunderstand.

These printers get opened up as raw devices because they all support VT-100 or ASCII escape sequences to position the print head on the page. You can roll it all the way up or down.

In the world of stupid-is-as-stupid-does, some Linux distros will identify and automatically set up a print queue for said printers. The real-time logging applications running on Linux have to identify which printers CUPS knows about, then disable the queue or force CUPS to forget.

In order to use the direct connected printer for real-time logging, it has to be tractor feed fan fold. It cannot be friction feed cut sheet.

Preparing the content a page at a time is not a legal option for these applications. That is viewed as a commercial airliner black box that only stores data once every 5 minutes. It will never have what you need after the crash.

Thanks

[michaelrsweet]

OK, I guess I just don’t understand why you care what CUPS thinks about these printers or how to support tractor/friction feed with CUPS if you aren’t using CUPS to print?

If you have a specific application that requires functionality not supported by CUPS (and this is definitely not functionality supported by CUPS), then it is up to you to provide that functionality, not CUPS. And given this is for “real time logging” then you probably don’t want desktop/server services like CUPS running anyways…

[RolandHughes]

For that (real-time logging) class of application nobody would ever be using CUPS to print. The application itself needs to be able to identify if CUPS has a print queue for that particular tractor fed device and kill the queue. Just finding the COM port is not good enough because the COM port could be in RS-485 or one of the other multi-drop modes with multiple devices connected to it.

For all other situations, especially the printing of source code for a listing, CUPS would be in use. One definitely wants to bypass PDF because that sends the printer into "graphics" mode which is the speed of molases (sp?) in the dead of winter. One just wants to dump the raw ASCII/UTF8 file to the device and let it print with its default 10 or 12 CPI setting.

This question is fallout from a really poorly designed enum that I posted in my first message and for some reason got mushified on here so it doesn't look like an enum. That enum got created during the era of OS/2 and Windows 3.x then Linux got shoe-horned into it. Adding insult to injury, in two different classes they had differently named enums trying to keep track of the same thing with comments about keeping them in sync instead of doing the right thing and moving one enum to a common header file so there wouldn't be a synchronization issue.

Thank you for the assistance. I am sorry for any confusion. This is a case of Rollie trying to "fix" something that was done poorly decades ago and has been ignored ever since. No, I'm not the original sinner. I'm just the one starting this and realizing some Linux distro is going to finally make the jump to CUPS 3.x sometime soon. I even took a look at a much later version of Qt 5.x available with the same license and they still have this poorly written 1990s code. The day Debian/Ubuntu/whatever jumps to 3.x after finally admitting they can't cling to 2.4.x forever, nothing written with Qt will be able to print unless they are doing a SYSTEM() call to LP on the command line.

Since LsCs is a "new" fork, I wanted to fix CUPS support before replacing the graphics layer.

When it comes to dot matrix and other impact printers I also wanted it to be much less painful to develop for both use cases.

1. real-time logging after identifying what, if anything, to kill in CUPS.
2. just dumping a source listing (or other text file) to the printer without having to have a PDF anywhere in the mix. Raw text should still have a method of bypasing the new world order. When set to graphics mode to print the glyphs of a PDF one could enroll in college then graduate before a document of any decent length finished printing.

Thanks again for your assistance.