Printing

does the fetcher put in a correct Content-Length header for the body only?

Interesting observation. I hope so, but…

Could you maybe cobble together a dead simple server to accept requests and dump what you receive?

There’s an easier way: use Wiresalmon to capture what’s sent in plain mode. The result is that the fetcher does indeed put in a correct Content-Length header, whose value is different from the length of extra header lines plus body that I fed to it.

We’re OK.

I’ve edited my code to remove excess, and verified that it works correctly on the one printer that I have access to. Rick, you can expect an email shortly.

Edit: email with code sent.

Rick, you can expect an email shortly.

Thanks. Sadly you missed me by about twenty minutes.

I’ll try it on both of my printers this evening, report back what they say.

My FindIPP works with them, so I would imagine straight http would suffice. We’ll see. ;)

I think I may have found a bug elsewhere in the printing system.

I decided to try PDriver_MiscOp to send information to my driver. I’ve implemented the MiscOp, but when I try to call it, I just get an error message:

Bad strip type specified to PDriverDP at line 40

Line 40 is in my little test app:

SYS &8015A, &80000100, 26

My dumper is registered as number 26. In fact it doesn’t matter if I substitute different PDumper numbers, or different reason codes, or if I remove the handler from my dumper – nothing changes the error message. My module doesn’t generate that message; no surprise, as the error message says it comes from PDumperDP (with which my dumper is registered), not from my dumper.

The relevant paper PRM pages are 3-654 and 3-674.

It’s as if the MiscOp isn’t being passed on by PDriverDP, or not passed on correctly.

Would anyone else like to try that BASIC one-liner, with whatever variations you like, and tell me if you get the same results?

The ultimate point of the exercise is to find a way to tell PDumperIPP the IP address or DNS name of the printer it should be communicating with.

I can add that, if I set R2 to strip type 5:

SYS &8015A, &80000100, 26, 5

the “Bad strip type” error message doesn’t occur, but my MiscOp handler still doesn’t get called.

Would anyone else like to try that BASIC one-liner, with whatever variations you like, and tell me if you get the same results?

If you send me your driver, sure.

It has no observable effect with the LJ6 driver.
Doesn’t seem to do anything with SPrinter either.

Am I doing this right? I select a printer, then I enter SYS &8015A, &80000100, 26 into a TaskWindow.

Oh….. it’s worse than that. It’s not just that the dumpers don’t use the MiscOp. PRM3-675 says “The current Acorn printer system does not use this call; if this reason code is used, current printer drivers merely return the call with all registers preserved.”

So, the point of documenting this call is what, exactly?

The test app is BASIC. But I can send you the dumper, sure.

Edit: you have email.

Edit: forgot to say, to see any response from the dumper, you’ll have to have Reporter running.

So, the point of documenting this call is what, exactly?

I think the point is the PDriver can use this call and dispatch it, but the current Acorn PDumpers don’t make any use of it.

I am leaving the computer now, need to bag up the rubbish for tomorrow, take the bin half a kilometre up the driveway, and… I think I’ll make Quaker Oats for dinner. Quick and easy.

But, before I go, I’ll leave you with the driver dispatch code:

miscop_decode ROUT

        Debug   Configure,"Reason code",R0

        BIC     R0,R0,#TopBit                   ;Convert to useable reason code

        CMP     R0,#(PDumperMiscOp_DumperSpecific -PDriverMiscOp_DriverSpecific)
        BLT     miscop_ours                     ;If not greater than the to dumper threshold then handle

        Debug   Configure,"Attempting to direct at device"

        Push    "R9,LR"

        TEQ     R10,#0                          ;Is there a job currently?
        BNE     miscop_tojob

; We could use conditional coding here, but because the device may corrupt
; the flags and possibly R10 it is safer to have two specific cases.

        MOV     R11,#PDumperReason_MiscOp
        BL      CallPDumper                     ;Despatch to current global PDumper
        Pull    "R9,PC"                         ;And return allowing flags and registers through

miscop_tojob
        MOV     R9,#PDumperReason_MiscOp
        BL      CallPDumperForJob               ;Direct at the current job (R10 -> record)
        Pull    "R9,PC"                         ;Return allowing flags and registers through

miscop_ours
        CMP     R0,#(%10-%00)/4                 ;Is the reason code valid?
        ADDCC   PC,PC,R0,LSL #2                 ;Yes so despatch
        B       miscop_invalid
00
        B       miscop_addpdumper
        B       miscop_removepdumper
        B       miscop_getpdumperstriptypemask
10

So, it looks like behaviour is different depending upon whether or not there’s a print job in progress.

Perhaps that might be the answer? Start a job, then send whatever information is necessary in the preamble?

Doesn’t the fetcher sort out the content length for itself from the size of the data given?

No, it doesn’t! It does rewrite the incoming Content-Length of a response in some circumstances.

Apologies, I was wrong again. For POST, PUT and other methods that require a body, the AcornHTTP module adds a Content-Length if there is none present, unless there is a Transfer-Encoding header, in which case it leaves it alone.

If the client has supplied a Content-Length then the value is corrected if the value is longer than the body of the supplied block of data. If the Content-Length value is less than the size of the supplied block, the value is not corrected.

If the client supplies Content-Length for GET, HEAD or any other method that must not have a body, the header is removed.

Link to source

Hmm… just the driver module.

Okay, I give up for today.

I hacked the DJ850C driver to refer to the IPP driver. But when creating a test (to file), it begins <esc>%-12345X, so it’s still working in PCL mode.

Without being able to select the driver, I can’t see if it responds to MiscOp… or not.

I was looking at the same code. It would take me a long time to build a mental model from it, though.

Perhaps that might be the answer? Start a job, then send whatever information is necessary in the preamble?

Problem is, jobs are single-tasking. I can’t issue a MiscOp while a job is in progress, AFAICS.

If all else fails, my dumper is a relocatable module, so I would be perfectly able to implement SWIs in it.

Rick: yes, another thing I didn’t think about because I’ve taken it for granted for so long…

You’ll need a Printer Definition File that refers to module number 26.

Here are the top few lines from the PDF that I use:

# PrData file for 'Generic IPP**', dp class
cl: dp
pr_nme: Generic IPP**
sh_nme: Gen-IPP
sp_nme: gutenp_ij
res: 3
 g_mode:
  module: dumpers:
   number: 26
   name: PDumperIPP
  palette: 0
  options: 1024
  pxres: 150
  pyres: 150
  data: 
  flags: 83886081
  gname: 150x150 DPI
  gcalib:
  data1: Generic IPP
  data2: 150dpi

The module number 26 is in line 9.

I’ve been using Gutenprint for years, so I really don’t know whether it looks the same on a vanila RO system.

The module number 26 is in line 9.

Clearly, IPP is going to be the easy part.

The hard part? Getting RISC OS to work with it.

I’ve put the driver in !Printers.PDumpers with the others.
Start Printers.
Double-click on a PrDefFile containing what you have specified above.

“Module not found”, at which point the entire Printers app keels over dead (great going, Acorn, wonderful job!).

I have consistently found the printing system… shall we say, fragile.

The hard part? Getting RISC OS to work with it.

Agreed. The architecture is top-down, with the dumper at the bottom, merely doing the very mechanical operation that it is told to do; and it assumes that communication with the printer is fire-and-forget.

And then there’s the problem of getting information from the PDF that the dumper needs.

And then there’s the problem that the MiscOp doesn’t appear to work as documented.

And there’s the question of what should interrogate the printer for its capabilities, and how that information might make its way to the PDF. PDumperIPP has to implement IPP, so it’s in a good position to feed back information for use in creating or editing a PDF, but there’s no way in the present architecture to feed anything back. The implementation of IPP would have to be duplicated in some other entity.

I’ve had a look at the non-squished Printer Manager a couple of times, but it’s challenging. It was clearly written by a mind or minds very different from my own. And it’s very big; it cannot have a line increment of 10. There are no meaningful comments.

That would be the obvious place to add a new connection method (LAN), but, although I’ve edited the templates and extended the animation of the UI, I can’t see how to proceed from there.

And then there’s the problem […] And then there’s the problem […] And there’s the question

I think the current setup is showing the legacy of You have printer X. It can do Y. Here’s a driver.

Suddenly, we have printer A-and-a-half and it might be able to do C but the other one prefers B, and it’s the same driver for all of them.

That would be the obvious place to add a new connection method (LAN),

I noticed in the connection settings there is a USB option. I wonder who patched that in? Does the changelog show anything? (better yet, a diff of before and after?).

The implementation of IPP would have to be duplicated in some other entity.

You answered this question earlier – it’s a module, it can provide its own SWIs. ;)

So here is a crazy idea…

If the Printers application is a total nightmare, then how about forgetting all about it?

Remember RISC OS 2, where we had a bunch of different ‘PrinterXX’ applications? They provided the correct API to the user applications, but left the detail!to themselves. I am sure there was common code between them, but there doesn’t have to be.

You could escape the limitations and/or insanity of Printers, by just forgetting about it.

I appreciate that this would cause other problems. :)

It sounds good, but at some point my energy and determination will give out and I’ll want to move onto something else.

It’s such a basic question, but: how do I cause the printing system to request printing of strip types other than 5?

I’ve tried printing a monochrome Drawfile, a Sprite created with just 2 colours, and I’ve put the desktop into 256 grescale, but all the print jobs give my dumper strip type 5.

but all the print jobs give my dumper strip type 5.

Surely it’s not the input, it’s the output. Consider printing a colour DrawFile to a monochrome laser.

I think you need to have your driver support different strip types, and a way of selecting which to use.

Surely it’s not the input, it’s the output. Consider printing a colour DrawFile to a monochrome laser.

Very good point, thank you. Now where do I find a PDF for a monochrome printer, so I can work out how to fill the “Quality” icon of the Printer Manager’s Configuration window with anything other than “Colour, diffused”?

I think you need to have your driver support different strip types

Yes

and a way of selecting which to use.

Why would the dumper do anything other than process the strip type it’s given? Or do I misunderstand you?