Canon imagePROGRAF iPF770

I’ve been asked about connecting to a Canon imagePROGRAF iPF770 A0 printer on RISC OS. It apparently supports the GARO, HP-GL/2 and HP RTL (apparently a subset of PCL) printer languages. Are there any existing solutions that might work with this printer?

<Googles model number> Oh. My. God.

Do you know if it supports IPP or AirPrint?

[ Dave – uh – huge page sizes? ]

Ooh lets do this. I’d start with this one:

PCL is somewhat variable, but the RO printer drivers are not sophisticated.

[ Dave – uh – huge page sizes? ]

The likeliest limit is file size, if the resolution is also very fine.

The modules only translate a row of pixels at a time, into a buffer reserved by malloc(). Although this could fail for lack of available RAM, I think it’s a less likely limit than file size.

[ Dave – uh – huge page sizes? ]

We had one that size at work, and replaced it because it was too small :)

Medical Illustration dept, late 1990s. Can’t recall what the make or model was.
I do recall it being Postscript driven though. Damned expensive too as I recall.

I did the installation of the mega PC workstation and printer apparently¹, but it was in the weeks just after my father died, and that time period is rather vague or blank in the memory banks.

¹ When tasked with doing the second setup about 4 months later “because you did the other one” I looked at people in disbelief. NT4 with drivers that were much happier with Win95

Dave divined

The modules only translate a row of pixels at a time, into a buffer reserved by malloc(). Although this could fail for lack of available RAM

The biggest problem with the PCL (LJ) dumper is that even when ‘compression’ is selected for a printer, it uses PackBits which can only achieve a 128× compression in the simplest of cases. So it’s not so much the page size as the complexity of the data on the page that balloons the output.

If it used Delta or Adaptive it could seriously reduce transmission and print time as well as file size – and the slowness of empty bits of the page is an indicator of the inefficiency of the ancient compression scheme used.

I think it’s a less likely limit than file size.

An A0 at 300dpi is 139MP, so in B&W that’s only 17MB uncompressed. It’s a rather more unpleasant 400MB in 24b colour though.

But in practice large parts of the page are blank, and the driver ought to skip them. But the PackBits method doesn’t help there in the way that the Delta and Adaptive command sets do.

I’d expect the Gutenprint drivers to be more sophisticated (didn’t MW & JT do them for RO?).

Ooh lets do this. I’d start with this one:

I’ve given this one a go, and it does partially work when connected via USB. It doesn’t seem to handle colour properly though, and the largest page size I was able to select is A2, which resulted in the document I tried being printed in one corner of the A0 page. Any suggestions on how to proceed would be appreciated.

Page sizes are easily customised using the !Printers interface, that’s not a Driver (or Print Defintion) matter. Just click menu on !Printers and select “Edit paper size”, type in your dimensions and name and Save.

It’ll be slow, because this is a “Dumper” type printer driver, which simply sends a bitimage of the page to the printer. This is to avoid having to create PCL fonts (various incrementally-defined bitimages or vector formats), HPGL2 vector graphics and PCL5 images more like the PostScript driver has to. So expect your A0 to go four times slower than your A2.

As for colour, I see that PrintDef supports small and large halftones and diffused (which is probably the one you’d want). That’s all the choices you get from RISC OS’s early 90’s print technology.

Page sizes are easily customised using the !Printers interface, that’s not a Driver (or Print Defintion) matter. Just click menu on !Printers and select “Edit paper size”, type in your dimensions and name and Save.

Thanks, that seems to have done the trick.

As for colour, I see that PrintDef supports small and large halftones and diffused (which is probably the one you’d want). That’s all the choices you get from RISC OS’s early 90’s print technology.

I already had diffused selected, so the lack of colour might be due to something else.

so the lack of colour might be due to something else.

Colour palette selection of what the printer expects in the way of codes vs. what the driver is sending, which maybe an older definition? Chapter 9 in the Guide?

Do you have any more information on how to handle this in PrintEdit?

One additional thing I’ve noticed is that when printing to a file using that driver and converting it using Ghostscript, the end result is also in black and white, which suggests that the issue isn’t specific to this printer.

You need to tick ‘Colour’ in the PS3 print driver config. JPEGs seem to go through in colour whatever the setting but a coloured Draw graphic will be bw if there is no tick.

You need to tick ‘Colour’ in the PS3 print driver config. JPEGs seem to go through in colour whatever the setting but a coloured Draw graphic will be bw if there is no tick.

I’m using the LaserJet dumper rather than PostScript (using the definition nemo recommened), and the colour options there don’t make a difference. For reference, I’m using Ghostscript 9 from PackMan, and am using the following command to convert from PCL to JPEG (sorry if I wasn’t clear enough about this):

gpcl6 -dNOPAUSE -dBATCH -sDEVICE=jpeg -sOutputFile=JPEG Printout