Mobile Printing Before AirPrint: PictBridge, Infrared, Bluetooth, and Email-to-Print

The protocol was not the missing piece

The natural way to tell this story is as a waiting period — a decade in which the necessary technology did not exist, ending when it finally arrived. The standards record does not support that shape. The Printer Working Group dates its Internet Printing Protocol project to November 1996; IPP/1.0 was published as experimental RFCs in April 1999; and IPP/1.1 was issued as an IETF Proposed Standard in September 2000 as RFC 2911, obsoleting RFC 2566 and later obsoleted itself by RFC 8011. By the autumn of 2000 there was a published way to submit a print job across a network without installing anything specific to the printer at the far end. Almost nothing portable used it for the next ten years.

The Printer Working Group's own retrospective supplies the structural reason, and it is about software distribution rather than networking: mobile devices' "small, lower-cost form factor, including memory size, does not allow for the inclusion of device-specific drivers." A desktop operating system had solved printing by accumulating drivers; a handheld could not, and nothing obliged printers to be usable without one. Mobile printing therefore grew as "vendor-specific apps and with little standardization." The interesting question is not whether an adequate protocol existed, but why an available one sat idle while five separate families of workaround grew up around it.

Cameras: an order file, then proprietary sessions, then a standard

The earliest of these mechanisms transmitted nothing at all. The Digital Print Order Format, developed by Canon, Eastman Kodak, Fuji Photo Film and Matsushita, writes a print-order file onto the camera's memory card: a record of which images to print, at what sizes and quantities. The card then goes to a photo lab or into a card slot on a printer that can read it. DPOF is generally dated to 1998, and trade press of the time reported a joint announcement of version 1.10 on 17 July 2000. Its mechanism is the part worth holding onto — an instruction sheet travelling with the media, a solution to selection rather than to transfer.

Live camera-to-printer sessions arrived next, and arrived fragmented. Canon's own patent record documents a protocol it called NCDP, for New Camera Direct Print, layered on Picture Transfer Protocol over USB (US7719706B2, priority 4 June 2002). Canon shipped other direct modes under other names, and other manufacturers shipped their own. Trade coverage of the era mixes these names freely.

The fragmentation was admitted by the standard that ended it. The Camera & Imaging Products Association's announcement of 3 February 2003 states that the specification had been "Originally proposed last December as 'DPS'" — December 2002 — by Canon, Fuji Photo Film, HP, Olympus, Seiko Epson and Sony, and adopted by CIPA as DC-001-2003 under the name PictBridge. The release is blunt about the motivation: "Until now, each company had its own proprietary solution for direct printing between digital still cameras and printers," an arrangement that had "proven to be limiting ease of use when using different product combinations and brands."

PictBridge is also the most consistently misdescribed item in this history. DC-001 specifies USB as the physical transport and Picture Transfer Protocol for the data exchange, with the camera driving the printer's interface rather than the reverse. It is not wireless: the picture-transfer-over-IP path is a separate and later CIPA standard, DC-005-2005, published in November 2005. And it is a camera standard, so a phone listing PictBridge support was borrowing a camera mechanism rather than joining a mobile printing ecosystem — there was none to join.

Infrared: a real printing path with a geometry problem

Infrared printing is often written off as something that never really worked, which understates it. The Infrared Data Association is conventionally dated to 1993, with its first specifications — SIR, IrLAP and IrLMP — published in June 1994; the two are frequently swapped for one another, and no specification page is cited here for either. And there was a genuine printing protocol in the stack, documented in a mainstream operating system's own manuals rather than in a vendor pamphlet.

Microsoft's Windows 2000 Server documentation names the pieces individually. IrLPT is "the protocol support that is used by IrDA Print Monitor" and "enables printing directly from IrDA devices to IrDA printers." IrCOMM provides serial and parallel port emulation for applications that expect a port. IrTran-P handles bidirectional image transfer and was receive-only in that release, described there as "used for cameras with infrared capability." Later accounts routinely merge the three; only IrLPT is the one that means printing.

What defeated infrared was its physical layer, not its protocol design. The link needed an unobstructed sightline between two ports held close together and roughly aimed at each other, and survived only as long as that geometry held — which made printing a posture, a handheld held still at the right height and angle for the duration of the transfer. Published figures for range, beam angle and data rate vary between sources and between specification versions, and none is quoted here. The technology is best described now as dormant and superseded; a formal dissolution of the association is not something this page can verify, and it claims none.

Bluetooth: the profile that existed and the profiles that got used

Bluetooth looks, at first, like the answer infrared could not be: no sightline, no aiming, a few metres of tolerance. The Bluetooth SIG even adopted a profile built for the job — the Basic Printing Profile, defining Printer and Sender roles, operating over the core specification from version 1.0B onward, with a mandatory errata correction for compliance. On paper, phones printing over Bluetooth used BPP.

Manufacturer documentation points the other way. Canon's online manual for printing from a mobile phone over Bluetooth specifies the Object Push Profile or the Basic Imaging Profile — generic mechanisms for pushing an object or an image at a device, not printing protocols. A companion page of the same manual extends the identical constraint to PDAs and digital cameras. The everyday experience of Bluetooth printing was therefore not a print job at all but a file handed over in the hope that whatever received it would interpret it as one.

The manual is unusually candid about the consequences, and the sentence deserves quoting rather than paraphrase: "Depending on your mobile phone, you may not perform printing even if your mobile phone supports the profiles above." Around that disclaimer sit the specifics. Photographs were capped in practice — "If the photo file is over 1.8 MB in size, it may not be possible to send the file." Video and downloaded content protected by digital rights management were excluded outright. The printer needed an optional Bluetooth unit bought separately and fitted to its direct print port. Pairing defaulted to a passkey of 0000. Bluetooth printing did not fail for vague reasons; it failed on limits the vendor closest to the problem published on its own support pages.

Server-brokered printing: someone else's infrastructure

The fifth family gave up on the local link and sent the job somewhere else first. This is usually remembered as a 2010 development, which is off by most of a decade. EFI's PrintMe Networks was introduced around late 2001 — one release-derived trade report places the debut on 22 October 2001, while a second EFI announcement of the service going live carries a different date — offering driverless remote printing to a network of public printers, explicitly marketed for PCs, PDAs, two-way pagers and cell phones, with rollouts at print shops and hotels. PrinterOn likewise dates its service from around the same period.

By 2010 the model had a mass-market face and a naming problem. Computerworld reported on 21 April 2010 that HP had unveiled a BlackBerry application backed by HP middleware, routing jobs onto PrinterOn's public-printer network at hotels with further venues planned, where the recipient released the job by entering a security code at the machine; commercial launch was set for that June, and the service explicitly covered printers that were not HP's. That product shares the ePrint name with a consumer feature giving a web-connected home printer its own email address, with later applications, and with the "ePrint enabled" printers repurposed as launch hardware for driverless printing from Apple devices. Any date attached to the name is meaningless without saying which is meant.

Google's entry belongs to the same family and gives away the era's real constraint through its architecture. A Chromium Blog post of 7 June 2010 carried an update on Google Cloud Print. Its design routed jobs through a connector program running on an internet-connected computer attached to the printer. That indirection existed precisely because the printers could not participate in the exchange themselves. Server brokering worked, which is why it lasted — but it made every document a round trip through a third party, contingent on an account, a network path and a company's continued interest in running the service. The archive's account of cloud print architectures follows how that pattern was later absorbed and discarded.

The vendor app, and the habits it produced

The last stage before the era closed was the per-brand application. The Printer Working Group's retrospective describes it without much affection: "printer makers got smart and created apps that supported their brand devices. An Epson app let users print to their Epson printer and the like." The same account records what people did when no app fit — users "emailed themselves links, bookmarked pages and did all sorts of strange things to remind themselves to print" later, from a computer. Its verdict is that the industry was "asking them to install all kinds of apps, which might or might not work well, and to keep updating them, signing in and in general presenting a number of hurdles." These posts are a standards body's blog rather than a specification and their tone is promotional, but as testimony about the state of practice they remain the sharpest description available. HP's photo printing application for early iPhones belongs to that stage; this page attaches no date and no first to it.

The boundary: 15 September 2010

Apple's press release of 15 September 2010 announced wireless printing for its handheld devices, quoting Phil Schiller on the intended experience: "no set up, no configuration, no printer drivers and no software to download." It named HP's ePrint-enabled Photosmart, Officejet, Officejet Pro and LaserJet Pro lines as the launch printers, and promised something further — printing to printers shared through a Mac or PC.

Two corrections attach to that document, and both matter more than the announcement. The first is that nothing new was invented at the protocol layer. Apple's own Bonjour printing specification describes multicast DNS service discovery feeding job submission over IPP, and the Printer Working Group's guide to IPP notes that printers in Apple's programme use an Apple raster format where IPP printers generally accept PDF, PWG Raster and JPEG. What shipped was IPP submission, Bonjour discovery and a mandatory raster fallback: a compulsory profile over a ten-year-old standard, backed by operating-system ubiquity. That is what had been missing, and it is not the same thing as a new protocol.

The second is that the September release does not describe what arrived. Macworld and other trade press reported in November 2010 that the shared-printer path had been removed from desktop operating system seeds and from developer documentation ahead of release, with no public explanation, and that third-party utilities appeared to fill the gap. No primary statement exists to cite on the reversal, which is itself part of the record: announcement and shipped behaviour differ, and quoting the former as a description of the latter is an error the sourcing will not support.

1. November 1996

   The Printer Working Group's Internet Printing Protocol project begins.

2. April 1999

   IPP/1.0 is published as experimental RFCs.

3. September 2000

   IPP/1.1 is issued as an IETF Proposed Standard in RFC 2911.

4. Around late 2001

   EFI introduces PrintMe Networks for remote printing to public printers; reported launch dates differ between releases.

5. June 2002

   Canon files the patent documenting NCDP, its proprietary camera direct-print protocol over PTP and USB.

6. December 2002

   The specification later known as PictBridge is proposed as DPS.

7. 3 February 2003

   CIPA announces adoption of the specification as DC-001-2003, PictBridge.

8. November 2005

   CIPA publishes DC-005-2005, the separate picture-transfer-over-IP standard.

9. April–June 2010

   HP's BlackBerry printing service and a Google Cloud Print update arrive; both route jobs through third-party infrastructure.

10. 15 September 2010

    Apple announces driverless wireless printing for its handhelds; this article's window closes here.

What actually changed

Set the five mechanisms side by side and they share one shape. In every case the printer was a passive endpoint. It could be reached through a cable, through a beam aimed at its front panel, through a separately purchased radio adapter, or through a company's servers — but not by a portable device speaking a standard protocol on a shared network, because nothing obliged it to listen for one. The workarounds were not substitutes for a missing protocol. They were substitutes for a missing capability in the machine at the other end.

That is why the decade ended as it did, rather than with a better radio or a faster link. The phones of 2010 were not dramatically better at printing than the phones of 2006; the printers were. The change was that a printer began advertising itself on the network it was already attached to and accepting a standard job with no driver installed anywhere — behaviour specified since 2000 and simply never required of anyone. Anything sold today as a smart printer is the descendant of exactly that capability, and reading the category that way — as the thing five generations of workaround were improvising around — explains both why those workarounds looked so awkward and why they vanished so completely once the printer itself changed roles. The archive's history of wireless printing follows the network side of that arc, and its reference on the Internet Printing Protocol covers the specification itself.