Printing

I’ve seen a number of other routers with print server facilities.

Some Netgear routers (e.g. the Nighthawk AC1900 model D7000v2) allow a USB printer to be shared. This is done using a proprietary mechanism (ReadySHARE) and each computer still needs the appropriate USB printer driver as well as the ReadySHARE software. In short, not that interesting for our purposes.

represents about 2 minutes of queries thrown at Google

Ditto. The thing is, if you read the information, you’ll find there are many holes and deficiencies.

I do not envisable a big problem in supporting “IPP Everywhere” as that’s an open specification.
However it’s an open specification that is very recent.
Thing is, every WiFi printer prior to that will likely not support it, and those that do will likely have deficiencies in their level of support (as noted above, PDF support is not guaranteed).
The one that is supported fairly widely is URF, either via a protocol like PCL or by dumping raw data to the printer. It’s a de facto standard. And this is where one runs into problems. De facto, but not open. Documented only by somebody attempting to reverse engineer one out of the many types.

I have here in my hand a technical specification of the SPL2 language (QPDL), written by Aurélien Croc and translated into English. It seems to be fairly similar to URF, in being a banded bitmap. There may be enough here to attempt something (for a far more limited range of devices), but again as it is the result of reverse engineering, there are omissions – the second entry in the header notes that it is the resolution divided by 100, and then states “(horizontal or vertical?)” afterwards. And there are numerous fields whose value is unknown but here’s what it always seems to be…

And this is just talking to the printer.

The next section of the amusement park is dealing with printer drivers. The method that I used was to use SPrinter to turn the output into a bitmap, and then have a little program to go through the bitmap pixel by pixel to create something for the printer. Which, ultimately, did not work and was really slow (even being written in C).

Maybe a bit of both?

Having some information is very different to having an implementation.

Note, by the way, that I’m not that interested (at this time) in supporting IPP. My interest is in getting a page from Ovation to appear on my printer. I don’t see much point in doing anything else until some form of output can be generated.

Perhaps people could check their router and similar models for such facilities.

It appears to accept raw data, so I would imagine it’s basically a pass-through and you’ll still need whatever sort of driver on the PC in order to create the expected sort of data. The router isn’t so much a printer server as an “invisible wire” between your computer and the printer.

<clicky><clicky><rummage>

Yes – you need to connect your printer to each computer in turn so it can load it’s drivers onto the computer. Info (in French).

Then you plug the printer into the Livebox and on the PC, add a new printer as a wireless device. Info (in French).

So, yeah, it’s just acting as an invisible wire so won’t be particularly useful to us.

RISC OS IPP driver on SourceForge…

…with no files!?

https://sourceforge.net/projects/ippdevicedriver/

Wayback is your friend or in this case the one you didn’t want to turn up as it seems only a non source pre built/non 32 bit module is avilable at version 1.04.

There seems to be an MIT-licenced Java/Kotlin implementation if IPP by HP: https://github.com/HPInc/jipp

Replying to myself…a description of an experiment on how to spend a few hours stumbling through unknown territory.

• start with zero knowledge about IPP apart from the name, and an OKI C530 colour laser printer which supports PDF and PostScript connected to the local network
  • side note: bought the Oki in 2011, so predates recent updates of IPP as I found out later…
• download jipp project from GitHub
• find out that it is written mostly in Kotlin and needs gradle to build
• search the Internet for a readily-packaged jar instead (and found it, complete with all Kotlin runtime dependencies!)
• create an Eclipse project based on a very minimal Java example from jipp project (“jprinter”)
• just run it (needs only the IPP URL supplied and a filename for the data to be printed – the OKI supports PDF, so find a one-page PDF first)
• of course it does not work out-of-the-box, with different interesting Java exceptions which suggest an HTTP protocol problem
• wait until the first wave of disappointment is gone by
• decide to not go for “printJob” directly, instead try “getPrinterAttributes” first
• still the same interesting exceptions
• study the various forms of “IppPacket” that are creatable where the command sent to the printer is encapsulated
• there is a suspicious field “versionNumber” there – try that form, and supply “1” as version
• search for the RFC where all the IPP commands are specified for “getPrinterAttributes”, because that braindead class does not accept that nice “Operations” enum for the constructor that also allows versionNumber
• find the command code for getPrinterAttributes first in the Kotlin sources instead
• ah, once in 20 times it gives not an exception, but the printer then replies properly with “server-error-version-not-supported”
• find out that the Oki supports IPP versions 1.0 and 1.1 and that jipp defaults to 2.0
• find out how to encode that version in the IppPacket – 1.1 must be 0×0101 obviously…
• now, all commands are received just fine by the printer
• find out that jipp cannot parse the reply from my printer to “getPrinterAttributes” properly – but there is enough deducable from the stacktrace to find out the printer’s features just fine
• now try the printJob command with a PDF
• doesn’t work – printer says “client-error-attributes-or-values-not-supported”
• turns out that the PDF must be sent as application/octet-stream instead of application/pdf as document type
• …and it prints!

So from my point of view, IPP printing is considered a solved problem, it is now just the details like doing it from RISC OS and supporting formats beyond PDF for the more standard printers :-)

So from my point of view, IPP printing is considered a solved problem, it is now just the details like doing it from RISC OS and supporting formats beyond PDF for the more standard printers :-)

For a proof of concept the RO end would surely just¹ require a download of the Dave Lambley module and a replacement of the 26-bit elements (likely to be simply exits with ^) and send some data to an IPP device.
Of course there’s the small diversion via the Wayback machine copy of Dave’s old site to get hold of the binary to reverse engineer – or the email query by Raik may result in the source being made available. Hopefully, updated it can be added to the ROOL source.

¹ Saying just of course is pretty glib but sometimes it is simply a quick cleanup.

For a proof of concept the RO end would surely just require a download of the Dave Lambley module and a replacement of the 26-bit elements (likely to be simply exits with ^) and send some data to an IPP device.

Having had a quick lock at the module – it does not do much. So an equally good proof of concept would be to do an HTTP connection and send some known-good payload data. I could supply that.

Unless the module sources surface, we get to know under which licence the source lives and it is liberal enough, and someone would take over development of a module written in Assembler, it does not make much sense to take that module as a starting point. For simple printing, extending one of the remote printing modules would probably be straightforward.

I am so happy. :-) ☺

I started this morning by writing a program to convert a laserjet raster file to sprite. It wasn’t actually that hard.

Then I rummaged around on my desk and dug up the unofficial specification of QPDL raster data and ran into a brick wall when it came to the compression part. Basically, it read like gibberish to me.

I had an example created with the printer driver on Windows (and saved to file) and it had a number of PJL commands in there.

So, just for the sake of playing around, I tried to set the language to PCL and write out a text message.
Which worked.
So I then tried cursor positioning.
Which worked.
So, just for the hell of it, I decided to dump an entire page printed as if to a LaserJet. Do or die, right?
It almost worked.
I got maybe the top three hundred lines (about half an inch) and garble. But it was enough to tell me that my Samsung M2022W (that mentioned nothing about PCL or LJ support) does in fact support PCL/LJ output.

The rest of the day was taken cobbling all of this into a program, and refining it to work reliably.

[link removed – see later post]

If you want to test this, here’s what you need to do:

• First of all, you will need a laser printer that supports IPP.
  The program will look specifically for a non-colour printer (this is because my inkjet is a lower IP address and isn’t compatible).

• Now install the LaserJet 6 driver.
  Configure it to be 600dpi with auto paper feed and grey,diffused quality.
  Set its connection to File and “<Wimp$ScrapDir>.LJ6data”.

• Print something. Anything, it’s up to you. If it’s your first attempt, I’d suggest a single page. ;-)
  Note that since RISC OS is making a raster bitmap, Japanese (etc) works just fine. ;-)

• When printing is complete, run SammyPrint. You can run it as a single-tasking program (double-click it) or in a TaskWindow.
  If it’s your first attempt, I’d suggest single-tasking.

• The hourglass will appear with the upper LED lit up. This means that the program is scanning your network looking for a compatible IPP printer (namely, on-line and not colour and supports URF – use the FindIPP program I linked to earlier to run a scan with output).

• Once a suitable printer has been found, the program will open port 9100 (hourglass LED changes to the bottom one) and will start chucking data at the port (with some preamble to set it up).

• The hourglass will count up percentage of the file sent. It isn’t terribly fast, note. Quite a bit slower than printing from mobile, but then we’re running at 600dpi (while mobile looks to be 150 if we’re lucky). Also QPDL compresses better than LJ’s packbits.

• At the end, the program will quit and a printout should appear before your eyes.
  From RISC OS, no less! ;-)

If it all went right for you, then be happy that you can now print from RISC OS to a newish laser printer.

If it went wrong, there should have been either a message on screen or some sort of reply from the printer. If there was a message, check the obvious like if port 9100 is open and available. If the printer did nothing, flashed some sort of error, or starting spitting out pages of junk, then there’s a good chance your printer does not support PCL.

Full size: https://i.imgur.com/DQVfSxr.jpg

A slightly later version of SammyPrint (my IPP WiFi laser printer dodah), some information on what I did, and installation instructions are on my blog:

https://heyrick.eu/blog/index.php?diary=20190729

If you try this on a WiFi capable mono laser printer, please let me know how you get on. I can say, for now:

Works with:

• Samsung M2022W

Do you intend to take it further, Rick? E.g. sending the data via IPP instead of to the raw port?

Once a suitable printer has been found, the program will open port 9100

Hang on, Rick. That means you’ve transferred the stream to the printer using the JetDirect protocol. No wonder it accepts PCL.

Please correct me if I’m wrong, but… it’s my understanding that IPP Everywhere etc. transfer the print data stream via IPP, which uses HTTP. As I understand it, all you’ve used IPP for is to find a printer and interrogate it for its capabilities.

Hang on, Rick. That means you’ve transferred the stream to the printer using the JetDirect protocol. No wonder it accepts PCL.

When JetDirect was invented by HP for laser printers, this connection was certainly the truth, but nowadays it is usually called “AppSocket prototcol”, is HP-independent (because it was always direct-raw-socket stuff) and is supported by all kinds of printers without PCL capability.

As I understand it, all you’ve used IPP for is to find a printer and interrogate it for its capabilities.

That’s also what I understand, but it is a very good first step.

Do you intend to take it further

Maybe some command line options for fine tuning, but otherwise probably not.

That means you’ve transferred the stream to the printer using the JetDirect protocol. No wonder it accepts PCL.

Tell that to my HP inkjet. You’d have thought the printer to support a common HP protocol would be the HP printer, right? <sigh>

Note also from the blog post (big Zap window) that the Samsung Windows driver sends QPDL in that same manner. You’ll also find many printer drivers (Windows and Android) will attempt to use a “raw” connection (may be configurable to LPR or IPP).

It’s JetDirect to printers that support JetDirect. It’s “raw” to everything else. Depending on the printer, it may support PCL, PostScript, HPGL, JPEG, or some sort of proprietary thing. If there is sort of PJL then you ought to be able to select what “language” is supported. If there is no PJL, then it’s probably fixed to be specifically what the printer wants (I believe the inkjet uses PCL3GUI).

it’s my understanding that IPP Everywhere etc. transfer the print data stream via IPP,

Correct. Also allows access control, which raw typically doesn’t.

which uses HTTP

HTTP-like with a binary payload. The mechanism will be familiar to anybody who has ever written a web fetcher of any sort.

all you’ve used IPP for is to find a printer and interrogate it for its capabilities.

Correct. To determine if it can be used. Then I send PJL to raw to get it to switch to PCL mode (which the user guide says the printer does not support!) and send the data. Why? Because that works. It may be that IPP only supports QPDL and URF encoding.

Like I said, this is what works. And if PJL/PCL is indeed fairly common, then RISC OS can now print to a number of devices, right? ;-)

Then I send PJL to raw to get it to switch to PCL mode (which the user guide says the printer does not support!) and send the data. Why? Because that works. It may be that IPP only supports QPDL and URF encoding.

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

However, I could also not believe that a printer supports PCL if its data sheet does not say so, so what do I know :-) A happy accident for you, Rick – probably Samsung hasn’t paid the PCL licence fee to HP…just remember to never update its firmware, those “accidents” sometimes get corrected.

A happy accident for you, Rick

Indeed.

Updated SammyPrint. Don’t have time to discuss it right now, so here’s the help message:

*SammyPrint -?
Syntax: SammyPrint [-colour] [-file <filename>] [-ip <addr>] [-nopreamble] [-verbose] 
        -colour     to allow colour printers to be accepted in network scan
        -file <f>   to use a file other than <Wimp$ScrapDir>.LJ6data.
        -ip <addr>  is an IP address of a printer, device will NOT
                    be checked for compatibility first.
        -nopreamble to send data verbatim, without PJL setup.
        -verbose    to be talkative (best used in a TaskWindow)

Examples:
  To print a LaserJet 6 output to a Samsung M2022W laser printer:
    SammyPrint
  To do likewise, but specify the printer:
    SammyPrint -ip 192.168.1.24
  To send "$.kittens.jpeg" to an HP3630 inkjet:
    SammyPrint -colour -file "$.kittens/jpeg" -nopreamble -verbose
    (this may work also for PDFs or PostScript if supported by the printer)

This is SammyPrint version 0.02 (30th July 2019) by Rick Murray.
Please refer to ht tps://heyrick.eu/blog/index.php?diary=20190729

*

Note that my HP inkjet accepted (and completely ignored) the PCL data.

However, with no preamble, I sent it a JPEG and it printed that scaled to fill the page. Not entirely useful for printing from RISC OS, mind you. ;-)
For more advanced printers, maybe PostScript or PDF is a possibility?

Updated file on my blog page (link a few messages before this one).

Note that my HP inkjet accepted (and completely ignored) the PCL data.

Did you use the “LaserJet” PCL thing? IIRC, it produces PCL5, and some inkjets only accept PCL3-with-colour-stuff or PCL-XL. IIRC, it’s been a long time…

What does the inkjet respond to “getPrinterAttributes”?

What does the inkjet respond to “getPrinterAttributes”?

I presume you mean this part?
[edited: copy-pasted again, this time using NetSurf, that didn’t muck it up like Android Firefox did]

  mimeMediaType       : document-format-supported = "application/vnd.hp-PCL"
  mimeMediaType       : (continued) "image/jpeg"
  mimeMediaType       : (continued) "application/PCLm"
  mimeMediaType       : (continued) "image/urf"
  mimeMediaType       : (continued) "image/pwg-raster"
  mimeMediaType       : (continued) "application/octet-stream"
  textWithoutLanguage : document-format-version-supported = "PCL3GUI"
  textWithoutLanguage : (continued) "PJL"
  textWithoutLanguage : (continued) "Automatic"
  textWithoutLanguage : (continued) "JPEG"
  textWithoutLanguage : (continued) "PCLM"
  textWithoutLanguage : (continued) "AppleRaster"
  textWithoutLanguage : (continued) "PWGRaster"

So, then… PCL3GUI and PCLM, IPP PWG, Apple URF, and JPEG.

But I’ll helpfully point out that the Samsung makes no mention at all of PCL. ;-)

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

Samsung no longer make printers. Shame. Guess who owns that stuff now…

The inkjet says it supports PJL. Not via the raw port, it doesn’t.

I had much better luck talking to the Samsung, once I’d told Hearsay to send CRLF. :-)

Make sure we’re in PJL mode and ask for configuration status:

%-12345X@PJL INFO CONFIG
IN TRAYS [1 ENUMERATED]
        INTRAY1
PAPERS [14 ENUMERATED]
        LETTER
        LEGAL
        A4
        EXECUTIVE
        JISB5
        ISOB5
        NO10ENV
        MONARCHENV
        DLENV
        C5ENV
        FOLIO
        A5
        CUSTOM
        OFICIO
LANGUAGES [1 ENUMERATED]
        QPDL
USTATUS [4 ENUMERATED]
        DEVICE
        JOB
        PAGE
        TIMED
MEMORY=1348009

You will notice, of course, that there’s no mention of PCL in the languages section. ;-)

Some other things:

@PJL INFO CONFIG
SERIAL NUMBER="xxxxxxxxxxxxxxx"
@PJL INFO MEMORY
TOTAL=1348008
LARGEST=1336925
@PJL INFO PAGECOUNT
PAGECOUNT=1418
@PJL INFO STATUS
CODE=35078
DISPLAY=
ONLINE=TRUE
FMU=NONE

Since it appears to be a proper PJL parser, I asked it for settings information:

@PJL INFO VARIABLES
AUTOCONT=ON0SEC[3 ENUMERATED]
        OFF
        ON30SEC
        ON0SEC
BINDING=OFF[5 ENUMERATED]
        OFF
        LONGEDGE
        SHORTEDGE
        REVERSE_LONGEDGE
        REVERSE_SHORTEDGE
COPIES=1[2 RANGE]
        1
        999
CUSTOMSHORTEDGE=210[2 RANGE]
        76
        216
CUSTOMLONGEDGE=297[2 RANGE]
        127
        356
DENSITY=3[10 ENUMERATED]
        1
        2
        3
        4
        5
        6
        7
        8
        9
        10
DUPLEX=OFF[2 ENUMERATED]
        OFF
        ON
ECONOMODE=OFF[2 ENUMERATED]
        OFF
        ON
INTRAY1=UNLOCKED[2 ENUMERATED]
        UNLOCKED
        LOCKED
INTRAY1SIZE=A4[37 ENUMERATED]
        LEGAL
        A4
        EXECUTIVE
        JISB5
        B5
        COM10
        MONARCH
        DL
        C5
        POSTA6
        C6
        FOLIO
        A5
        STATEMENT
        A6
        LEDGER
        A3
        JISB4
        JPOST
        JPOSTD
        CUSTOM
        LETTERP
        A4P
        B5P
        A5P
        EXECP
        STSP
        A3OVER
        B5ENV
        OFICIO
        634
        USPOST
        INDEX
        B6
        HAGAKI
        ODD
        B4
LANG=ENGLISH[1 ENUMERATED]
        ENGLISH
MANUALFEED=OFF[2 ENUMERATED]
        OFF
        ON
MEDIASOURCE=AUTO[2 ENUMERATED]
        DEFAULT
        TRAY1
MEDIATYPE=PLAIN[36 ENUMERATED]
        PLAIN
        NORMAL
        THICK
        THIN
        BOND
        COLOR
        CARDSTOCK
        LABELS
        OHP
        TRANSPARENCY
        ENVELOPE
        PRE-PRINTED
        RECYCLED
        USED
        LETTERHEAD
        SPECIAL
        PRINTED
        COTTON
        PAPERTYPE1
        PUNCHED
        ARCHIVE
        PREPUNCHED
        PHOTO
        HEAVYWEIGHT
        HEAVY
        PERSONAL CHECK
        3MDECAL
        Custom1
        Custom2
        Custom3
        Custom4
        Custom5
        THICKER
        EXTRATHICK
        THICK_ENV
        THINCARDSTOCK
ORIENTATION=PORTRAIT[2 ENUMERATED]
        PORTRAIT
        LANDSCAPE
PAPER=A4[39 ENUMERATED]
        LETTER
        LEGAL
        A4
        EXECUTIVE
        JISB5
        B5
        COM10
        MONARCH
        DL
        C5
        POSTA6
        C6
        FOLIO
        A5
        STATEMENT
        A6
        LEDGER
        A3
        JISB4
        JPOST
        JPOSTD
        CUSTOM
        LETTERP
        A4P
        B5P
        A5P
        EXECP
        STSP
        A3OVER
        B5ENV
        OFICIO
        634
        NO9
        USPOST
        INDEX
        B6
        HAGAKI
        ODD
        B4
PERSONALITY=AUTO[2 ENUMERATED]
        SMART
        QPDL
POWERSAVE=ON[2 ENUMERATED]
        OFF
        ON
POWERSAVETIME=1[2 RANGE]
        1
        120
RESOLUTION=600[5 ENUMERATED]
        300
        600
        FAST1200
        1200
        200
TIMEOUT=15[2 RANGE]
        5
        300
TONERSAVE=OFF[2 ENUMERATED]
        OFF
        ON
REPRINT=OFF[2 ENUMERATED]
        OFF
        ON
LPARM:PCL FONTNUMBER=0[2 RANGE]
        0
        103
LPARM:PCL FONTSOURCE=I[2 ENUMERATED]
        I
        RFONT
LPARM:PCL SYMSET=PC8[47 ENUMERATED]
        ROMAN8
        DESKTOP
        ISOL1
        ISOL2
        ISOL5
        ISOL6
        MCTEXT
        MATH8
        MSPUBL
        PIFONT
        PSMATH
        PSTEXT
        VNINTL
        VNMATH
        VNUS
        WIN30
        WINL1
        WINL2
        WINL5
        WINBALT
        SYMBOL
        WINGDING
        LEGAL
        ISO4
        ISO6
        ISO11
        ISO15
        ISO17
        ISO21
        ISO60
        ISO69
        PC775
        PC1004
        PC8
        PC8DN
        PC850
        PC852
        PC8TK
        CYRILLIC
        CP866
        GREEK
        ARABIC8
        WINARABIC
        PC864
        FARSI
        ISOARABIC
        PC8GREEK
LPARM:PCL LINETERMINATION=0[4 ENUMERATED]
        0
        1
        2
        3
FORMLINES=64[2 RANGE]
        5
        128
WIDEA4=OFF[4 ENUMERATED]
        OFF
        ON
        NO
        YES
OVERRIDEA4WITHLETTER=NO[2 ENUMERATED]
        NO
        YES
LPARM:PCL PITCH=10.00[2 RANGE]
        0.44
        99.99
LPARM:PCL PTSIZE=12.00[2 RANGE]
        4.00
        999.75
COURIER=REGULAR[2 ENUMERATED]
        REGULAR
        DARK
BITSPERPIXEL=1[3 ENUMERATED]
        1
        2
        4

Hmm… WideA4 is “off”, “on”, “no”, and “yes”. Well, is there any specific difference between “no” and “off” or “yes” and “on”? Nothing like clarity, is there?

One can ask for various sorts of status information as well.

@PJL INFO USTATUS
DEVICE=OFF [3 ENUMERATED]
        OFF
        ON
        VERBOSE
JOB=OFF [2 ENUMERATED]
        OFF
        ON
PAGE=OFF [2 ENUMERATED]
        OFF
        ON
TIMED=0 [2 RANGE]
        5
        300

So I ask for a running status, then mash a few keys to send data that it thinks is supposed to be printed.

@PJL USTATUS DEVICE = VERBOSE
Hello! Hello! Hello!

@PJL USTATUS DEVICE
CODE=10003
DISPLAY="Warming Up"
ONLINE=TRUE
@PJL USTATUS DEVICE
CODE=10023
DISPLAY="Printing"
ONLINE=TRUE
@PJL USTATUS DEVICE
CODE=40022
DISPLAY="Pickup JAM"
ONLINE=TRUE

That’s normal, I’ve not bothered to put any paper into it. ;-)

Use the terminal of your choice to connect to port 9100. Then send the command <esc>%-12345X (probably best programmed in as a macro), and then send @PJL INFO CONFIG (with CRLF line ending) and see if the printer replies with anything.

Crap.
Just discovered an unpleasant bug in v0.02 where autoscanning would be liable to fail.
Reason: variable “scanip” was used for the IPP scanner. When it was split up into procedures (so it could be skipped if IP address given), “scanip” was made global so it could be seen from other places in the code.
But the local copy, now not in main() any more, was left in place. So when the scanning routine updated “scanip” with the value of the printer found, it was updating its local copy, not the global one. Meaning there’s a pretty good chance SammyPrint would be trying to connect to 0.0.0.0. :-(

Update pushed to my blog, and here’s a direct link for you guys: https://heyrick.eu/blog/index.php?diary=20190729

Sorry. I’m an arse.

M2022W tested at 150dpi (which looks like the same sort of quality as the Android print, jeez). Worked fine, didn’t need any changes, all that setup is in the PCL data. ;-)

Is anybody here familiar with the PDumpers?

Just for a test, I created a LaserJet definition set to 1200dpi resolution. It appeared as if it might work, but when the page came out, it was the upper left quarter, thus suggesting to me that maybe it was stuck on understanding scaling or whatnot for 600dpi as the maximum?
There’s no mention of “600” in the PDumperLJ source, so I was wondering if it had some other mechanism for dealing with the output scaling?

I’ll be honest with you, I don’t need 1200dpi – 600 is plenty fine (the front page of Frobnicate #31 looks okay, given it’s a black and white printer!) and the file size at 1200dpi was getting a bit… much (13MiB for the page, where 600dpi is ~3½MiB). It’s just… an odd result. I am interested in where/how/why it did what it did.

Steve said

Apparently renamed as PCL6 Enhanced by HP but third party implementations tend to refer to PCL XL or PXL

Having implemented PCL5 & 6 in a PostScript RIP I can be definitive about the standard: There isn’t one. We used to joke that the “spec” in “PCL spec” stood for “speculation”. When a Japanese manufacturer specifies PCL compatibility they don’t just specify the manufacturer, they specify the individual model, as behaviour can vary from implementation to implementation. PC drivers then target a specific implementation.

I really can’t stress strongly enough what an absolute pain PCL is. PCLXL is somewhat better defined than PCL, but it’s still extremely implementation defined. And by that I mean choose-your-favourite-set-of-bugs-and-go-with-it.

The most wonky area is in the support of ROPs (raster ops), which can be highly variable in corner cases. Fortunately, RISC OS doesn’t have ROPs, so any mismatch between expectation and implementation is not going to crop up. Stick to rasterised fonts and the simplest image cases and you’ll be good. Start messing with Intellifont or embedded TrueTypes and it’ll get messy.

Steffen exclaimed

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.

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.

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.

Rick wrote a lot, including

<esc>%-12345X

PCL FTW. If your device supports PCL, use that. If they’re pretending that the device doesn’t support PCL it may be because it’s horribly bugged. However, devices for the Japanese market have to have a working PCL implementation. They just do.

But I have to stress, PCL does not equal PCL. What works on one device may not on another. It helps enormously if the PCL file is created with banding in mind. If it jumps about all over the page it can cause memory problems in small devices.

I created a LaserJet definition set to 1200dpi resolution. It appeared as if it might work, but when the page came out, it was the upper left quarter, thus suggesting to me that maybe it was stuck on understanding scaling or whatnot for 600dpi as the maximum?

I’ve not explored the Dumpers much, but bear in mind that RISC OS plotting is resolutely 16bit (and some things less than that) so that could well cause problems at high resolution.

If 600dpi works, I’d be tempted to use that and enhance to 1200dpi – you’re not likely to be able to tell the difference, and I suspect the halftoning would be unusable at 1200dpi.

Apropos of nothing, one of my favourite features of HP’s PCL implementation (which I did not duplicate) is that it draws a single-pixel outline around halftoned text, to sharpen the edge. Clever and effective.

However, I did implement an Eagle-style (or SAA-5050 style, if you will) resolution enhancement for bitimaged fonts, which in PCL are often delivered at 300dpi but used at 1200dpi – that smoothed things out very nicely.

The most interesting discovery though is that some Japanese drivers don’t bother making any fonts at all – working on the principle that if you have 17,000 glyphs you’re not going to be reusing many of them per page, so why not just draw them.

Unfortunately they also did that with Latin text, which absolutely does reuse its glyphs all over the page, which impacted performance noticeably. So I invented a technique where repeated geometry was recognised and turned into a font to take advantage of caching. This is cleverer than it sounds because there seemed to be two stages of quantisation in the glyph geometry, so no two repeated letters were ever numerically identical. Fun.

I really can’t stress strongly enough what an absolute pain PCL is.

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

The most wonky area is in the support of

I’d be inclined to say PCLm or PCL3GUI, given they’re not openly defined.

it wouldn’t surprise me if that guess was interface-specific.

The best description that I found for AppSocket said to just imagine that it was a parallel port plugged into the printer. Treat it exactly as that, nothing more, nothing less.

Getting the PDL to work inside the constraints of a desktop printer is by far the hardest part of printer development.

Constraints? It’s a 600MHz ARM with 128MiB onboard. A full resolution page (9924×14028 pixels) is about 17½MiB.
I’m pointing this out because this is the bottom end of the laser printer market, with a device that’s a good few years old now.

It absolutely does not happen by accident.

Added as a “feature” with copy-pasted code from an earlier model? Wait, what was that you were saying about bugs? Don’t worry, it’s not a rocket…

Rick wrote a lot,

No surprise.

However, devices for the Japanese market have to have a working PCL implementation.

That’s useful to know. I’m surprised there’s no “Export model” without, though.

Speaking of Japanese – I’ve had a report of it working with a Kyocera M2040dn.

If 600dpi works, I’d be tempted to use that and enhance to 1200dpi

“Enhance it”?
Yes, the 600dpi works and looks fine. I would imagine the extra quality would just mean extra time taken.
My question was mainly around why it printed the top left quarter of the document zoomed to fill the page – it’s as if something can only handle scaling up to 600dpi and the driver tried to cope with larger and failed. So close, yet so far. ;-)

that if you have 17,000 glyphs you’re not going to be reusing many of them per page, so why not just draw them.

That might make sense with kanji, but surely caching kana would have been useful? “Wa” and “ga” are common particles, and “no” (the pretzel) is a possessive particle that turns up all the time, along with the “ru” verb ending. And that’s just off the top of my head.