↑↑ Home ↑ Hardware  

The HP DesignJet T230 large-format printer and URF format support

Introduction -- Printing -- JPEG -- URF -- PJL ? -- Print quality -- Firmware crashes -- Storage -- References

Mini-Review and hacker's guide


The HP DeskJet T230 is a 24 inch large-format printer that can hardly be called cheap but is still affordable for a private citizen. I bought it for printing nice images from the web to hang in my flat and for printing my own maps.

Using FreeBSD on my main computer, I print using the printer's natively supported formats rather than spooling software: CUPS does not support it, the vendor software is unlikely to be BSD compatible, and in any case going low-level saves you from messing around with hugely complex know-it-all software, forced updates and end-of-life deadlines.

Turns out the problem was not so much low-level access as such, but the fact that this printer type (like so many products today) has not completed development before being sold.


Like many network printers, the T230 receives files to be printed on TCP port 9100. Transmitting the file is most simply done with a variant of the netcat program, often called nc. I use socat:

socat -u file:/path/to/file tcp:printerIP:9100

The T230 is documented as supporting two image formats natively, JPEG and URF:


JPEG images are scaled up to an aspect ratio of 1:√2 fitting inside the current paper size by the printer. When using 24" paper rolls, this means > 90 cm of paper is used up. If you happen to want to print a poster of that size from a JPEG file, or use a smaller paper size you want to fill completely, that is a viable option. If you want to print variously sized images on roll paper, it is not.


The URF data format seems to be documented nowhere, but some programs supporting it can be found (ppm2pwg and urf2image) , allowing it to be reverse engineered. It can contain multiple images, with print quality and paper source settings for each. I have only ever used it for single images.

So here is the first ever URF spec on the web (offsets in hexadecimal; enumerated constants are sequential unless value is specified):

7 bytes "UNIRAST" + 0 byte
big endian 4-byte page count (may be 0, which is treated as 1)
bits per pixel in the pixel data below, e.g. 24 for colour with 8 bits per channel
colour space (sGray=0, sRGB, CieLab, AdobeRGB, Gray32, RGB, CMYK)
duplex (no=0, short side, long side)
quality (default=0, draft=3, normal, high)
T230 note: setting this to "high" will crash the printer firmware
media type (auto=0, stationery, transparency, envelope, cardstock, labels, stationery letterhead, disc, photographic matte, photo satin, photo semigloss, photo glossy, photo high gloss, other)
media position (auto=0, main, alternate, large capacity, manual, envelope, disc, photo, hagaki, main roll, alternate roll, top, middle, bottom, side, left, right, center, rear, bypass tray, tray1 .. tray20, roll1 .. roll10)
6 bytes 0
big endian 4-byte image width
big endian 4-byte image height
big endian 4-byte resolution in DPI
T230 note: will be rounded up to nearest of 75, 150, 300, 600, 1200 DPI, so images may come out smaller unless one of those is chosen
T230 note: setting this to > 1200 will crash the printer firmware
8 bytes 0
pixel data

For multiple images, the fields from offset 0C are repeated.

The pixel data are encoded in a simple run-length compression scheme that is the same as in the PWG (printer working group) raster format and documented in section 4.4 (page 23) of the PWG raster format spec:

I have always set media type and position to auto and colour space to sRGB. Considering the flaky nature of the printer firmware, experimentation is likeyly to reveal more crashing bugs.

For simplicity and lack of unnecessary dependencies, I have written my own small Perl script printurf.pl for converting images to URF and optionally transmitting them directly to the printer. In "testing" mode it has no dependencies other than the Perl interpreter but supports only PPM images (which you can save with most image processing programs).

In its usual operation mode, it requires GraphicsMagick and accounts for quirks of the DesignJet T230 printer. The image to print is resized as needed to a supported DPI setting. A white margin is added so the image is not cut off. (The T230 can print up to the side edge of the paper but not to the starting edge; and the raster data are not aligned with those edges but cut off.)

Another small Per script urfcheck.pl checks URF format correctness, outputs header information and converts back to PPM.

These scripts come with no warranty whatsoever, especially considering the flaky nature of the printer's firmware.


The header of firmware update files contains commands in HP's Printer Job Language (PJL), so apparently the T230 understands it. The PJL manual does not mention any DesignJet T### printers, so it is not known which commands it supports. I have not experimented so far but may add the information if I get round to it.

Print quality optimisation


The T230 seems to print colour a bit warmer (more red and yellow) than waht I see on my monitor. Also, when I bought the printer, colours were off because I could not select the right paper type due to a firmware bug.

In order to correct the colour before printing, I used a simple prcedure to determine red, green and blue gamma values. Print a copy of the image (possibly reduced) and hold it up to your monitor. Then adjust the screen gamma correction values until the colours of the displayed image match the printout. On Linux/BSD systems with X11 graphics, you can use xgamma to adjust the screen gamma correction on the fly. On other OSes you may have to test transform the image under investigation and display the version with modified colours.

In order to compensate for the differences between monitor and printer colours, perform a gamma correction with the inverses of the RGB gamma values that make your screen match the printer colours. Use this GraphicsMagick command to gamma transform with separate exponents for each colour channel:

gm convert srcimage -gamma 0.91/1.18/1.4 destimage

Be aware that there are conflicting definitions of how to interpret the gamma parameters depending on whether a forward transform is done or a compensation for device properties and whether the maximum pixel value or the value 1 is fixed. This is rarely adequately documented, but the direction of the effect can easily be checked visually.


In some printing modes, stripes of ~ 30 mm are printed at a time. This can give rise to perceived bright or dark lines across the image when the stripes overlap slightly or there is a slight gap. Paper advance calibration may be expected to help but did not always. This may have been due to a firmware bug forcing me to choose the wrong paper type.

Also sometimes the first stripe of an image printed had a slighly different colouring. This may be due to differences between ink retained in the print head versus ink fresh from the cartridge.

Other notes

Printed images can end up slightly larger or (rarely) smaller than one would compute from the image size and DPI setting, by up to ~ 2%. Test print and measure before you rely on the size.

Firmware crashes

HP DesignJet firmware is being (not: has been) developed by underpaid folks in faraway countries who have not heard of fuzz testing, so users are going to become familiar with images like this on the printer's screen:

This requires resetting the printer by pulling the power plug.

My first encounter with the nature of the printer firmware after receiving the printer was when setting a "coated" paper type and printing images upward of a certain size in URF format.

Support is not bad as those things go (though HP restricts it to one year after an arbitrary-seeming date a few months before purchase). Communication is restricted to phone, with nice support personnel without any technical knowledge following a wetware program. Firmware crashes not susceptible to a certain reset procedure warrant sending a technician on site to change the mainboard.

The equally nice and in addition technologically competent service tech did a bit of trial and error with me and concluded reasonably that a hardware swap does not fix software bugs. He even managed to convince the (technologically illiterate) support personnel to accept that (since I agreed with him). With the help of a test case URF file from me, two weeks later a new firmware version was available that fixed the problem.

This seems like competent and prompt help until you realize that it could have been completely avoided by proper testing before going on sale. It is worth mentioning that the same firmware is used by the whole DesignJet T200-T600 range and DesignJet Studio.

As detailed above, firmware crashes are also caused by setting the print quality to "high" in the URF header and selecting a print resolution larger than supported by the printer.


Inkjet printers can dry out if kept unused for too long. Printing a test page every few months is probably a good idea. Still, there are other precautions that can at least help, and I am surprised they seem to be mentioned nowhere on a tech forum.

The ink of inkjet printers is water-based, and if it dries out in the print head it has to be cleaned or (expensively) replaced. When the printer is turned off, the carriage with the print head is in a parking position where it is not as exposed as during printing. So at the very least make sure you shut down the printer properly before a storage period.

Besides, evaporation is increased by a warm and dry environment and by ventilation. So storing the printer somewhere cool and somewhat humid will help. So will sealing the printer in a large plastic bag. I cover mine with the plastic bag from its packaging whenever not in use, which reduces air circulation to and from the printer.


Licensed under the Creative Commons Attribution-Share Alike 3.0 Germany License

TOS / Impressum