Printing

This is interesting stuff Rick, especially because I recently purchased a Samsung laser network printer!
When I got said printer home (after John Lewis tried to give me a 2.5 grand Apple Mac) I was mystified to find the power flex in a bag with a HP warranty leaflet. Anyway while searching for a firmware update discovered HP bought Samsung’s printer division some years ago.

So much for not buying another HP printer!

I cannot believe that there are printers supporting one data format over one transport and different data format over another transport.

Printers often try to guess the format if they support many – it wouldn’t surprise me if that guess was interface-specific.

The “I cannot believe” was to motivate Rick to prove me wrong. Now you’ve ruined it! Why not say “This might be a distant possibility, but very unlikely”.

probably Samsung hasn’t paid the PCL licence fee to HP

You don’t have to pay a licence fee to write your own interpreter. Many other implementations are available.

I assumed that it was not possible – without paying a licence fee to HP – to call your printer “PCL compatible”. Just like the PostScript situation. It is written in HP documentation the following phrase: “PCL and Resolution Enhancement are registered trademarks of Hewlett-Packard Company.” Which kind of interpreter you write or licence is a completely different question.

never update its firmware, those “accidents” sometimes get corrected.

I can assure you that a desktop printer does not have support for a particular PDL by accident. Getting the PDL to work inside the constraints of a desktop printer is by far the hardest part of printer development. It absolutely does not happen by accident.

The typical accident happens because a company sells a range of devices to cover all price segments of the market and only change the software to change the capabilities of the device. This is absolutely typical for a wide variety of devices, and I would be very surprised if it is different in the case of desktop printers.

If no other Samsung printer with similar hardware would support PCL, you might have a point.

It might also be that the PCL support is incomplete and/or broken or of limited use because of memory constraints and just happens to work for Rick’s example PCL and it got left active in that firmware version, because it would have been more work to remove it, and since it was no “official feature” it was not considered a problem when deciding if that firmware version could be shipped with that printer.

Rick said

There’s the “standard” apparently defined by HP, and then there’s everybody’s implementations of it.

Nope, even HP implementations don’t agree with each other.

It’s a 600MHz ARM with 128MiB onboard. A full resolution page (9924×14028 pixels) is about 17½MiB.

And a single Japanese OpenType can be 20MB. You can’t assume that the device uses a frame buffer just because it has a lot of RAM in total – there’s a lot of other stuff in there. I can reel of a list of printer manufacturers running the software I worked on, and they’re mostly using banding.

My question was mainly around why it printed the top left quarter of the document zoomed to fill the page

I may still be misunderstanding you, but I think you’re saying that you sent a 1200dpi full page to the printer but it only printed the top left hand quarter? In which case it’s printing the image at 600dpi isn’t it. Is that what you meant?

surely caching kana would have been useful

You’re trying to apply logic to the output of a 300MB PCL driver. HAAAAAAA HAAA HA HA rookie. ;-p

Here one for nemo https://youtu.be/MijmeoH9LT4

I assumed that it was not possible – without paying a licence fee to HP – to call your printer “PCL compatible”

Firstly, interoperability is enshrined in European law. Nobody can stop you saying you are “compatible with” <registered trademark>, although you would probably clarify that your product is “not produced or endorsed by <trademark holder>”. The only reason people try to avoid doing so is the golden rule of advertising – never mention your competitor.

Secondly, “PCL” certainly is a registered trademark – it’s a make of pneumatic tyre equipment; an industrial chemical; some fire-fighting equipment; a brand of fertiliser; a kind of farm lighting; and medical equipment and supplies. But is not registered in Europe as anything to do with printers, computers or HP.

BE VERY CAREFUL! Misrepresenting trademarks is very common. A trick that is often used is a form of words like “Foobar is a trademark of GeeWhiz Corp, registered at the something something patent office”… which is intended to make you believe “Foobar” is a registered trademark, but it’s actually “GeeWhiz” that’s registered.

I had a fight with Agfa Monotype on this very subject, when they started claiming on their various websites that they owned the trademark “Courier” for the ubiquitous typewriter font. They used that ambiguous phrasing to try to rewrite history, but I established that uniquely among the original PostScript fonts, Courier had no trademark claim associated with it (how could it, it was a reproduction of the letterforms of the “Courier” typewriter).

They eventually backed down and removed all claims of trademark ownership.

Having just checked the US Patent Office too, the only registration in a computing field is for telecommunications services, for “Southern Cross Cables Holdings” in Bermuda.

I would be very surprised if it is different in the case of desktop printers.

And I’ve produced desktop printer firmware for various household names for over a decade. Canon, Xerox, Ricoh, HP, Lexmark and others. So, no.

If someone wanted to buy a new printer now for use under RISC OS, what should s/he buy?

Going back to Dave’s original question, we are very happy with the Xerox colour laser printer we bought a few years ago. It’s connected via Ethernet, so we use RemotePrinterFS to feed data to it from RISC OS, using the LPD protocol (it also supports JetDirect).

This is handier than what we had to do previously, when our printer was USB, connected to our Iyonix. We used to use Dave’s JetDirect printer server to print from any machine apart from the Iyonix.

The Xerox supports PostScript and PCL, so from RISC OS the PostScript option makes most sense. It can also accept PDF files, and has a web-based management interface. I was going to write a handy little application such that you could drop a PDF file onto its icon and it would be sent through to the printer, but I found that it was possible to get the same effect by setting the PrintType system variable for PDFs to run a copy command. The application would have made it easy to choose whether the PDF should have been printed double-sided, or 2 pages to a side, etc. But as the printer’s web interface is reasonably usable from NetSurf, we just use that to change the settings before printing a PDF.

Strangely, although we use the Wuerthner/Tytgat PostScript driver for both processes, we find that printing direct from RISC OS produces fairly dark colours, whereas printing to a PDF file (using Steve Fryatt’s PrintPDF) and then copying the PDF to the printer produces colours which are much closer to what we expect. I can’t understand that one.

I recently purchased a duplex Xerox Phaser 3330dni A4 wireless mono laser printer for my home network and I’m really happy with its plug and play capability, it surprised me when Linux auto-configured itself to use the printer.

Because I wanted to use RISC OS I picked a printer with what seemed at the time to have the most options, that included PDF Direct. ;-) Also the Xerox cashback helped, along with it being wireless.

Anyway good to know that when I get round to printing from RISC OS there are options… Thanks Rick / Matthew,…

That’s a nice printer, Andrew – good features :) I’d probably pick Kyocera at that price point, but that Xerox has some nice things that aren’t on the Kyoceras :)

Worth also mentioning on this thread (sorry, advert[ish] coming up…) that our Network Printer Drivers 2 product will work with these printers. Also, it includes !lprPrint which, despite its slightly confusing name, allows sending of data/files direct to the printer via LPR or port 9100 (I think, not checked). I wrote it to do direct PDF printing on an old QMS printer, but it is also useful for sending saved postscript jobs, JPEGs etc.

Network Printer Drivers provides features like job queuing (super-useful for mail-merge on RISC OS), background printing, queue management, job-retry-if-busy and so on (it is also very fast). AFAIK these are unique features and hopefully justify the (quite low) price. It’s also part of our “Bundle CD” which is available as an option for any of our machine customers.

After see Raik’s post earier, I bought a Samsung C480W laser printer from Curry/PC World for UKP 170. I already had the PS3 drivers and I got it printing wirelessly from my Riscospi lapdock. I used RemotePrinterFS#proto=JetDirect;address=192.168.1.129;port=9100:
as the command string. I don’t know if there is a better way.
Thanks Raik for your post.

Thanks Andrew and good to know that there are more options…

Also thanks to Raik for his link to Stefan’s web page that contains a number of useful utilities that includes remote printing.

I don’t know if there is a better way.

Yes but not for free (sorry, I forget in my post.).
Like Andrew Rawnsley say… Network Printer Drivers 2.
Have give a short try this morning with my ARMX6 and Samsung C480W.
You get an easy configuration via GUI.
Supports LPR and JetDirect.
Have try LPR. Works faster than remoteprinterfs and in background.

Rob wrote

[video]

Sorry Rob I missed this. Yes, that video is almost entirely correct. UTF-8 is a brilliant solution, especially to the problem of supporting Unicode through 8bit interfaces.

There were a few errors and omissions though – although UTF-8 is now widely used on the web, many OS APIs and binary document files still use UCS-16, which is unfortunate. And despite his assertion about the number of bytes in a UTF-8 sequence, you can’t have more than four bytes in a legal sequence because Unicode is officially 21bit, not 32bit.

The other slight problem is that it’s out of date. I advocated for fallback right from the start, but it took the Committee a while to come around to the idea. However, fallback is now recommended. Therefore you cannot step back in an arbitrary piece of text just by looking for the first ‘start’ byte – because it might not be a valid sequence. Instead you have to step back by the length of your maximal sequence (four, unless you’re encoding non-Unicode values) and then work forward to the last legal character.

For example, if the text contains F0 80 80|41 (where the | is the cursor) pressing left should move the cursor left by one byte, not by three. The F0 is the start of a four byte sequence, but 41 is not a valid continuation byte, so the whole sequence is broken. The old UTF-8 standard would have replaced F0 80 80 with the Unicode replacement character (usually displayed as a white-on-black question mark), but with fallback one treats those bytes as characters in an 8-bit fallback alphabet.

I’m interested in IPP again.

I note that PWG-Raster is an open standard. What proportion of IPP-compatible printers out there support PWG-Raster?

Also, I’m thinking a bit further forward, to how to integrate IPP within the Printers system that we have. You’d like a universal IPP Printer Definition File, wouldn’t you, but the existing system has one for each printer model, in which all the resolutions and the maximum media sizes are already known. IPP makes it possible to interrogate the printer to find the information. I don’t see a way to feed that back into the Printers app to make it possible to select the resolution, live. Of course it’s possible to interrogate the printer and create a definition file for the user to store away and select, which is not too bad (and may be the best we can do).

What proportion of IPP-compatible printers out there support PWG-Raster?

Isn’t that how raster images are to be encoded? So, I’d say all of them that support IPP. Which is likely most things since at least 2017.

I say that, as my HP3630 which is a cheap thirty-quid printer claims to be IPP compatible. If that can support IPP, then its contemporaries ought to be able to as well.

You’d like a universal IPP Printer Definition File, wouldn’t you,

Probably not. I can imagine my inkjet accepting 24 bit RGB data. My laser is too old to support IPP, but if it did, well, I can’t imagine a mono laser doing anything useful with RGB. That’ll probably want a monochrome (1bpp?) bitmap.
Then there’s the issue of resolution. A 300dpi bitmap won’t be the same as a 600dpi bitmap.
So already we have different amounts of data and different physical formats.

Now combine this with what happens if a user has multiple such printers. :-)

The (failed) method that I was working on (aimed at AirPrint, but it’s conceptually similar) was to use SPrinter to print to a colour sprite, which would then be picked up by a program that would convert the sprite into a raster bitmap for the printer. If the inkjet, it would generate a colour raster, if the laser, it would make a monochrome one (which would look poor as no halftoning, but that was something to work out when it, you know, actually worked).

Integrating with Printers would be better, but I think Printers itself would need some work in order to be able to change its setup “on the fly”, including reading status and settings from the printers themselves. RISC OS comes from a day when printers were dumb devices that either did what they were told, or ate bits of paper and spewed out weird messages like the infamous PC LOAD LETTER.

Isn’t that how raster images are to be encoded? So, I’d say all of them that support IPP.

I don’t see anything in the IPP spec that mandates support for PWG-Raster. If I’ve missed something, please correct me.

You’d like to believe that printer manufacturers would support it, as it would absolve them of having to provide a driver for every model they make, for each OS version they support. But since when have manufacturers behaved logically?

Maybe you’d like to blow the dust off your IPP app and make a version that only queries the printer for the formats it supports. Then you can ask our readers here to try it and report back.

You’d like a universal IPP Printer Definition File, wouldn’t you,

Probably not.

I’m surprised by your answer. Imagine that there’s an “IPP” definition file, and it would work for every IPP printer (that supports the raster formats that we do), and the options shown are the options for the printer that it’s communicating with. In terms of user friendliness, I think it’s unbeatable. Cleraly it would require some changes to the Printers app though, to go find them from the printer instead of the PDF.

that mandates support for PWG-Raster

How does one send raster data if not?

I don’t see anything in the IPP spec that mandates support for PWG-Raster.

IPP Everywhere standard 5100.14-2013:

Section 6, Document Formats
Printers MUST support documents conforming to PWG Raster Format [PWG5102.4] (“image/pwg-raster”) and JPEG File Information Format Version 1.02 [JFIF] (“image/jpeg”) […snip specifics on JPEG…]

IPP/2.1 and IPP/2.2 Printers MUST and IPP/2.0 Printers SHOULD support documents conforming to Document management – Portable document format – Part 1: PDF 1.7 [ISO32000] (“application/pdf”) […snip…]

Printers SHOULD support documents conforming to the Open XML Paper Specification [ECMA388] (“application/openxps”).

I’m surprised by your answer.

Yes, I might have been a bit hasty there. Your suggestion makes sense. I’m just wondering what would happen with respect to multiple printers.

Oh, and you’ll want to pull out the printer’s serial number (the enquiry will tell you that along with a ton of other things) because a home router with DHCP, could give different addresses each session (perhaps depending on what order the printer(s) were turned on in, or if the kids have their phones/tablets active, etc).

and the options shown are the options for the printer that it’s communicating with.

That might need a number of changes to Printers to get that to work. ;-)

But, certainly, consider me a volunteer for testing. I have Instant Ink so I can easily spare a dozen pages a month on testing stuff. And god knows, supporting IPP would magically make a lot more modern printing devices available to us.

Hmmm… I have a WiFi Epson around somewhere that I bought but never set up (as the HP is still working). When this gets going, I’ll need to dig it out and see if that one supports IPP too.

You must not confuse “IPP” (as in: we have a transport protocol based on HTTP for any kind of data the printer happens to like, such as PCL, PS, PDF…) with “IPP Everywhere” (basically a standardized Apple AirPrint which defines a universal raster format). My Oki laser printer from 2011 supports IPP just fine, but the IPP Everywhere standard did not exist back then.

To answer Dave’s question: apparently, only a few HP printers support IPP Everywhere. You could do worse than running a Google translate over a blog article I wrote some time ago about my experiments with some IPP Java code on PCs with that Oki laser mentioned above: http://itblog.huber-net.de/2019/08/stuempern-mit-niveau/

Rick: thanks, that’s good. Clearly I missed that.

I skimmed through some of the PDumper code this afternoon. There is an option to create strips in RGB24, which is one of the flavours of PWG-Raster. I don’t know whether the results would be perfectly compatible. If not, it might at least be close enough to make it easy to add code to give the correct format.

If only we had documentation on the internal workings of the printing system, that is…

I’ve started to work on IPP PWG Raster. I found some example files on the Internet, appearing to come from an impeccable source. I’ve managed to create a sprite from the first one: black and white, 1 bit per colour, 150dpi. Not wildly exciting on its own, but it shows that I’m on my way to understanding the IPP PWG Raster spec, 5102.4-2012.

The point of the exercise, apart from confirming my understanding of the spec, is to create a tool that will enable testing generation of IPP PWG Raster files by the RISC OS printing system without having to spend a fortune on ink and paper.

I’m going to add more resolutions so that all IPP PWG Raster formats can be tested.

(Edited “IPP Raster” to “IPP PWG Raster”)

Sounds a good plan!

Sounds a good plan!

+1

Good luck Dave in your quest.

I have used Rick’s SammyPrint to good effect on three HP printers, two inkets and one laserjet, but it would be good to get IPP as standard.

It was also a pity Dave Lambley’s IPP Printer Driver has got lost and stuck at 26bit so is the intention to feed this back in to the ROOL sources.

If you need any testing doing then also happy to help.

It was also a pity Dave Lambley’s IPP Printer Driver has got lost and stuck at 26bit

Wayback can ‘unlose’ the IPPDeviceDriver 1.04 module

The “stuck at 26bit” bit is still a thing though.

A 32bit conversion via Armalyser could be possible, if one knew how that is!!

I’m not sure how useful converting a 16 year old driver without the source is going to be, it certainly wouldn’t be easy to develop it further.

I’m not sure how useful converting a 16 year old driver without the source is going to be, it certainly wouldn’t be easy to develop it further.

Possibly useful for a reference output from a standard set of inputs?