# Aros/Developer/Docs/Devices/Printer

* Navbar for the Aros wikibook
* Aros User
* Aros User Docs
* Aros User FAQs
* Aros User Applications
* Aros User DOS Shell
* Aros/User/AmigaLegacy
* Aros Dev Docs
* Aros Developer Docs
* Porting Software from AmigaOS/SDL
* For Zune Beginners
* Zune .MUI Classes
* For SDL Beginners
* Aros Developer BuildSystem
* Specific platforms
* Aros x86 Complete System HCL
* Aros x86 Audio/Video Support
* Aros x86 Network Support
* Aros Intel AMD x86 Installing
* Aros Storage Support IDE SATA etc
* Aros Poseidon USB Support
* x86-64 Support
* Motorola 68k Amiga Support
* Linux and FreeBSD Support
* Windows Mingw and MacOSX Support
* Android Support
* Arm Raspberry Pi Support
* PPC Power Architecture
* misc
* Aros Public License

## Introduction

AmigaDOS 3.1 (which AROS is modeled after) didn't have any standard printing dialogs like you are probably used to seeing under other OSes for selecting which pages to print of a document, choosing landscape mode vs portrait, paper sizes, paper types, duplex mode, print preview, etc. Every program has to roll its own to interface with the printer prefs for these things.
Under AmigaDOS 1.x-3.1 each and every application program has to do its own support for high resolution, high quality printing because the graphics display and printing API didn't have any resolution independence built in creating and displaying a drawing command list and then converting that to a structured drawing format or language output including logos or fonts, etc. (unlike MacOS or Windows).
Under AmigaDOS 1.x-3.1 printing consisted of a primitive printer.device which only understands ANSI formatted text and a few types of graphics rastport binary data, and consulted the printer, printergfx, and printerps preferences to decide how to handle printing to either a bitmap oriented printer, an ANSI sequence text printer, or by feeding raw data (generated independently by each individual program that wanted to print raw). Each printer would have a custom device file made for it to switch modes from text to graphics (translating from internal Amiga graphics or text format to something the printer liked) and do things like form feed, set margins, etc. and printer.device would (by the printer prefs) decide which port to send that data to, check for errors while printing, etc.
AROS, at the moment, does support translating any text and pictures into Postscript (.ps) files which can then be saved as a file or printed to a limited range of printers.

### Use the existing printer.device API

* PRD_RAWWRITE send unprocessed data to printer
* PRD_DUMPRPORT (IODRPReq->ioCommand) send rastport to printer
* PRD_QUERY (IOStdReq->io_Command) in what state is the printer port
* PRD_PRTCOMMAND (IOPrtCmdReq->ioCommand) send ANSI escape sequence to printer via CMD_WRITE (unsupported)

### Writes its output to

* A filename specified by the user (via prefs or a pop-up)
* A pipe to another program (via prefs or a pop-up requester)
* The output is PostScript Level 2 (or lower)
* Select page size as A4, Letter, or custom (in inches or mm)
Status:
* printer.device is ~99% code complete
* L:port-handler is code complete
* C:Print is code complete (print via Datatypes)
* DEVS:Printers/PostScript is ~95% code complete
Features:
Known issues:
* Almost all of the printer drivers with source code that could be found have a big "Copyright (c) 19xx Amiga" at the top. Hopefully people can use the PostScript and Skeleton drivers to write printer drivers with better licenses.

## References

See 2View src
Read more about printer driver and more printer drivers
Also take a look at TurboPrint's printer.device API extensions. It used to be the de facto standard for many years before v44. Documentation can be found here. Actually, the AROS printer.device already supports all the CyberGfx bitmap formats, and every screen mode. Sure. But TurboPrint also extended printer.device with its own command. If you are interested by 68k binary compatibility, this may be an easy addition as it's very close to CBM's DUMPRPORT command.
The way it works is that it does all scaling into an AllocBitmap 'friend' of the source bitmap, and uses the CyberGfx ReadPixelArray to get BGR032 pixel lines from that. BGR032 is the same format that the printer drivers use internally (unless inverted for YMCK purposes), so no additional transform is needed there. The only thing io_Modes is used for is to get the display's aspect ratio. I haven't tested printing HAM6 or HAM8 images, but I don't know of a test program for that, either. I suggest example program from Turboprint SDK and Ghostscript 68k (old 5.x, included in TurboPrint and new one). Both have sources available. ArtEffect has support for Turboprint also and my Scandal too (aros x86 version also but you must have some supported scanner to get data to be printed :))
commit 43799 restructured to allow future printer drivers.
The error is found in io_Error.