Printing

My takeaway is just don’t compress BASIC programs.

+1

Ditto with squeezed modules/apps. It’s just annoying when you need to look inside for something (you know, nerd issues).
The load speed increase will be negligible for the usual module, unless people are still using floppies or Econet these days; and any disc space saved will be far less than the disc space allocated in either case due to the granularity of the map.

With the exception of a compressed ROM image or those GCC programs that run to ten megabytes, is there any valid reason for squeezing stuff these days?

I’ve just been looking through RFC8010, the corresponding IANA assignments, and some IPP PWG documents, trying to find out how restricting duplexing is handled. I can’t find any reference to duplexing being restricted by media source or media weight. What I can find is a printer state reason “media-path-cannot-duplex-media-selected”. This suggests to me that a printer can’t tell its host in advance that it can only duplex selectively, it can only put up an error message when the user has sent a job that it can’t duplex.

It’s imperfect, but it looks to me to be good enough to fulfil over 99.99% of all RISC OS printing jobs.

Some duplexers in small printers work by rolling the media up. e.g. a desktop inkjet photo printer. That’ll happily flip a piece of 80gsm from the paper tray, but it’s not going to cope with a piece of 300gsm from the manual feed.

Others pull the sheet back down to the paper tray feed, but this can involve the same tight turns that the paper tray is subject to, so again has similar weight limits to that of the paper tray. e.g. LaserJet:

In larger workflow print solutions there can be a dummy cart or second output tray in which a sheet can do a 3-point turn.

A pertinent video which, if you don’t want to find the “I’m not paying you” button, talks about this beast. Duplex path is left of centre at the bottom:

But it is often the case that manual feed implies no auto-duplex.

Thank you for the interesting references.

The video also points out that duplexing is length-limited, but do they really provide bins for media up to 1260mm long?

But I still don’t see any way to get information from the IPP data to proactively prevent users from submitting a job, requesting duplexing that the machine cannot fulfil. All I can see is that such a request would result in an error message, which IPPTrnspt would report to the user.

So I still think that it is sensible to treat media source and duplexing as independent of each other.

Can you see a way to get the information we need, or can you see a better solution?

Some duplexers in small printers work by rolling the media up. e.g. a desktop inkjet photo printer.

The big laser photocopier printer fax email thing at work is a bit like that, it half spits the paper out into the upper output tray only to suck it back in again and print the other side.

<whisper>One day I was in a hurry and forget it was duplex copy, so when I saw the paper come out I grabbed it. Bloody thing promptly crashed, a half drawn error message on the screen and completely unresponsive. Luckily it was management lunch break so nobody noticed I switched it off and back on again. And my thirty second copy? Took four minutes thanks to all the self checks at startup. 🤦🏻‍♀️</whisper>

The video also points out that duplexing is length-limited, but do they really provide bins for media up to 1260mm long?

SRA0 is 1280mm so that’s a standard for large-format presses. But most printing is SRA2, and the Xerox I pictured above is SRA3. However, the limiting factor is the width. Digital devices can generally cope with surprisingly long media because high resolution imagers like this do not use a frame buffer – they don’t image a “page” and then print it. Instead the PDL is processed into a display list (like a DrawFile really) and then it is rendered in stripes across the sheet.

In fact there are multiple display lists so that multiple stripes can be rendered on different cores simultaneously, or on the very fast machines, on different nodes of a render farm and piped to the output device Just In Time.

Some devices of this form support roll media. For example the devices that produce your electricity or phone bills (if you still get those on paper) – the speed of those things isn’t measured in pages per minute, but in metres per second.

I still think that it is sensible to treat media source and duplexing as independent of each other.

I’m not disagreeing. I agree. And !Printers+ has both Bin and Feed which would allow exactly that abstraction.

Can you see a way to get the information we need, or can you see a better solution?

No I can’t. The device interrogation capability is highly dependent upon PDL, connection medium and manufacturer. For example HP PCL devices use PJL, which is effectively an interrogation language separate from PDF, PCL, PS or whatever PDL you’re sending the page in.

My specialism is in the printer internals. How it talks to the outside world and what it does in its UI is the OEM “skin” and not shared with us poor code monkeys.

@Nemo posted a nice photo of some Xerox printers

especially when you have this kind of thing:
…
[I’ve had very good experiences with Xerox SRA3s BTW, highly recommended, and not just because my code may be in them]

That’s very similar to the model I had, ‘DocuCentre [I forget the number]’ . A great machine that did sterling work, as long as the service contract was in place as it needed regular visits from the Xerox engineers – especially for the booklet maker.

What code did you provide was it in the RIP or the machine itself? Mine had the Fiery (bustle) RIP.

And the one in the background, the larger press type one. I was in the process of buying on of those in 2007 (again, I forget which model), but it was just as the credit-crunch happened and Xerox Finance had got into some trouble with some dodgey dealing and all finance was susspended. I was just at the point of signing the agreement papers when they stopped the deal. At the time I was annoyed with them, but it was atually a blessing in disguise as I was about to sign for a 98,000 pound machine just as the economy struggled and business got tough.

The one I had was rated for 350gsm stock, but would happily feed 400gsm (SRA3). Although it couldn’t duplex that weight – you had to manually re-feed it through again.

p.s. I always wanted a HP Idigo, but could never aford the 250,000 GBP price tag.

Gavin guessed

the Fiery RIP

Not that one (though Xerox was a customer).

HP Indigo

That one!

I’m struggling to know how to move forward. I’ve written two Printer Dumper modules, for PWG-Raster and Uniraster formats; I’ve written an app that finds entities supporting IPP in the LAN, and interrogates them for information; and I’ve written an IPP transpprt app, to package up and transport a PWG-Raster or Uniraster Printout file to a chosen IPP device.

So far, so good. But it doesn’t hang together like the Printer Manager app does. In particular, it doesn’t handle duplexing or feed selection at all.

I can’t see how selected duplex or feed selection values are passed through to PDumper modules. This is the only logical place for the information – it’s embedded in the page headers within the Printout files. I imagine (but I don’t know) that Printer Manager was written in the days when impact and inkjet printers didn’t have duplexing or more than one feed; LaserJet printers would be controlled by a separate job control language, albeit through the same communication channel; and PostScript printers merely needed a prologue, which would be dead easy to send.

Printer Definition Files seem to me to be the logical place to keep information, read from the printer, about available feeds and duplexing. There are separate apps (e.g. GPSetup in Gutenprint) to make settings for a printer; but how is the PrDefn file passed to the setup app, and how does it pass its choices back to Printer Manager, and how (repeating the question from above) is this passed to the dumper module?

A setup app should not be completely generic; it should only offer choices that exist for the selected printer.

I can see how I would solve this by rewriting Printer Manager, but that’s a daunting task because of its terseness and lack of documentation. And if I were to rewrite it, the IPP transport app would be built into it.

Suggestions welcome!

Nemo, do you have one or more printers that support IPP and have multiple feed sources? If you do, I’d like to send you my IPP finder app, so you can send me what the printer(s) says(s).

Dave said

I can’t see how selected duplex or feed selection values are passed through to PDumper modules.

The !Printers front end sets the PDumper##$Extra SysVar, which the PDumper typically squirts straight into the start of the file (this isn’t the best strategy as some PDLs require a reset or config sequence first, though this could be mitigated where both Bins and Feeds are supported, as Bins seems to be included first, so all Bin options could include the start sequence… all unnecessarily hamstrung by !Printers’ simplistic Basic string handling of course).

However, as I wrote recently that code works in the LJ support library but seems to have rotted (in my copy of !Printers+) for DP support. I have patched it in and it works.

Printer Definition Files seem to me to be the logical place to keep information, read from the printer, about available feeds and duplexing

And they do contain that information, but in the form of what you might call a “Group Name” – i.e. this kind of feeds, that set of bins. That “Group Name” selects a subdirectory of !Printers.##.Feeds/Bins from which a set of files are read… these contain the PDL strings that are ultimately included in the output file.

So the model is that Feeds and Bins are expected to be pretty standard for a class of printer. I don’t see why it would be any different for bitimage dump command strings, but they certainly are in the PDef. It ought to all be one place really. But it ain’t (even when it is wired up).

do you have one or more printers

I have one that ought to support IPP, in that I regularly print to it wirelessly from various Android and Apple portable devices.

You should have email. The address I sent it to is the one you registered here.

I’m going to be very busy all weekend and Monday, but I’ll get back to you. And if I don’t, shout.

I’ve just found how to get job state back from an IPP host, so it can in principle be updated on screen until finished. Implementation over multiple jobs is another matter.

Well done!

Is there any documentation of the internal operation of the printing system?

Even looking at the unsqueezed BASIC isn’t very revealing. No comments, rather opaque.

Clearly I’d be interested in anything. In particular, I’d like docs for the (xx).Resources.Support prog (where (xx) is dp, ps, etc.)

I notice that use is made of Wimp message &8014B, which is not documented in the PRMs.

I notice that use is made of Wimp message &8014B

Interesting…

https://gitlab.riscosopen.org/RiscOS/Sources/Printing/PrinterManager/-/blob/master/Doc/Messages#L141

Later:

Aha, I think I’ve found it.
https://gitlab.riscosopen.org/RiscOS/Sources/Printing/PrinterManager/-/blob/master/Doc/RO4Additions#L184

Very useful, given there’s loads of possible message numbers, that somebody ignored the “won’t reuse” note and reused this message number. Bravo.

The joy of wading through mostly obsolete and mostly contradictory notes and information. 😪

Right, back to Netflix…

Sort of relevant – I recently tried to mail-merge onto A5 paper. Normally I would define two A5 pages on a sheet of A4, and that works. With real A5 paper, I almost completely failed.

The two printers are both HP, M277 and P3015. I’m usine PS3 and the Duplex Driver. The first problem is that if I create a paper definition for A5 and call it A5, one printer prints an error page complaining about “unknown paper size A5” or something along those lines. The other ignores the entire output.

I’ve noticed before a strange dependency on the name of the paper definition – if it starts with something that could be the name of a paper size, and that isn’t A4, it barfs. It doesn’t matter whether I’ve set the printer menu to have A5 in the tray for example, it still only tries to print if the name starts A4, or something else entirely, like Generic. Why is !Printers even passine the name of the paper definition?

The second problem was that it required three button presses on the control panel per sheet printed.

In the end I had to define the document as A4 landscape, define an A5 portrait frame in the top, and set the printer to think the paper was A4. On the P3015 this worked. It failed utterly on the M277.

I almost got desperate enough to recreate the mail-merge document in Word. (Using mail-merge in Word fits my definition of desperate perfectly.)

The two printers are both HP, M277 and P3015. I’m usine PS3 and the Duplex Driver. The first problem is that if I create a paper definition for A5 and call it A5, one printer prints an error page complaining about “unknown paper size A5” or something along those lines. The other ignores the entire output.

I’ve noticed before a strange dependency on the name of the paper definition – if it starts with something that could be the name of a paper size, and that isn’t A4, it barfs. It doesn’t matter whether I’ve set the printer menu to have A5 in the tray for example, it still only tries to print if the name starts A4, or something else entirely, like Generic. Why is !Printers even passine the name of the paper definition?

Are you sure you’re using PS3, and not PS2?

What you’re describing is what the PS2 drivers do by default, and PS2Paper was written in an attempt to make things work as well as they can be expected to in the circumstances.

The PS3 driver does paper sizes correctly, as far as I know.

I watched somebody at work earlier wrestling with trying to get their magical Microsoft solution and their magical printing solution to handle a DL ¹ envelope, and correctly print it sideways (so it’s the right way up on the envelope).

She told me the way she ends up doing it is just writing it as a Word document and printing to A4, shoving the envelope in the tray with the flap overlapping a blank piece of paper (so it doesn’t fault on paper jam).

I told her that I’m nearly fifty and printers were doing that sort of nonsense when I was a teenager. Hell, the LaserJet II I knew back then used to eat envelopes.
It’s rather depressing that, in 35-40 years, about the only thing that has changed ² is that a good number of printers now understand 15×10 photo pages.

But, really, if it’s not a photo print, an A4 page or Letter ³ or Legal ⁴ then it’s like you’re on your own, good luck, you’ll need it.

¹ That’s the one that’s an A4 page folded into thirds. You’ll be familiar with this as it’s a common format for bills, back statements, etc.

² Some hyperbole – we do have colour, printers that can scan, photo quality output, WiFi, IPP driverless connectivity, etc etc; but woe betide anybody wanting to use weird page sizes like A5…

² American size similar to A4. That’s what the infamous message in Office Space “PC Load Letter” meant, it was saying it had run out of letter size paper.

³ American size that’s a similar width to A4 but about three inches longer, so lawyers could write more on each page apparently…?

I’ve noticed before a strange dependency on the name of the paper definition – if it starts with something that could be the name of a paper size, and that isn’t A4, it barfs.

Just as a bit of extra info on this, IIRC¹ what happens with the PS2 driver is…

1. Printers tries to find a PS snippet file which matches the name of the paper up to and including the first space and, if one is found, writes this out to the printer verbatim as the paper details. See PS2Paper’s manual for chapter and verse. If that fails, then as I recall…

2. Some attempt is made to treat the paper name as a named paper size (possibly taking the name up to the first space again), and sending this to the printer. If your printer recognises this, you may get lucky. If you name a paper something like “A4 only joking” and make it 0.5m square, then clearly things will get confused. I also seem to recall that named paper sizes wasn’t really a valid thing anyway, but that might just have been GhostScript.

The TL/DR is that paper sizes in the PS2 driver were a monumental Acorn-style hack, which surprisingly worked enough of the time to lull people into a false sense of security. If you use PostScript, get the PS3 drivers – they always embed the paper size in a way that is valid in real PostScript. If you can’t do that for some reason, then at least make sure that your PS snippets files are up to date and sensible.

¹ This is all something of a hazy memory, and I haven’t gone looking for supporting documents.

I’ve thought of a possible way to deal with multiple paper sources, and duplexing, with printers that support IPP.

It’s easy enough to get the information from the printer about its paper sources and duplexing support.

That information can be written into a Printer Definition File, using prefixes that are not already known to Printer Manager, as PM ignores anything it doesn’t understand. I think.

IPPTrnspt knows which printer it’s sending to, and parses the Printer Definition File whose name is in its choices file, and gets the feed and duplexing information.

This can be selected by the user from a submenu.

IPPTrnspt sends this information to the PDumperIPP or PDumperURF module via the MiscOp SWI.

OK, those of you who know the printing system: where have I got it wrong?

This is, of course, not as tidy as doing all the configuration in Printer Manager, but to do that would require PM to be rewritten AFAICS. The choice seems to be between untidy and impossible.