|
|
Home | Alpha Telephone | Domain Names | Web Hosting | Get Traffic | xrEvidence | xrSoccer United States Patent
Memory configuration in a printer that simultaneously prints on both surfaces of a sheet of print media A printer, configured to simultaneously print on both surfaces of a sheet of media includes a first memory configured to receive, from a host system, descriptions of all pages to be printed on the surfaces of the sheets of print media and a second memory. First and second print engines are configured to print on first and second surfaces of the print media, the first print engine receives descriptions of pages to be printed from the first memory and the second print engine receives descriptions of pages to be printed from the second memory. A first controller is configured to transfer descriptions of pages to be printed by the second print engine from the first memory to the second memory.
CROSS REFERENCE TO RELATED APPLICATION This is a Continuation Application of U.S. application Ser. No. 09/459,409, filed on Dec. 11, 1999 now abandoned of which is herein incorporated by reference. We claim: 1. A printer, configured to simultaneously print on both surfaces of a sheet of media, including: first memory configured to receive, from a host system, descriptions of all pages to be printed on the surfaces of the sheets of print media; a first print engine configured to print on a first surface of the print media, the print engine receiving descriptions of pages to be printed from the first memory; a second memory; a second print engine configured to print on a second surface of the print media, the second print engine receiving descriptions of pages to be printed from the second memory, and a first controller configured to transfer descriptions of pages to be printed by the second print engine from the first memory to the second memory. 2. The printer of claim 1 wherein the first controller also controls the first print engine. 3. The printer of claim 1 including a second controller that controls the second print engine and wherein the first controller also controls the first print engine. 4. The printer of claim 1 including a removable first print module that includes one of the first and second print engines. 5. The printer of claim 4 including a removable second print module that includes the other one of the first and second print engines. 6. The printer of claim 4 wherein the first print module includes at least the first print engine and first memory. 7. The printer of claim 4 wherein the first print module also includes the first controller. 8. The printer of claim 1 including a removable first print module that includes the first print engine, the first memory and the first controller and a removable second print module that includes the second print engine and the second memory. 9. The printer of claim 3 wherein the first controller is a master print controller and the second controller is a slave print controller operable under command of the master print controller. 10. The printer of claim 1 including a first communications link through which said data is transferred to the second memory. 11. The printer of claim 10 in which the first communications link is a bi-directional link. 12. The printer of claim 1 including a second communications link for receiving print data from the host system. 13. The printer of claim 12 configured to present a unified view to the host system to mask the presence of the slave controller. 14. The printer of claim 1 in which the first print engine prints described pages on a rear surface of the print media and the second print engine prints on a front surface of the print media. 15. The printer of claim 3 in which print synchronization is achieved by the first controller controlling the printing operation of the second controller. 16. The printer of claim 3 in which printhead interfaces of both controllers are synchronized to a shared line synchronization signal generated by one of the controllers. FIELD OF THE INVENTION This invention relates to a printing system. More particularly, the invention relates to a controller for controlling printing on both surfaces of a sheet of print media and to a method of controlling printing on both surfaces of a sheet of print media. SUMMARY OF THE INVENTION According to a first aspect of the invention, there is provided a controller for controlling printing on both surfaces of a sheet of print media, the controller including: a first print controller for controlling printing by a page width printhead of a first print engine; a second print controller for controlling printing by a page width printhead of a second print engine substantially simultaneously with the printing by the printhead of the first print engine; a first communications link interconnecting the first print controller and the second print controller for synchronizing the print controllers; and a second communications link interconnecting at least one of the print controllers with a host system for receipt from the host system of descriptions of pages to be printed on said surfaces of the sheet of print media by the print engines. The invention also provides, in another broad form, a printer, configured to simultaneously print on both surfaces of a sheet of media, including: first memory configured to receive, from a host system, descriptions of all pages to be printed on the surfaces of the sheets of print media; a first print engine configured to print on a first surface of the print media, the print engine receiving descriptions of pages to be printed from the first memory; a second memory; a second print engine configured to print on a second surface of the print media, the second print engine receiving descriptions of pages to be printed from the second memory, and a first controller configured to transfer descriptions of pages to be printed by the second print engine from the first memory to the second memory. Preferably the first controller also controls the first print engine. Preferably the printer includes a second controller that controls the second print engine. In this specification, unless the context clearly indicate otherwise the term "page width printhead", is to be understood as a printhead having a printing zone that prints one line at a time on a page, the line being parallel either to a longer edge or a shorter edge of the page. The line is printed as a whole as the page moves past the printhead and the printhead is stationary, i.e. it does not raster. The first print controller is, preferably, a master print controller with the second print controller being a slave print controller operable under command of the master print controller on receipt of signals via the first communications link. The first communications link may be a bi-directional link enabling the transmission of data from the slave print controller to the master print controller. Thus, after the printing of a page, or more frequently, the master print controller may obtain ink consumption information from the slave print controller via the first communications link. The master print controller uses this to update the remaining ink volume in an ink cartridge. Further, the master print controller and slave print controller may also exchange error events and host-initiated printer reset commands via the first communications link. The master print controller may have the second communications link connected to it to present a unified view to the host system to mask the presence of the slave print controller. The master print controller may print described pages on a rear surface of the print media with the slave print controller printing on a front surface of the print media so that the master print controller always has a page buffer available for a page description destined for the slave print controller. Print synchronization may be achieved by the master print controller controlling a printing operation of the slave print controller. Printhead interfaces of both print controllers may be synchronized to a shared line synchronization signal generated by one of the print controllers. According to a second aspect of the invention there is provided a method of controlling printing on both surfaces of a sheet of print media, the method including the steps of: receiving data relating to a first page to be printed in a first print controller of a first print engine; transmitting the data relating to the first page from the first print controller to a second print controller of a second print engine; receiving data relating to a second page to be printed in the first print controller; and controlling printing by the print engines under command of the first print controller to achieve synchronization of printing of the pages by the first print controller and the second print controller on rear and front surfaces of the print media, respectively. In a further broad form, the invention provides method of manipulating print data in a printer capable of simultaneously printing on both surfaces of a sheet of print media, the method including the steps of: receiving first data relating to a first page to be printed in a first memory; transferring the first data from the first memory to a second memory; receiving second data relating to a second page to be printed in the first memory; and simultaneously accessing the first and second data to simultaneously print the first and second pages on both surfaces of the print media. Preferably the receiving and transferring of the first data is under the control of a first controller. Preferably printing of said second data is controlled by the first controller and preferably the printing of said first data is controlled by a second controller. The method may include synchronizing printhead interfaces of both print controllers by means of a shared line synchronization signal generated by the first print controller which is a master print controller. Further, the method may include transmitting data relating to the pages to be printed from a host system to the master print controller by means of a host communications link, the master print controller determining whether or not said data are to be routed to the second print controller which is a slave print controller. The method may also include receiving said data in its entirety in a memory of the master print controller before forwarding it to the slave print controller. The method may include selecting the master print controller to print the rear surface of the print media to ensure that the master print controller always has a page buffer available for a page description destined for the slave print controller. As described above, the method may include, periodically, transmitting predetermined data from the slave print controller to the master print controller. BRIEF DESCRIPTION OF THE DRAWINGS The invention is now described by way of example with reference to the accompanying drawings in which: FIG. 1 shows a front view of a CePrint printer, in accordance with a first embodiment if the invention; FIG. 2 shows a front view of the printer, in accordance with a second embodiment of the invention; FIG. 3 shows a side view of the printer of FIG. 1; FIG. 4 shows a plan view of the printer of FIG. 1; FIG. 5 shows a side view of the printer of FIG. 2; FIG. 6 shows a table illustrating a sustained printing rate of the printer achievable with double-buffering in the printer; FIG. 7 shows a flowchart illustrating the conceptual data flow from application to printed page; FIG. 8 shows a schematic, sectional plan view of the printer; FIG. 8A shows a detailed view of the area circled in FIG. 8; FIG. 9 shows a side view, from one side, of the printer of FIG. 8; FIG. 10 shows a side view, from the other side, of the printer of FIG. 8; FIG. 11 shows a schematic side view of part of the printer showing the relationship between a print engine and image transfer mechanism of the printer; FIG. 12A shows a schematic side view of part of the devices of FIG. 11 showing the printhead in a parked, non-printing condition relative to the transfer mechanism; FIG. 12B shows a schematic side view of the part of the devices of FIG. 11 showing the printhead in a printing condition relative to the transfer mechanism; FIG. 13 shows a schematic side view of the arrangement of the printheads and transfer mechanisms of the double-sided printer of FIG. 2; FIG. 14 shows a three-dimensional, exploded view of a paper drive chain of the printer; FIG. 15 shows a three-dimensional view of the printing system of the printer; FIG. 16 shows an enlarged, three-dimensional view of part of the printing system of FIG. 15; FIG. 17 shows a simple encoding sample; FIG. 18 shows a block diagram of printer controller architecture; FIG. 19 shows a flowchart of page expansion and printing data flow; FIG. 20 shows a block diagram of an EDRL expander unit; FIG. 21 shows a block diagram of an EDRL stream decoder; FIG. 22 shows a block diagram of a runlength decoder; FIG. 23 shows a block diagram of a runlength encoder; FIG. 24 shows a block diagram of a JPEG decoder; FIG. 25 shows a block diagram of a halftoner/compositor unit; FIG. 26 shows a diagram of the relationship between page widths and margins; FIG. 27 shows a block diagram of a multi-threshold dither unit; FIG. 28 shows a block diagram of logic of the triple-threshold dither; FIG. 29 shows a block diagram of a speaker interface; FIG. 30 shows a block diagram of a dual printer controller configuration; FIG. 31 shows a schematic representation of a Memjet page width printhead; FIG. 32 shows a schematic representation of a pod of twelve printing nozzles numbered in firing order; FIG. 33 shows a schematic representation of the same pod with the nozzles numbered in load order; FIG. 34 shows a schematic representation of a chromapod comprising one pod of each color; FIG. 35 shows a schematic representation of a podgroup comprising five chromapods; FIG. 36 shows a schematic representation of a phasegroup comprising two podgroups; FIG. 37 shows a schematic representation of the relationship between segments, firegroups, phasegroups, podgroups and chromapods: FIG. 38 shows a phase diagram of AEnable and BEnable lines during a typical printing cycle; FIG. 39 shows a block diagram of a printhead interface; FIG. 40 shows a block diagram of a Memjet interface; FIG. 41 shows a flow diagram of the generation of AEnable and BEnable pulse widths; FIG. 42 shows a block diagram of dot count logic; FIG. 43 shows a conceptual overview of double buffering during printing of lines N and N+1; FIG. 44 shows a block diagram of the structure of a line loader/format unit; FIG. 45 shows a conceptual structure of a buffer; FIG. 46 shows a block diagram of the logical structure of a buffer; FIG. 47 shows a diagram of the structure and size of a two-layer page buffer; and FIG. 48 shows a block diagram of a Windows 9x/NT/CE printing system with printer driver components indicated. DETAILED DESCRIPTION OF THE DRAWINGS 1 Introduction The printer, in accordance with the invention, is a high-performance color printer which combines photographic-quality image reproduction with magazine-quality text reproduction. It utilizes an 8'' page-width microelectromechanical inkjet printhead which produces 1600 dots per inch (dpi) bi-level CMYK (Cyan, Magenta, Yellow, blacK). In this description the printhead technology shall be referred to as "Memjet", and the printer shall be referred to as "CePrint". CePrint is conceived as an original equipment manufacture (OEM) part designed for inclusion primarily in consumer electronics (CE) devices. Intended markets include televisions, VCRs, PhotoCD players, DVD players, Hi-fi systems, Web/Internet terminals, computer monitors, and vehicle consoles. As will be described in greater detail below, it features a low-profile front panel and provides user access to paper and ink via an ejecting tray. It operates in a horizontal orientation under domestic environmental conditions. CePrint exists in single- and double-sided versions. The single-sided version prints 30 full-color A4 or Letter pages per minute. The double-sided version prints 60 full-color pages per minute (i.e. 30 sheets per minute). Although CePrint supports both paper sizes, it is configured at time of manufacture for a specific paper size. 1.1 Operational Overview CePrint reproduces black text and graphics directly using bi-level black, and continuous-tone (contone) images and graphics using dithered bi-level CMYK. For practical purposes, CePrint supports a black resolution of 800 dpi, and a contone resolution of 267 pixels per inch (ppi). CePrint is embedded in a CE device, and communicates with the CE device (host) processor via a relatively low-speed (1.5 MBytes/s) connection. CePrint relies on the host processor to render each page to the level of contone pixels and black dots. The host processor compresses each rendered page to less than 3 MB for sub-two-second delivery to the printer. CePrint decompresses and prints the page line by line at the speed of its micro-electromechanical inkjet (Memjet) printhead. CePrint contains sufficient buffer memory for two compressed pages (6 MB), allowing it to print one page while receiving the next, but does not contain sufficient buffer memory for even a single uncompressed page (119 MB). The double-sided version of CePrint contains two printheads which operate in parallel. These printheads are fed by separate data paths, each of which replicates the logic found in the single-sided version of CePrint. The double-sided version has a correspondingly faster connection to the host processor (3 MB/s). 2 Product Specification Table 1 gives a summary product specification of the single-sided and double-sided versions of the CePrint unit. TABLE-US-00001 TABLE 1 CePrint Specification single-sided version double-sided version dot pitch 1600 dpi paper standard A4/Letter paper tray capacity 150 sheets print speed 30 pages per minute 60 pages per minute, 30 sheets per minute warm-up time Nil first print time 2 6 seconds subsequent prints 2 seconds/sheet color model 32-bit CMYK process color printable area Full page (full edge bleed) printhead page width Memjet with dual printheads 54,400 nozzles print method Self-cleaning transfer roller, dual transfer rollers titanium nitride (TiN) coated size (h .times. w .times. d) 40 mm .times. 272 mm .times. 60 mm .times. 272 mm .times. 416 mm 416 mm weight 3 kg (approx.) 4 kg (approx.) power supply 5 V, 4 A 5 V, 8 A ink cartridge 650 pages at 15% coverage color capacity ink cartridge 900 pages at 15% coverage black capacity ink cartridge size 21 mm .times. 188 mm .times. 38 mm (h .times. w .times. d) 3 Memjet-Based Printing A Memjet printhead produces 1600 dpi bi-level CMYK. On low-diffusion paper, each ejected drop forms an almost perfectly circular 22.5 mm diameter dot. Dots are easily produced in isolation, allowing dispersed-dot dithering to be exploited to its fullest. Since the Memjet printhead is page-width and operates with a constant paper velocity, the four color planes are printed in perfect registration, allowing ideal dot-on-dot printing. Since there is consequently no spatial interaction between color planes, the same dither matrix is used for each color plane. A page layout may contain a mixture of images, graphics and text. Continuous-tone (contone) images and graphics are reproduced using a stochastic dispersed-dot dither. Unlike a clustered-dot (or amplitude-modulated) dither, a dispersed-dot (or frequency-modulated) dither reproduces high spatial frequencies (i.e. image detail) almost to the limits of the dot resolution, while simultaneously reproducing lower spatial frequencies to their full color depth, when spatially integrated by the eye. A stochastic dither matrix is carefully designed to be free of objectionable low-frequency patterns when tiled across the image. As such its size typically exceeds the minimum size required to support a number of intensity levels (i.e. 16.times.16.times.8 bits for 257 intensity levels). CePrint uses a dither volume of size 64.times.64.times.3.times.8 bits. The volume provides an extra degree of freedom during the design of the dither by allowing a dot to change states multiple times through the intensity range, rather than just once as in a conventional dither matrix. Human contrast sensitivity peaks at a spatial frequency of about 3 cycles per degree of visual field and then falls off logarithmically, decreasing by a factor of 100 beyond about 40 cycles per degree and becoming immeasurable beyond 60 cycles per degree. At a normal viewing distance of 12 inches (about 300 mm), this translates roughly to 200 300 cycles per inch (cpi) on the printed page, or 400 600 samples per inch according to Nyquist's theorem. Contone resolution beyond about 400 pixels per inch (ppi) is therefore of limited utility, and in fact contributes slightly to color error through the dither. Black text and graphics are reproduced directly using bi-level black dots, and are therefore not antialiased (i.e. low-pass filtered) before being printed. Text is therefore supersampled beyond the perceptual limits discussed above, to produce smoother edges when spatially integrated by the eye. Text resolution up to about 1200 dpi continues to contribute to perceived text sharpness (assuming low-diffusion paper, of course). 4 Page Delivery Architecture 4.1 Page Image Sizes CePrint prints A4 and Letter pages with full edge bleed. Corresponding page image sizes are set out in Table 2 for various spatial resolutions and color depths used in the following discussion. Note that the size of an A4 page exceeds the size of a Letter page, although the Letter page is wider. Page buffer requirements are therefore based on A4, while line buffer requirements are based on Letter. TABLE-US-00002 TABLE 2 Page Image Sizes spatial resolution color depth A4.sup.a Letter.sup.b (pixels/inch) (bits/pixel) page buffer size page buffer size 1600 32 948 MB 913 MB 800 32 237 MB 228 MB 400 32 59.3 MB 57.1 MB 267 32 26.4 MB 25.4 MB 1600 4 119 MB 114 MB 800 4 29.6 MB 28.5 MB 1600 1 29.6 MB 28.5 MB 800 1 7.4 MB 7.1 MB .sup.a210 mm .times. 297 mm, or 8.3'' .times. 11.7'' .sup.b8.5'' .times. 11'' 4.2 Constraints The act of interrupting a Memjet-based printer during the printing of a page produces a visible discontinuity, so it is advantageous for the printer to receive the entire page before commencing printing, to eliminate the possibility of buffer underrun. Furthermore, if the transmission of the page from the host to the printer takes significant time in relation to the time it takes to print the page, then it is advantageous to provide two page buffers in the printer so that one page can be printed while the next is being received. If the transmission time of a page is less than its 2-second printing time, then double-buffering allows the full 30 pages/minute page rate of CePrint to be achieved. FIG. 6 illustrates the sustained printing rate achievable with double-buffering in the printer, assuming 2-second page rendering and 2-second page transmission. Assuming it is economic for the printer to have a maximum of only 8 MB of memory (i.e. a single 64 Mbit DRAM), then less than 4 MB is available for each page buffer in the printer, imposing a limit of less than 4 MB on the size of the page image. To allow for program and working memory in the printer, we limit this to 3 MB per page image. Assuming the printer has only a typical low-speed connection to the host processor, then the speed of this connection is 1 2 MB/s (i.e. 2 MB/s for parallel port, 1.5 MB/s for USB, and 1 MB/s for 10Base-T Ethernet). Assuming 2-second page transmission (i.e. equal to the printing time), this imposes a limit of 2 4 MB on the size of the page image, i.e. a limit similar to that imposed by the size of the page buffer. In practice, because the host processor and the printer can be closely coupled, a high-speed connection between them may be feasible. Whatever the speed of the host connection required by the single-sided version of CePrint, the double-sided version requires a connection of twice that speed. 4.3 Page Rendering and Compression Page rendering (or rasterization) can be split between the host processor and printer in various ways. Some printers support a full page description language (PDL) such as Postscript, and contain correspondingly sophisticated renderers. Other printers provide special support only for rendering text, to achieve high text resolution. This usually includes support for built-in or downloadable fonts. In each case the use of an embedded renderer reduces the rendering burden on the host processor and reduces the amount of data transmitted from the host processor to the printer. However, this comes at a price. These printers are more complex than they might be, and are often unable to provide full support for the graphics system of the host, through which application programs construct, render and print pages. They fail to exploit the possibly high performance of the host processor. CePrint relies on the host processor to render pages, i.e. contone images and graphics to the pixel level, and black text and graphics to the dot level. CePrint contains only a simple rendering engine which dithers the contone data and combines the results with any foreground bi-level black text and graphics. This strategy keeps the printer simple, and independent of any page description language or graphics system. It fully exploits the high performance expected in the host processor of a multimedia CE device. The downside of this strategy is the potentially large amount of data which must be transmitted from the host processor to the printer. We therefore use compression to reduce the page image size to the 3 MB required to allow a sustained printing rate of 30 pages/minute. An 8.3''.times.11.7'' A4 page has a bi-level CMYK page image size of 119 MBytes at 1600 dpi, and a contone CMYK pagesize of 59.3 MB at 400 ppi. We use JPEG compression to compress the contone data. Although JPEG is inherently lossy, for compression ratios of 10:1 or less the loss is usually negligible. To achieve a high-quality compression ratio of less than 10:1, and to obtain an integral contone to bi-level ratio, we choose a contone resolution of 267 ppi. This yields a contone CMYK pagesize of 25.5 MB, a corresponding compression ratio of 8.5:1 to fit within the 3 MB/page limit, and a contone to bi-level ratio of 1:6 in each dimension. A full page of black text (and/or graphics) rasterized at printer resolution (1600 dpi) yields a bi-level image of 29.6 MB. Since rasterizing text at 1600 dpi places a heavy burden on the host processor for a small gain in quality, we choose to rasterize text at 800 dpi. This yields a bi-level image of 7.4 MB, requiring a lossless compression ratio of less than 2.5:1 to fit within the 3 MB/page limit. We achieve this using a two-dimensional bi-level compression scheme similar to the compression scheme used in Group 4 Facsimile. As long as the image and text regions of a page are non-overlapping, any combination of the two fits within the 3 MB limit. If text lies on top of a background image, then the worst case is a compressed page image size approaching 6 MB (depending on the actual text compression ratio). This fits within the printer's page buffer memory, but prevents double-buffering of pages in the printer, thereby reducing the printer's page rate by two-thirds, i.e. to 10 pages/minute. 4.4 Page Expansion and Printing As described above, the host processor renders contone images and graphics to the pixel level, and black text and graphics to the dot level. These are compressed by different means and transmitted together to the printer. The printer contains two 3 MB page buffers--one for the page being received from the host, and one for the page being printed. The printer expands the compressed page as it is being printed. This expansion consists of decompressing the 267 ppi contone CMYK image data, halftoning the resulting contone pixels to 1600 dpi bi-level CMYK dots, decompressing the 800 dpi bi-level black text data, and compositing the resulting bi-level black text dots over the corresponding bi-level CMYK image dots. The conceptual data flow from the application to the printed page is illustrated in FIG. 7. 5 Printer Hardware CePrint is conceived as an OEM part designed for inclusion primarily in consumer electronics (CE) devices. Intended markets include televisions, VCRs, PhotoCD players, DVD players, Hi-fi systems, Web/Internet terminals, computer monitors, and vehicle consoles. It features a low-profile front panel and provides user access to paper and ink via an ejecting tray. It operates in a horizontal orientation under domestic environmental conditions. Because of the simplicity of the page width Memjet printhead, CePrint contains an ultra-compact print mechanism which yields an overall product height of 40 mm for the single-sided version and 60 mm for the double-sided version. The nature of an OEM product dictates that it should be simple in style and reflect minimum dimensions for inclusion into host products. CePrint is styled to be accommodated into all of the target market products and has minimum overall dimensions of 40 mm high.times.272 mm wide.times.416 mm deep. The only cosmetic part of the product is the front fascia and front tray plastics. These can be re-styled by a manufacturer if they wish to blend CePrint with a certain piece of equipment. Front views of the two versions of CePrint or the printer are illustrated in FIGS. 1 and 2, respectively, of the drawings and are designated generally by the reference numeral 10. It is to be noted that, mechanically, both versions are the same, apart from the greater height of the double-sided version to accommodate a second print engine instead of a pinch roller. This will be described in greater detail below. Side and plan views of the single-sided version of CePrint are illustrated in FIGS. 3 and 4 respectively. The side view of the double-sided version of CePrint is illustrated in FIG. 5. CePrint 10 is a motorized A4/Letter paper tray with a removable ink cartridge and a Memjet printhead mechanism. It includes a front panel 12 housing a paper eject button 14, a power LED 16, an out-of-ink LED 18 and an out-of-paper LED 20. A paper tray 22 is slidably arranged relative to the front panel 12. When the paper tray 22 is in its "home" position, a paper output slot 24 is defined between the front panel 12 and the paper tray 22. The front panel 12 fronts a housing 26 containing the working parts of the printer 10. As illustrated in 5 of the drawings, the housing 26, in the case of the double-sided version is stepped, at 28, towards the front panel 12 (FIGS. 1 and 2) to accommodate the second print engine. The housing 26 covers a metal chassis 30 (FIG. 8), fascias, the (molded) paper tray 22, an ink cartridge 32 (FIG. 10), three motors, a flex PCB 34 (FIG. 8A), a rigid PCB 36 (FIG. 8) and various injection moldings and smaller parts to achieve a cost effective high volume product. The printer 10 is simple to operate, only requiring user interaction when paper or ink need replenishing as indicated by the front-panel LEDs 20 or 18, respectively. The paper handling mechanisms are similar to current printer applications and are therefore considered reliable. In the rare event of a paper jam, the action of ejecting the paper tray allows the user to deal with the problem. The tray 22 has a sensor which retracts the tray if the tray 22 is pushed. If the tray 22 jams on the way in, this is also sensed and the tray 22 is re-ejected. This allows the user to be lazy in operating the tray 22 by just pushing it to close and protects the unit from damage should the tray 22 get knocked while in the out position. It also caters for children sticking fingers in the tray 22 while closing. Ink is replaced by inserting a new cartridge 32 into the paper tray 22 (FIG. 8) and securing it by a cam lock lever mechanism. 5.1 Overview The overall views of CePrint 10 are shown in FIGS. 8 to 10. As shown in FIG. 9 the chassis 30 includes base metalwork 38 on which front roller wheels 40 of the paper tray 22 are slidable. A bracket 42 accommodates motors 44, 46 and 48 and gears 50 and 52 for ejecting the paper tray 22 and driving a paper pick-up roller 54. Attached to the bracket 42 and the base metalwork 38 are two guide rails 56 that allow the molded paper tray 22 and its rear roller wheels 58 to slide forward. As described above, the tray 22 also sits on front rollers 40 and this provides a strong, low friction and steady method of ejection and retraction. The flex PCB 34 (FIG. 8A) runs from the main PCB 36 via the motors 44, 46 and 48 to a contact molding 60 and a lightpipe area 62. An optical sensor on the flex PCB 34 allows the tray ejector motor 46 to retract the tray 22 independently of the eject button 14 if the tray 22 is pushed when in the out position by sensing a hole in a gear wheel 64 (FIG. 9). Similarly, the tray 22 is ejected if there is any stoppage during retraction. The contact molding 60 has a foam pad 66 that the flex PCB 34 is fixed onto and provides data and power contacts to the printhead and bus bars during printing. A transfer roller 68 (FIG. 11) has two end caps 69 (FIG. 8A) that run in low friction bearing assemblies 70. One of the end caps 69 has an internal gear that acts on a small gear 72 (FIG. 14) which transfers power through a reduction gear 74 to a worm drive. This is reduced further via another gear to a motor worm drive 76 mounted on an output shaft of a stepper motor 124 arranged within the transfer roller 68. This solution for a motor drive assembly that is housed inside the transfer roller 68 saves space for future designs and mounts onto a small chassis 78 (FIG. 8A) that is attached to ink connector moldings 80, 82. An ink connector 84 has four pins 86 with an ejector plate 88 and springs 90 that interfaces with the ink cartridge 32 (FIG. 10). The ink cartridge 32 is accessed via a cam lock lever and spring 92 (FIG. 8). The ink is conducted through molded channels into a flexible four-channel hose connector 94 that interfaces with a printhead cartridge end cap 96. The other end of the printhead cartridge has a different flexible sealing connector 98 (FIG. 8) on the end cap to allow ink to be drawn through the cartridge during assembly and effectively charge the unit and ink connector with ink in a sealed environment. The printhead and ink connector assemblies are mounted directly into the paper tray 22. The paper tray 22 has several standard paper handling components, namely a metal base channel 100 (FIG. 8) with low friction pads 102, sprung by two compression springs 104 and two metal paper guides 106 with arms 108 secured by rivets. The paper is aligned to one side of the tray 22 by a spring steel clip 110. The tray 22 is normally configured to take A4 paper, but Letter size paper is accommodated by relocating one of the paper guide assemblies 106 and clipping a plate into the paper tray 22 to provide a rear stop. The paper tray 22 can accommodate up to 150 sheets. As is standard practice for adding paper, the metal base channel 100 is pushed down and is latched using a tray lock molding 112 and a return spring 114. When paper has been added and the tray 22 retracted, the tray lock molding 112 is unlatched by hitting a metal return 116 in the base metalwork 38 (FIG. 9). The printer 10 is now ready to print. When activated, the paper pick-up roller 54 is driven by a small drive gear 118 that meshes with another drive gear 50 and a normal motor 44. The roller 54 is located to the base metalwork 38 (FIG. 9) by two heat staked retainer moldings 120 (FIG. 8). A small molding on the end of the pick-up roller 54 acts with a sensor on the flex PCB 34 to accurately position the pick-up roller 54 in a parked position so that paper and tray 22 can be withdrawn without touching it when ejecting. This accurate positioning also allows the roller 54 to feed the sheet to the transfer roller 68 (FIG. 10) with a fixed number of revolutions. As the transfer roller 68 is running at a similar speed there should be no problem with take-up of the paper. An optical sensor 122 mounted into the housing 26 finds the start of each sheet and engages a transfer motor 124 (FIG. 14), so there is no problem if for example a sheet has moved forward of the roller during any strange operations. The main PCB 36 is mounted onto the base metalwork 38 via standard PCB standoffs 126 and is fitted with a data connector 128 and a DC connector 130. The front panel 12 is mounted onto the base metalwork 38 using snap details and a top metal cover 132 completes the overall product with RFI/EMI integrity via four fixings 134. 5.2 Printhead Assembly and Image Transfer Mechanism The print engine is shown in greater detail in FIG. 11 and is designated generally by the reference numeral 140. The Memjet printhead assembly is, in turn, designated by the reference numeral 142. This represents one of the four possible ways to deploy the Memjet printhead 143 in conjunction with the ink cartridge 32 in a product such as CePrint 10: permanent printhead, replaceable ink cartridge (as shown in FIG. 11) separate replaceable printhead cartridge and ink cartridge refillable combined printhead and ink cartridge disposable combined printhead and ink cartridge The Memjet printhead 143 prints onto the titanium nitride (TiN) coated transfer roller 68 which rotates in an anticlockwise direction to transfer the image onto a sheet of paper 144. The paper 144 is pressed against the transfer roller 68 by a spring-loaded rubber coated pinch roller 145 in the case of the single-sided version. As illustrated in FIG. 13, in the case of the double-sided version, the paper 144 is pressed against one of the transfer rollers 68 under the action of the opposite transfer roller 68. After transferring the image to the paper 144 the transfer roller 68 continues past a cleaning sponge 146 and finally a rubber wiper 148. The sponge 146 and the wiper 148 form a cleaning station for cleaning the surface of the transfer roller 68. While operational, the printhead assembly 142 is held off the transfer roller 68 by a solenoid 150 as shown in FIG. 12B. When not operational, the printhead assembly 142 is parked against the transfer roller 68 as shown in FIG. 12A. The printhead's integral elastomeric seal 152 seals the printhead assembly 142 and prevents the Memjet printhead 143 from drying out. In the double-sided version of CePrint 10, there are dual print engines 140, each with its associated printhead assembly 142 and transfer roller 68, mounted in opposition as illustrated in FIG. 13. The lower print engine 140 is fixed while the upper print engine 140 pivots and is sprung to press against the paper 144. As previously described, the upper transfer roller 68 takes the place of the pinch roller 145 in the single-sided version. The relationship between the ink cartridge 32, printhead assembly 142 and the transfer roller 68 is shown in greater detail in FIGS. 15 and 16 of the drawings. The ink cartridge has four reservoirs 154, 156, 158 and 160 for cyan, magenta, yellow and black ink respectively. Each reservoir 154 160 is in flow communication with a corresponding reservoir 164 170 in the printhead assembly 142. These reservoirs, in turn, supply ink to a Memjet printhead chip 143 (FIG. 16) via an ink filter 174. It is to be noted in FIG. 16 that the elastomeric capping seal 152 is arranged on both sides of the printhead chip 143 to assist in sealing when the printhead assembly 142 is parked against the transfer roller 68. Power is supplied to the solenoid via busbars 176. 6 Printer Control Protocol This section describes the printer control protocol used between a host and CePrint 10. It includes control and status handling as well as the actual page description. 6.1 Control and Status The printer control protocol defines the format and meaning of messages exchanged by the host processor and the printer 10. The control protocol is defined independently of the transport protocol between the host processor and the printer 10, since the transport protocol depends on the exact nature of the connection. Each message consists of a 16-bit message code, followed by message-specific data which may be of fixed or variable size. All integers contained in messages are encoded in big-endian byte order. Table 3 defines command messages sent by the host processor to the printer 10. TABLE-US-00003 TABLE 3 Printer command messages command message message code description reset printer 1 Resets the printer to an idle state (i.e. ready and not printing). get printer status 2 Gets the current printer status. start document 3 Starts a new document. start page 4 Starts the description of a new output page. page band 5 Describes a band of the current output page. end page 6 Ends the description of the current output page. end document 7 Ends the current document. The reset printer command can be used to reset the printer to clear an error condition, and to abort printing. The start document command is used to indicate the start of a new document. This resets the printer's page count, which is used in the double-sided version to identify odd and even pages. The end document command is simply used to indicate the end of the document. The description of an output page consists of a page header which describes the size and resolution of the page, followed by one or more page bands which describe the actual page content. The page header is transmitted to the printer in the start page command. Each page band is transmitted to the printer in a page band command. The last page band is followed by an end page command. The page description is described in detail in Table 4.2. Table 4 defines response messages sent by the printer to the host processor. TABLE-US-00004 TABLE 4 Printer response messages response message message code description printer status 8 Contains the current printer status (as defined in Table 7). page error 9 Contains the most recent page error code (as defined in Table 8). A printer status message is normally sent in response to a get printer status command. However, the nature of the connection between the host processor and the printer may allow the printer to send unsolicited status messages to the host processor. Unsolicited status messages allow timely reporting of printer exceptions to the host processor, and thereby to the user, without requiring the host processor to poll the printer on a frequent basis. A page error message is sent in response to each start page, page band and end page command. Table 5 defines the format of the 16-bit printer status contained in the printer status message. TABLE-US-00005 TABLE 5 Printer status format field bit description ready 0 The printer is ready to receive a page. printing 1 The printer is printing. error 2 The printer is in an error state. paper tray missing 3 The paper tray is missing. paper tray empty 4 The paper tray is empty. ink cartridge missing 5 The ink cartridge is missing. ink cartridge empty 6 The ink cartridge is empty. ink cartridge error 7 The ink cartridge is in an error state. (reserved) 8 15 Reserved for future use. Table 6 defines page error codes which may be returned in a page error message. TABLE-US-00006 TABLE 6 Page error codes error code value description no error 0 No error. bad signature 1 The signature is not recognized. bad version 2 The version is not supported. bad parameter 3 A parameter is incorrect. 6.2 Page Description CePrint 10 reproduces black at full dot resolution (1600 dpi), but reproduces contone color at a somewhat lower resolution using halftoning. The page description is therefore divided into a black layer and a contone layer. The black layer is defined to composite over the contone layer. The black layer consists of a bitmap containing a 1-bit opacity for each pixel. This black layer matte has a resolution which is an integer factor of the printer's dot resolution. The highest supported resolution is 1600 dpi, i.e. the printer's full dot resolution. The contone layer consists of a bitmap containing a 32-bit CMYK color for each pixel. This contone image has a resolution which is an integer factor of the printer's dot resolution. The highest supported resolution is 267 ppi, i.e. one-sixth the printer's dot resolution. The contone resolution is also typically an integer factor of the black resolution, to simplify calculations in the printer driver. This is not a requirement, however. The black layer and the contone layer are both in compressed form for efficient transmission over the low-speed connection to the printer. 6.2.1 Page Structure CePrint prints with full edge bleed using an 8.5'' printhead. It imposes no margins and so has a printable page area which corresponds to the size of its paper (A4 or Letter). The target page size is constrained by the printable page area, less the explicit (target) left and top margins specified in the page description. 6.2.2 Page Description Format Apart from being implicitly defined in relation to the printable page area, each page description is complete and self-contained. There is no data transmitted to the printer separately from the page description to which the page description refers. The page description consists of a page header which describes the size and resolution of the page, followed by one or more page bands which describe the actual page content. Table 7 shows the format of the page header. TABLE-US-00007 TABLE 7 Page header format field format description signature 16-bit integer Page header format signature. version 16-bit integer Page header format version number. structure size 16-bit integer Size of page header. target resolution 16-bit integer Resolution of target page. This is (dpi) always 1600 for CePrint. target page width 16-bit integer Width of target page, in dots. target page height 16-bit integer Height of target page, in dots. target left margin 16-bit integer Width of target left margin, in dots. target top margin 16-bit integer Height of target top margin, in dots. black scale factor 16-bit integer Scale factor from black resolution to target resolution (must be 2 or greater). black page width 16-bit integer Width of black page, in black pixels. black page height 16-bit integer Height of black page, in black pixels. contone scale factor 16-bit integer Scale factor from contone resolution to target resolution (must be 6 or greater). contone page width 16-bit integer Width of contone page, in contone pixels. contone page height 16-bit integer Height of contone page, in contone pixels. The page header contains a signature and version which allow the printer to identify the page header format. If the signature and/or version are missing or incompatible with the printer, then the printer can reject the page. The page header defines the resolution and size of the target page. The black and contone layers are clipped to the target page if necessary. This happens whenever the black or contone scale factors are not factors of the target page width or height. The target left and top margins define the positioning of the target page within the printable page area. The black layer parameters define the pixel size of the black layer, and its integer scale factor to the target resolution. The contone layer parameters define the pixel size of the contone layer, and its integer scale factor to the target resolution. Table 8 shows the format of the page band header. TABLE-US-00008 TABLE 8 Page band header format field format description signature 16-bit integer Page band header format signature. version 16-bit integer Page band header format version number. structure size 16-bit integer Size of page band header. black band height 16-bit integer Height of black band, in black pixels. black band data size 32-bit integer Size of black band data, in bytes. contone band height 16-bit integer Height of contone band, in contone pixels. contone band data size 32-bit integer Size of contone band data, in bytes. The black layer parameters define the height of the black band, and the size of its compressed band data. The variable-size black band data follows the fixed-size parts of the page band header. The contone layer parameters define the height of the contone band, and the size of its compressed page data. The variable-size contone band data follows the variable-size black band data. Table 9 shows the format of the variable-size compressed band data which follows the page band header. TABLE-US-00009 TABLE 9 Page band data format field format description black band data EDRL bytestream Compressed bi-level black band data. contone band data JPEG bytestream Compressed contone CMYK band data. The variable-size black band data and the variable-size contone band data are aligned to 8-byte boundaries. The size of the required padding is included in the size of the fixed-size part of the page band header structure and the variable-size black band data. The entire page description has a target size of less than 3 MB, and a maximum size of 6 MB, in accordance with page buffer memory in the printer. The following sections describe the format of the compressed black layer and the compressed contone layer. 6.2.3 Bi-Level Black Layer Compression 6.2.3.1 Group 3 and 4 Facsimile Compression The Group 3 Facsimile compression algorithm losslessly compresses bi-level data for transmission over slow and noisy telephone lines. The bi-level data represents scanned black text and graphics on a white background, and the algorithm is tuned for this class of images (it is explicitly not tuned, for example, for halftoned bi-level images). The 1D Group 3 algorithm runlength-encodes each scanline and then Huffman-encodes the resulting runlengths. Runlengths in the range 0 to 63 are coded with terminating codes. Runlengths in the range 64 to 2623 are coded with make-up codes, each representing a multiple of 64, followed by a terminating code. Runlengths exceeding 2623 are coded with multiple make-up codes followed by a terminating code. The Huffman tables are fixed, but are separately tuned for black and white runs (except for make-up codes above 1728, which are common). When possible, the 2D Group 3 algorithm encodes a scanline as a set of short edge deltas (0, .+-.1, .+-.2, .+-.3) with reference to the previous scanline. The delta symbols are entropy-encoded (so that the zero delta symbol is only one bit long etc.) Edges within a 2D-encoded line which can't be delta-encoded are runlength-encoded, and are identified by a prefix. 1D- and 2D-encoded lines are marked differently. 1D-encoded lines are generated at regular intervals, whether actually required or not, to ensure that the decoder can recover from line noise with minimal image degradation. 2D Group 3 achieves compression ratios of up to 6:1. The Group 4 Facsimile algorithm losslessly compresses bi-level data for transmission over error-free communications lines (i.e. the lines are truly error-free, or error-correction is done at a lower protocol level). The Group 4 algorithm is based on the 2D Group 3 algorithm, with the essential modification that since transmission is assumed to be error-free, 1D-encoded lines are no longer generated at regular intervals as an aid to error-recovery. Group 4 achieves compression ratios ranging from 20:1 to 60:1 for the CCITT set of test images. The design goals and performance of the Group 4 compression algorithm qualify it as a compression algorithm for the bi-level black layer. However, its Huffman tables are tuned to a lower scanning resolution (100 400 dpi), and it encodes runlengths exceeding 2623 awkwardly. At 800 dpi, our maximum runlength is currently 6400. Although a Group 4 decoder core might be available for use in the printer controller chip (Section 7), it might not handle runlengths exceeding those normally encountered in 400 dpi facsimile applications, and so would require modification. Since most of the benefit of Group 4 comes from the delta-encoding, a simpler algorithm based on delta-encoding alone is likely to meet our requirements. This approach is described in detail below. 6.2.3.2 Bi-Level Edge Delta and Runlength (EDRL) Compression Format The edge delta and runlength (EDRL) compression format is based loosely on the Group 4 compression format and its precursors. EDRL uses three kinds of symbols, appropriately entropy-coded. These are create edge, kill edge, and edge delta. Each line is coded with reference to its predecessor. The predecessor of the first line is defined to a line of white. Each line is defined to start off white. If a line actually starts of black (the less likely situation), then it must define a black edge at offset zero. Each line must define an edge at its left-hand end, i.e. at offset page width. An edge can be coded with reference to an edge in the previous line if there is an edge within the maximum delta range with the same sense (white-to-black or black-to-white). This uses one of the edge delta codes. The shorter and likelier deltas have the shorter codes. The maximum delta range (.+-.2) is chosen to match the distribution of deltas for typical glyph edges. This distribution is mostly independent of point size. A typical example is given in Table 10. TABLE-US-00010 TABLE 10 Edge delta distribution for 10 point Times at 800 dpi |delta| probability 0 65% 1 23% 2 7% .gtoreq.3 5% An edge can also be coded using the length of the run from the previous edge in the same line. This uses one of the create edge codes for short (7-bit) and long (13-bit) runlengths. For simplicity, and unlike Group 4, runlengths are not entropy-coded. In order to keep edge deltas implicitly synchronized with edges in the previous line, each unused edge in the previous line is 'killed' when passed in the current line. This uses the kill edge code. The end-of-page code signals the end of the page to the decoder. Note that 7-bit and 13-bit runlengths are specifically chosen to support 800 dpi A4/Letter pages. Longer runlengths could be supported without significant impact on compression performance. For example, if supporting 1600 dpi compression, the runlengths should be at least 8-bit and 14-bit respectively. A general-purpose choice might be 8-bit and 16-bit, thus supporting up to 40'' wide 1600 dpi pages. The full set of codes is defined in Table 11. Note that there is no end-of-line code. The decoder uses the page width to detect the end of the line. The lengths of the codes are ordered by the relative probabilities of the codes' occurrence. TABLE-US-00011 TABLE 11 EDRL codewords code encoding suffix description .DELTA.0 1 -- don't move corresponding edge .DELTA.+1 010 -- move corresponding edge +1 .DELTA.-1 011 -- move corresponding edge -1 .DELTA.+2 00010 -- move corresponding edge +2 .DELTA.-2 00011 -- move corresponding edge -2 kill edge 0010 -- kill corresponding edge create near 0011 7-bit RL create edge from short edge runlength (RL) create far 00001 13-bit RL create edge from long edge runlength (RL) end-of-page 000001 -- end-of-page marker (EOP) FIG. 17 shows a simple encoding example. Note that the common situation of an all-white line following another all-white line is encoded using a single bit (.DELTA.0), and an all-black line following another all-black line is encoded using two bits (.DELTA.0, .DELTA.0). Note that the foregoing describes the compression format, not the compression algorithm per se. A variety of equivalent encodings can be produced for the same image, some more compact than others. For example, a pure runlength encoding conforms to the compression format. The goal of the compression algorithm is to discover a good, if not the best, encoding for a given image. The following is a simple algorithm for producing the EDRL encoding of a line with reference to its predecessor. TABLE-US-00012 #define SHORT_RUN_PRECISION 7 // precision of short run #define LONG_RUN_PRECISION13 // precision of long run EDRL_CompressLine ( Byte prevLine[], // previous (reference) // bi-level line Byte currLine[], // current (coding) bi-level line int lineLen, // line length BITSTREAM s // output (compressed) bitstream ) int prevEdge = 0 // current edge offset in // previous line int currEdge = 0 // current edge offset in // current line int codedEdge = currEdge // most recent coded (output) edge int prevColor = 0 // current color in prev line // (0 = white) int currColor = 0 // current color in current line int prevRun // current run in previous line int currRun // current run in current line bool bUpdatePrevEdge = true // force first edge update bool bUpdateCurrEdge = true // force first edge update while (codedEdge < lineLen) // possibly update current edge in previous line if (bUpdatePrevEdge) if (prevEdge < lineLen) prevRun = GetRun(prevLine, prevEdge, lineLen, prevColor) else prevRun = 0 prevEdge += prevRun prevColor = !prevColor bUpdatePrevEdge = false // possibly update current edge in current line if (bUpdateCurrEdge) if (currEdge < lineLen) currRun = GetRun(currLine, currEdge, lineLen, currColor) else currRun = 0 currEdge += currRun currColor = !currColor bUpdateCurrEdge = false // output delta whenever possible, i.e. when // edge senses match, and delta is small enough if (prevColor == currColor) delta = currEdge - prevEdge if (abs(delta) <= MAX_DELTA) PutCode(s, EDGE_DELTA0 + delta) codedEdge = currEdge bUpdatePrevEdge = true bUpdateCurrEdge = true continue // kill unmatched edge in previous line if (prevEdge <= currEdge) PutCode(s, KILL_EDGE) bUpdatePrevEdge = true // create unmatched edge in current line if (currEdge <= prevEdge) PutCode(s, CREATE_EDGE) if (currRun < 128) PutCode(s, CREATE_NEAR_EDGE) PutBits(currRun, SHORT_RUN_PRECISION) else PutCode(s, CREATE_FAR_EDGE) PutBits(currRun, LONG_RUN_PRECISION) codedEdge = currEdge bUpdateCurrEdge = true Note that the algorithm is blind to actual edge continuity between lines, and may in fact match the "wrong" edges between two lines. Happily the compression format has nothing to say about this, since it decodes correctly, and it is difficult for a "wrong" match to have a detrimental effect on the compression ratio. For completeness the corresponding decompression algorithm is given below. It forms the core of the EDRL Expander unit in the printer controller chip (Section 7). TABLE-US-00013 EDRL_DecompressLine ( BITSTREAM s, // input (compressed) bitstream Byte prevLine[], // previous (reference) bi-level line Byte currLine[], // current (coding) bi-level line int lineLen // line length ) int prevEdge = 0 // current edge offset in // previous line int currEdge = 0 // current edge offset in current line int prevColor = 0 // current color in previous line // (0 = white) int currColor = 0 // current color in current line while (currEdge < lineLen) code = GetCode(s) switch (code) case EDGE_DELTA_MINUS2: case EDGE_DELTA_MINUS1: case EDGE_DELTA_0: case EDGE_DELTA_PLUS1: case EDGE_DELTA_PLUS2: // create edge from delta int delta = code - EDGE_DELTA_0 int run = prevEdge + delta - currEdge FillBitRun(currLine, currEdge, currColor, run) currEdge += run currColor = !currColor prevEdge += GetRun(prevLine, prevEdge, lineLen, prevColor) prevColor = !prevColor case KILL_EDGE: // discard unused reference edge prevEdge += GetRun(prevLine, prevEdge, lineLen, prevColor) prevColor = !prevColor case CREATE_NEAR_EDGE: case CREATE_FAR_EDGE: // create edge explicitly int run if (code == CREATE_NEAR_EDGE) run = GetBits(s, SHORT_RUN.sub.-- PRECISION) else run = GetBits(s, LONG_RUN.sub.-- PRECISION) FillBitRun(currLine, currEdge, currColor, run) currColor = !currColor currEdge += run 6.2.3.3 EDRL Compression Performance Table 12 shows the compression performance of Group 4 and EDRL on the CCITT test documents used to select the Group 4 algorithm. Each document represents a single page scanned at 400 dpi. Group 4's superior performance is due to its entropy-coded runlengths, tuned to 400 dpi features. TABLE-US-00014 TABLE 12 Group 4 and EDRL compression performance on standard CCITTT documents at 400 dpi CCITT Group 4 EDRL document number compression ratio compression ratio 1 29.1 21.6 2 49.9 41.3 3 17.9 14.1 4 7.3 5.5 5 15.8 12.4 6 31.0 25.5 7 7.4 5.3 8 26.7 23.4 Magazine text is typically typeset in a typeface with serifs (such as Times) at a point size of 10. At this size an A4/Letter page holds up to 14,000 characters, though a typical magazine page holds only about 7,000 characters. Text is seldom typeset at a point size smaller than 5. At 800 dpi, text cannot be meaningfully rendered at a point size lower than 2 using a standard typeface. Table 13 illustrates the legibility of various point sizes. TABLE-US-00015 TABLE 13 Text at different point sizes ##STR00001## Table 14 shows Group 4 and EDRL compression performance on pages of text of varying point sizes, rendered at 800 dpi. Note that EDRL achieves the required compression ratio of 2.5 for an entire page of text typeset at a point size of 3. The distribution of characters on the test pages is based on English-language statistics. TABLE-US-00016 TABLE 14 Group 4 and EDRL compression performance on text at 800 dpi characters/ Group 4 EDRL point size A4 page compression ratio compression ratio 2 340,000 2.3 1.7 3 170,000 3.2 2.5 4 86,000 4.7 3.8 5 59,000 5.5 4.9 6 41,000 6.5 6.1 7 28,000 7.7 7.4 8 21,000 9.1 9.0 9 17,000 10.2 10.4 10 14,000 10.9 11.3 11 12,000 11.5 12.4 12 8,900 13.5 14.8 13 8,200 13.5 15.0 14 7,000 14.6 16.6 15 5,800 16.1 18.5 20 3,400 19.8 23.9 For a point size of 9 or greater, EDRL slightly outperforms Group 4, simply because Group 4's runlength codes are tuned to 400 dpi. These compression results bear out the observation that entropy-encoded runlengths contribute much less to compression than 2D encoding, unless the data is poorly correlated vertically, such as in the case of very small characters. 6.2.4 Contone Layer Compression 6.2.4.1 JPEG Compression The JPEG compression algorithm lossily compresses a contone image at a specified quality level. It introduces imperceptible image degradation at compression ratios below 5:1, and negligible image degradation at compression ratios below 10:1. JPEG typically first transforms the image into a color space which separates luminance and chrominance into separate color channels. This allows the chrominance channels to be subsampled without appreciable loss because of the human visual system's relatively greater sensitivity to luminance than chrominance. After this first step, each color channel is compressed separately. The image is divided into 8.times.8 pixel blocks. Each block is then transformed into the frequency domain via a discrete cosine transform (DCT). This transformation has the effect of concentrating image energy in relatively lower-frequency coefficients, which allows higher-frequency coefficients to be more crudely quantized. This quantization is the principal source of compression in JPEG. Further compression is achieved by ordering coefficients by frequency to maximize the likelihood of adjacent zero coefficients, and then runlength-encoding runs of zeroes. Finally, the runlengths and non-zero frequency coefficients are entropy coded. Decompression is the inverse process of compression. 6.2.4.2 CMYK Contone JPEG Compression Format The CMYK contone layer is compressed to an interleaved color JPEG bytestream. The interleaving is required for space-efficient decompression in the printer, but may restrict the decoder to two sets of Huffman tables rather than four (i.e. one per color channel). If luminance and chrominance are separated, then the luminance channels can share one set of tables, and the chrominance channels the other set. If luminance/chrominance separation is deemed necessary, either for the purposes of table sharing or for chrominance subsampling, then CMY is converted to YCrCb and Cr and Cb are duly subsampled. K is treated as a luminance channel and is not sub sampled. The JPEG bytestream is complete and self-contained. It contains all data required for decompression, including quantization and Huffman tables. 7 Printer Controller 7.1 Printer Controller Architecture A printer controller 178 (FIG. 18) consists of the CePrint central processor (CCP) chip 180, a 64 MBit RDRAM 182, and a master QA chip 184. The CCP 180 contains a general-purpose processor 181 and a set of purpose-specific functional units controlled by the processor via a processor bus 186. Only three functional units are non-standard--an EDRL expander 188, a halftoner/compositor 190, and a printhead interface 192 which controls the Memjet printhead 143. Software running on the processor 181 coordinates the various functional units to receive, expand and print pages. This is described in the next section. The various functional units of the CCP 180 are described in subsequent sections. 7.2 Page Expansion and Printing Page expansion and printing proceeds as follows. A page description is received from the host via a host interface 194 and is stored in main memory 182. 6 MB of main memory 182 is dedicated to page storage. This can hold two pages each not exceeding 3 MB, or one page up to 6 MB. If the host generates pages not exceeding 3 MB, then the printer operates in streaming mode--i.e. it prints one page while receiving the next. If the host generates pages exceeding 3 MB, then the printer operates in single-page mode--i.e. it receives each page and prints it before receiving the next. If the host generates pages exceeding 6 MB then they are rejected by the printer. In practice the printer driver prevents this from happening. A page consists of two parts--the bi-level black layer, and the contone layer. These are compressed in distinct formats--the bi-level black layer in EDRL format, the contone layer in JPEG format. The first stage of page expansion consists of decompressing the two layers in parallel. The bi-level layer is decompressed by the EDRL expander unit 188, the contone layer by a JPEG decoder 196. The second stage of page expansion consists of halftoning the contone CMYK data to bi-level CMYK, and then compositing the bi-level black layer over the bi-level CMYK layer. The halftoning and compositing is carried out by the halftoner/compositor unit 190. Finally, the composited bi-level CMYK image is printed via the printhead interface unit 192, which controls the Memjet printhead 143. Because the Memjet printhead 143 prints at high speed, the paper 144 must move past the printhead 143 at a constant velocity. If the paper 144 is stopped because data cannot be fed to the printhead 143 fast enough, then visible printing irregularities will occur. It is therefore important to transfer bi-level CMYK data to the printhead interface 192 at the required rate. A fully-expanded 1600 dpi bi-level CMYK page has an image size of 119 MB. Because it is impractical to store an expanded page in printer memory, each page is expanded in real time during printing. Thus the various stages of page expansion and printing are pipelined. The page expansion and printing data flow is described in Table 15. The aggregate traffic to/from main memory via an interface 198 of 182 MB/s is well within the capabilities of current technologies such as Rambus. TABLE-US-00017 TABLE 15 Page expansion and printing data flow input output input output process input window output window rate rate Receive -- -- JPEG 1 -- 1.5 MB/s contone stream -- 3.5 Mp/s receive -- -- EDRL 1 -- 1.5 MB/s bi-level stream -- 31 Mp/s decompress JPEG -- 32-bit 8 1.5 MB/s 13 MB/s contone stream CMYK 3.5 Mp/s 3.5 Mp/s decompress EDRL -- 1-bit 1 1.5 MB/s 15 MB/s bi-level stream K 31 Mp/s.sup.a 124 Mp/s halftone 32-bit 1 --.sup.b -- 13 MB/s -- CMYK 3.5 Mp/s.sup.c -- composite 1-bit K 1 4-bit 1 15 MB/s 60 MB/s CMYK 124 Mp/s 124 Mp/s print 4-bit 24, 1.sup.d -- -- 60 MB/s -- CMYK 124 Mp/s -- 91 MB/s 91 MB/S 182 MB/S .sup.a800 dpi .fwdarw. 1600 dpi (2 .times. 2 expansion) .sup.bhalftone combines with composite, so there is no external data flow between them .sup.c267 dpi .fwdarw. 1600 dpi (6 .times. 6 expansion) .sup.dNeeds a window of 24 lines, but only advances 1 line. Each stage communicates with the next via a shared FIFO in main memory 182. Each FIFO is organized into lines, and the minimum size (in lines) of each FIFO is designed to accommodate the output window (in lines) of the producer and the input window (in lines) of the consumer. Inter-stage main memory buffers are described in Table 16. The aggregate buffer space usage of 6.3 MB leaves 1.7 MB free for program code and scratch memory (out of the 8 MB available). TABLE-US-00018 TABLE 16 Page expansion and printing main memory buffers organization number buffer buffer and line size of lines size compressed byte stream -- 6 MB page buffer (one or two pages) -- contone 32-bit interleaved CMYK 8 .times. 2 = 16 142 KB CMYK (267 ppi .times. 8.5'' .times. 32 = 8.9 KB) buffer bi-level 1-bit K 1 .times. 2 = 2 3 KB K buffer (1600 dpi .times. 8.5'' .times. 1 = 1.7 B) bi-level 4-bit planar odd/even CMYK 24 + 1 = 25 166 KB CMYK (1600 dpi .times. 8.5'' .times. 4 = 6.6 KB) buffer 6.3 MB The overall data flow, including FIFOs, is illustrated in FIG. 19. Contone page decompression is carried out by the JPEG decoder 196. Bi-level page decompression is carried out by the EDRL expander 188. Halftoning and compositing is carried out by the halftoner/compositor unit 190. These functional units are described in the following sections. 7.2.1 DMA Approach Each functional unit contains one or more on-chip input and/or output FIFOs. Each FIFO is allocated a separate channel in a multi-channel DMA controller 200. The DMA controller 200 handles single-address rather than double-address transfers, and so provides a separate request/acknowledge interface for each channel. Each functional unit stalls gracefully whenever an input FIFO is exhausted or an output FIFO is filled. The processor 181 programs each DMA transfer. The DMA controller 200 generates the address for each word of the transfer on request from the functional unit connected to the channel. The functional unit latches the word onto or off the data bus 186 when its request is acknowledged by the DMA controller 200. The DMA controller 200 interrupts the processor 181 when the transfer is complete, thus allowing the processor 181 to program another transfer on the same channel in a timely fashion. In general the processor 181 will program another transfer on a channel as soon as the corresponding main memory FIFO is available (i.e. non-empty for a read, non-full for a write). The granularity of channel servicing implemented in the DMA controller 200 depends somewhat on the latency of main memory 182. 7.2.2 EDRL Expander The EDRL expander unit (EEU) 188 is shown in greater detail in FIG. 20. The unit 188 decompresses an EDRL-compressed bi-level image. The input to the EEU 188 is an EDRL bitstream. The output from the EEU is a set of bi-level image lines, scaled horizontally from the resolution of the expanded bi-level image by an integer scale factor to 1600 dpi. Once started, the EEU 188 proceeds until it detects an end-of-page code in the EDRL bitstream, or until it is explicitly stopped via its control register. The EEU 188 relies on an explicit page width to decode the bitstream. This must be written to a page width register 202 prior to starting the EEU 188. The scaling of the expanded bi-level image relies on an explicit scale factor. This must be written to a scale factor register 204 prior to starting the EEU 188. TABLE-US-00019 TABLE 17 EDRL expander control and configuration registers register width description start 1 Start the EEU. stop 1 Stop the EEU. page width 13 Page width used during decoding to detect end-of-line. scale factor 4 Scale factor used during scaling of expanded image. The EDRL compression format is described in Section 6.2.3.2. It represents a bi-level image in terms of its edges. Each edge in each line is coded relative to an edge in the previous line, or relative to the previous edge in the same line. No matter how it is coded, each edge is ultimately decoded to its distance from the previous edge in the same line. This distance, or runlength, is then decoded to the string of one bits or zero bits which represent the corresponding part of the image. The decompression algorithm is defined in Section 6.2.3.2. The EEU 188 consists of a bitstream decoder 206, a state machine 208, edge calculation logic 210, two runlength decoders 212, and a runlength (re)encoder 214. The bitstream decoder 206 decodes an entropy-coded codeword from the bitstream and passes it to the state machine 208. The state machine 208 returns the size of the codeword to the bitstream decoder 206, which allows the decoder 206 to advance to the next codeword. In the case of a create edge code, the state machine 208 uses the bitstream decoder 206 to extract the corresponding runlength from the bitstream. The state machine 208 controls the edge calculation logic 210 and runlength decoding/encoding as defined in Table 19. The edge calculation logic 210 is quite simple. The current edge offset in the previous (reference) and current (coding) lines are maintained in a reference edge register 216 and edge register 218 respectively. The runlength associated with a create edge code is output directly to the runlength decoder 212.1, and is added to the current edge. A delta code is translated into a runlength by adding the associated delta to the reference edge and subtracting the current edge. The generated runlength is output to the runlength decoder 212.1, and is added to the current edge. The next runlength is extracted from the runlength encoder 214 and added to the reference edge. A kill edge code simply causes the current reference edge to be skipped. Again the next runlength is extracted from the runlength encoder 214 and added to the reference edge. Each time the edge calculation logic 210 generates a runlength representing an edge, it is passed to the runlength decoder 212.1. While the runlength decoder 212.1 decodes the run it generates a stall signal to the state machine 208. Since the runlength decoder 212 is slower than the edge calculation logic 210, there is not much point in decoupling it. The expanded line accumulates in a line buffer 220 large enough to hold an 8.5'' 800 dpi line (850 bytes). The previously expanded line is also buffered in a buffer 222. It acts as a reference for the decoding of the current line. The previous line is re-encoded as runlengths on demand. This is less expensive than buffering the decoded runlengths of the previous line, since the worst case is one 13-bit runlength for each pixel (20 KB at 1600 dpi). While the runlength encoder 214 encodes the run it generates a stall signal to the state machine 208. The runlength encoder 214 uses the page width to detect end-of-line. The (current) line buffer 220 and the previous line buffer 222 are concatenated and managed as a single FIFO to simplify the runlength encoder 214. The second runlength decoder 212.2 decodes the output runlength to a line buffer 224 large enough to hold an 8.5'' 1600 dpi line (1700 bytes). The runlength passed to this output runlength decoder 212.2 is multiplied by the scale factor from the register 204, so this decoder 212.2 produces 1600 dpi lines. The line is output scale factor times through the output pixel FIFO. This achieves the required vertical scaling by simple line replication. The EEU 188 could be designed with edge smoothing integrated into its image scaling. A simple smoothing scheme based on template-matching can be very effective. This would require a multi-line buffer between the low-resolution runlength decoder and the smooth scaling unit, but would eliminate the high-resolution runlength decoder. 7.2.2.1 EDRL Stream Decoder The EDRL stream decoder 206 (FIG. 21) decodes entropy-coded EDRL codewords in the input bitstream. It uses a two-byte input buffer 226 viewed through a 16-bit barrel shifter 228 whose left (most significant) edge is always aligned to a codeword boundary in the bitstream. A decoder 230 connected to the barrel shifter 228 decodes a codeword according to Table 18, and supplies the state machine 208 with the corresponding code. TABLE-US-00020 TABLE 18 EDRL stream codeword decoding table input codeword output code bit pattern.sup.a output code bit pattern 1xxx xxxx .DELTA.0 1 0000 0000 010x xxxx .DELTA.+1 0 1000 0000 011x xxxx .DELTA.-1 0 0100 0000 0010 xxxx kill edge 0 0010 0000 0011 xxxx create near edge 0 0001 0000 0001 0xxx .DELTA.+2 0 0000 1000 0001 1xxx .DELTA.-2 0 0000 0100 0000 1xxx create far edge 0 0000 0010 0000 01xx end-of-page (EOP) 0 0000 0001 .sup.ax = don't care The state machine 208 in turn outputs the length of the code. This is added, modulo-8, by an accumulator 232 to the current codeword bit offset to yield the next codeword bit offset. The bit offset in turn controls the barrel shifter 228. If the codeword bit offset wraps, then the carry bit controls the latching of the next byte from the input FIFO. At this time byte 2 is latched to byte 1, and the FIFO output is latched to byte 2. It takes two cycles of length 8 to fill the input buffer. This is handled by starting states in the state machine 208. 7.2.2.2 EDRL Expander State Machine The EDRL expander state machine 208 controls the edge calculation and runlength expansion logic in response to codes supplied by the EDRL stream decoder 206. It supplies the EDRL stream decoder 206 with the length of the current codeword and supplies the edge calculation logic 210 with the delta value associated with the current delta code. The state machine 206 also responds to start and stop control signals from a control register 234 (FIG. 20), and the end-of-line (EOL) signal from the edge calculation logic 210. The state machine 208 also controls the multi-cycle fetch of the runlength associated with a create edge code. TABLE-US-00021 TABLE 19 EDRL expander state machine input input current code signal code state next state len delta actions start -- stopped starting 8 -- -- -- -- starting idle 8 -- -- stop -- -- stopped 0 -- reset RL decoders and FIFOs EOL -- -- EOL 1 0 -- reset RL encoder; reset RL decoders; reset ref. edge and edge -- -- EOL 1 idle RL encoder .fwdarw. ref. RL; ref. edge + ref. RL .fwdarw. ref. edge -- .DELTA.0 idle idle 1 0 edge - ref. edge + delta .fwdarw. RL; edge + RL .fwdarw. edge; RL .fwdarw. RL decoder; RL encoder .fwdarw. ref. RL; ref. edge + ref. RL .fwdarw. ref. edge -- .DELTA.+1 idle idle 2 +1 edge - ref. edge + delta .fwdarw. RL; edge + RL .fwdarw. edge; RL .fwdarw. RL decoder; RL encoder .fwdarw. ref. RL; ref. edge + ref. RL .fwdarw. ref. edge -- .DELTA.-1 idle idle 3 -1 edge - ref. edge + delta .fwdarw. RL; edge + RL .fwdarw. edge; RL .fwdarw. RL decoder; RL encoder .fwdarw. ref. RL; ref. edge + ref. RL .fwdarw. ref. edge -- .DELTA.+2 idle idle 4 +2 edge - ref. edge + delta .fwdarw. RL; edge + RL .fwdarw. edge; RL .fwdarw. RL decoder; RL encoder .fwdarw. ref. RL; ref. edge + ref. RL .fwdarw. ref. edge -- .DELTA.-2 idle idle 5 -2 edge - ref. edge + delta .fwdarw. RL; edge + RL .fwdarw. edge; RL .fwdarw. RL decoder; RL encoder .fwdarw. ref. RL; ref. edge + ref. RL .fwdarw. ref. edge -- kill idle idle 6 -- RL encoder edge .fwdarw. ref. RL; ref. edge + ref. RL .fwdarw. ref. edge -- create idle create RL lo 7 7 -- reset create RL near edge -- create idle create RL hi 6 8 -- -- far edge -- EOP idle stopped 8 -- -- -- -- create RL create RL lo 7 6 -- latch hi 6 create RL hi 6 -- -- create RL create edge 7 -- latch lo 7 create RL lo 7 -- -- create idle 0 -- create RL .fwdarw. RL; edge edge + RL .fwdarw. edge; RL .fwdarw. RL encoder 7.2.2.3 Runlength Decoder The runlength decoder 212 expands a runlength into a sequence of zero bits or one bits of the corresponding length in the output stream. The first run in a line is assumed to be white (color 0). Each run is assumed to be of the opposite color to its predecessor. If the first run is actually black (color 1), then it must be preceded by a zero-length white run. The runlength decoder 212 keeps track of the current color internally. The runlength decoder 212 appends a maximum of 8 bits to the output stream every clock. Runlengths are typically not an integer multiple of 8, and so runs other than the first in an image are typically not byte-aligned. The runlength decoder 212 maintains, in a byte space register 236 (FIG. 22), the number of bits available in the byte currently being built. This is initialized to 8 at the beginning of decoding, and on the output of every byte. The decoder 212 starts outputting a run of bits as soon as the next run line 248 latches a non-zero value into a runlength register 238. The decoder 212 effectively stalls when the runlength register 238 goes to zero. A number of bits of the current color are shifted into an output byte register 240 each clock. The current color is maintained in a 1-bit color register 242. The number of bits actually output is limited by the number of bits left in the runlength, and by the number of spare bits left in the output byte. The number of bits output is subtracted from the runlength and the byte space. When the runlength goes to zero it has been completely decoded, although the trailing bits of the run may still be in the output byte register 240, pending output. When the byte space goes to zero the output byte is full and is appended to the output stream. A 16-bit barrel shifter 244, the output byte register 240 and the color register 242 together implement an 8-bit shift register which can be shifted multiple bit positions every clock, with the color as the serial input. An external reset line 246 is used to reset the runlength decoder 212 at the start of a line. An external next run line 248 is used to request the decoding of a new runlength. It is accompanied by a runlength on an external runlength line 250. The next run line 248 should not be set on the same clock as the reset line 246. Because next run inverts the current color, the reset of the color sets it to one, not zero. An external flush line 252 is used to flush the last byte of the run, if incomplete. It can be used on a line-by-line basis to yield byte-aligned lines, or on an image basis to yield a byte-aligned image. An external ready line 254 indicates whether the runlength decoder 212 is ready to decode a runlength. It can be used to stall the external logic. 7.2.2.4 Runlength Encoder The runlength encoder 214 detects a run of zero or one bits in the input stream. The first run in a line is assumed to be white (color 0). Each run is assumed to be of the opposite color to its predecessor. If the first run is actually black (color 1), then the runlength encoder 214 generates a zero-length white run at the start of the line. The runlength decoder keeps track of the current color internally. The runlength encoder 214 reads a maximum of 8 bits from the input stream every clock. It uses a two-byte input buffer 256 (FIG. 23) viewed through a 16-bit barrel shifter 258 whose left (most significant) edge is always aligned to the current position in the bitstream. An encoder 260 connected to the barrel shifter 258 encodes an 8-bit (partial) runlength according to Table 20. The 8-bit runlength encoder 260 uses the current color to recognize runs of the appropriate color. The 8-bit runlength generated by the 8-bit runlength encoder 260 is added to the value in a runlength register 262. When the 8-bit runlength encoder 260 recognizes the end of the current run it generates an end-of-run signal which is latched by a ready register 264. The output of the ready register 264 indicates that the encoder 214 has completed encoding the current runlength, accumulated in the runlength register 262. The output of the ready register 264 is also used to stall the 8-bit runlength encoder 260. When stalled the 8-bit runlength encoder 260 outputs a zero-length run and a zero end-of-run signal, effectively stalling the entire runlength encoder 214. TABLE-US-00022 TABLE 20 8-bit runlength encoder table Color input length end-of-run 0 0000 0000 8 0 0 0000 0001 7 1 0 0000 001x 6 1 0 0000 01xx 5 1 0 0000 1xxx 4 1 0 0001 xxxx 3 1 0 001x xxxx 2 1 0 01xx xxxx 1 1 0 1xxx xxxx 0 1 1 1111 1111 8 0 1 1111 1110 7 1 1 1111 110x 6 1 1 1111 10xx 5 1 1 1111 0xxx 4 1 1 1110 xxxx 3 1 1 110x xxxx 2 1 1 10xx xxxx 1 1 1 0xxx xxxx 0 1 The output of the 8-bit runlength encoder 260 is limited by the remaining page width. The actual 8-bit runlength is subtracted from the remaining page width, and is added to a modulo-8 bit position accumulator 266 used to control the barrel shifter 258 and clock the byte stream input. An external reset line 268 is used to reset the runlength encoder 214 at the start of a line. It resets the current color and latches a page width signal on line 270 into a page width register 272. An external next run line 274 is used to request another runlength from the runlength encoder 214. It inverts the current color, and resets the runlength register 262 and ready register 264. An external flush line 276 is used to flush the last byte of the run, if incomplete. It can be used on a line-by-line basis to process byte-aligned lines, or on an image basis to process a byte-aligned image. An external ready line 278 indicates that the runlength encoder 214 is ready to encode a runlength, and that the current runlength is available on a runlength line 280. It can be used to stall the external logic. 7.2.2.5 Timing The EEU 188 has an output rate of 124M 1-bit black pixels/s. The core logic generates one runlength every clock. The runlength decoders 212 and the runlength encoder 214 generate/consume up to 8 pixels (bits) per clock. One runlength decoder 212.1 and the runlength encoder 214 operate at quarter resolution (800 dpi). The other runlength decoder 212.2 operates at full resolution (1600 dpi). A worst-case bi-level image consisting of a full page of 3 point text converts to approximately 6M runlengths at 800 dpi (the rendering resolution). At 1600 dpi (the horizontal output resolution) this gives an average runlength of about 20. Consequently about 40% of 8-pixel output bytes span two runs and so require two clocks instead of one. Output lines are replicated vertically to achieve a vertical resolution of 1600 dpi. When a line is being replicated rather than generated it has a perfect efficiency of 8 pixels per clock, thus the overhead is halved to 20%. The full-resolution runlength decoder in the output stage of the EEU 188 is the slowest component in the EEU 188. The minimum clock speed of the EEU 188 is therefore dictated by the output pixel rate of the EEU (124 Mpixels/s), divided by the width of the runlength decoder (8), adjusted for its worst-case overhead (20%). This gives a minimum speed of about 22 MHz. 7.2.3 JPEG Decoder The JPEG decoder 196 (FIG. 24) decompresses a JPEG-compressed CMYK contone image. The input to the JPEG decoder 196 is a JPEG bitstream. The output from the JPEG decoder 196 is a set of contone CMYK image lines. When decompressing, the JPEG decoder 196 writes its output in the form of 8.times.8 pixel blocks. These are sometimes converted to full-width lines via an page width.times.8 strip buffer closely coupled with the codec. This would require a 67 KB buffer. We instead use 8 parallel pixel FIFOs 282 with shared bus access and 8 corresponding DMA channels, as shown in FIG. 24. 7.2.3.1 Timing The JPEG decoder 196 has an output rate of 3.5M 32-bit CMYK pixels/s. The required clock speed of the decoder depends on the design of the decoder. 7.2.4 Halftoner/Compositor The halftoner/compositor unit (HCU) 190 (FIG. 25) combines the functions of halftoning the contone CMYK layer to bi-level CMYK, and compositing the black layer over the halftoned contone layer. The input to the HCU 190 is an expanded 267 ppi CMYK contone layer, and an expanded 1600 dpi black layer. The output from the HCU 190 is a set of 1600 dpi bi-level CMYK image lines. Once started, the HCU 190 proceeds until it detects an end-of-page condition, or until it is explicitly stopped via its control register 284. The HCU 190 generates a page of dots of a specified width and length. The width and length must be written to page width and page length registers of the control registers 284 prior to starting the HCU 190. The page width corresponds to the width of the printhead. The page length corresponds to the length of the target page. The HCU 190 generates target page data between specified left and right margins relative to the page width. The positions of the left and right margins must be written to left margin and right margin registers of the control registers 284 prior to starting the HCU 190. The distance from the left margin to the right margin corresponds to the target page width. The HCU 190 consumes black and contone data according to specified black and contone page widths. These page widths must be written to black page width and contone page width registers of the control registers 284 prior to starting the HCU190. The HCU 190 clips black and contone data to the target page width. This allows the black and contone page widths to exceed the target page width without requiring any special end-of-line logic at the input FIFO level. The relationships between the page width, the black and contone page widths, and the margins are illustrated in FIG. 26. The HCU 190 scales contone data to printer resolution both horizontally and vertically based on a specified scale factor. This scale factor must be written to a contone scale factor register of the control registers 284 prior to starting the HCU 190. TABLE-US-00023 TABLE 21 Halftoner/compositor control and configuration registers register width description start 1 Start the HCU. stop 1 Stop the HCU. page width 14 Page width of printed page, in dots. This is the number of dots which have to be generated for each line. left margin 14 Position of left margin, in dots. right margin 14 Position of right margin, in dots. page length 15 Page length of printed page, in dots. This is the number of lines which have to be generated for each page. black page width 14 Page width of black layer, in dots. Used to detect the end of a black line. contone page width 14 Page width of contone layer, in dots. Used to detect the end of a contone line. contone 4 Scale factor used to scale contone data to scale factor bi-level resolution. The consumer of the data produced by the HCU 190 is the printhead interface 192. The printhead interface 192 requires bi-level CMYK image data in planar format, i.e. with the color planes separated. Further, it also requires that even and odd pixels are separated. The output stage of the HCU 190 therefore uses 8 parallel pixel FIFOs 286, one each for even cyan, odd cyan, even magenta, odd magenta, even yellow, odd yellow, even black, and odd black. An input contone CMYK FIFO 288 is a full 9 KB line buffer. The line is used contone scale factor times to effect vertical up-scaling via line replication. FIFO write address wrapping is disabled until the start of the last use of the line. An alternative is to read the line from main memory contone scale factor times, increasing memory traffic by 44 MB/s, but avoiding the need for the on-chip 9 KB line buffer. 7.2.4.1 Multi-Threshold Dither A multi-threshold dither unit 290 is shown in FIG. 27 of the drawings. A general 256-layer dither volume provides great flexibility in dither cell design, by decoupling different intensity levels. General dither volumes can be large--a 64.times.64.times.256 dither volume, for example, has a size of 128 KB. They are also inefficient to access since each color component requires the retrieval of a different bit from the volume. In practice, there is no need to fully decouple each layer of the dither volume. Each dot column of the volume can be implemented as a fixed set of thresholds rather than 256 separate bits. Using three 8-bit thresholds, for example, only consumes 24 bits. Now, n thresholds define n+1 intensity intervals, within which the corresponding dither cell location is alternately not set or set. The contone pixel value being dithered uniquely selects one of the n+1 intervals, and this determines the value of the corresponding output dot. We dither the contone data using a triple-threshold 64.times.64.times.3.times.8-bit (12 KB) dither volume. The three thresholds form a convenient 24-bit value which can be retrieved from the dither cell ROM in one cycle. If dither cell registration is desired between color planes, then the same triple-threshold value can be retrieved once and used to dither each color component. If dither cell registration is not desired, then the dither cell can be split into four subcells and stored in four separately addressable ROMs from which four different triple-threshold values can be retrieved in parallel in one cycle. Using the addressing scheme shown below, the four color planes share the same dither cell at vertical and/or horizontal offsets of 32 dots from each other. Each triple-threshold unit 292 converts a triple-threshold value and an intensity value into an interval and thence a one or zero bit. The triple-thresholding rules are shown in Table 22. The corresponding logic is shown in FIG. 28. TABLE-US-00024 TABLE 22 Triple-thresholding rules interval output V .ltoreq. T.sub.1 0 T.sub.1 < V .ltoreq. T.sub.2 1 T.sub.2 < V .ltoreq. T.sub.3 0 T.sub.3 < V 1 7.2.4.2 Composite A composite unit 294 of the HCU 190 composites a black layer dot over a halftoned CMYK layer dot. If the black layer opacity is one, then the halftoned CMY is set to zero. Given a 4-bit halftoned color C.sub.cM.sub.cY.sub.cK.sub.c and a 1-bit black layer opacity K.sub.b, the composite logic is as defined in Table 23. TABLE-US-00025 TABLE 23 Composite logic color channel condition C C.sub.c K.sub.b M M.sub.c K.sub.b Y Y.sub.c K.sub.b K K.sub.c K.sub.b 7.2.4.3 Clock Enable Generator A clock enable generator 296 of the HCU 190 generates enable signals for clocking the contone CMYK pixel input, the black dot input, and the CMYK dot output. As described earlier, the contone pixel input buffer is used as both a line buffer and a FIFO. Each line is read once and then used contone scale factor times. FIFO write address wrapping is disabled until the start of the final replicated use of the line, at which time the clock enable generator 296 generates a contone line advance enable signal which enables wrapping. The clock enable generator 296 also generates an even signal which is used to select the even or odd set of output dot FIFOs, and a margin signal which is used to generate white dots when the current dot position is in the left or right margin of the page. The clock enable generator 296 uses a set of counters. The internal logic of the counters is defined in Table 24. The logic of the clock enable signals is defined in Table 25. TABLE-US-00026 TABLE 24 Clock enable generator counter logic load decrement counter abbr. w. data condition condition dot D 14 page width RP.sup.a EOL.sup.b (D>0) clk line L 15 page length RP (L>0) EOL left margin LM 14 left margin RP EOL (LM>0) clk right margin RM 14 right RP EOL (RM>0) clk margin even/odd dot E 1 0 RP EOL clk black dot BD 14 black width RP EOL (LM=0) (BD > 0) clk contone dot CD 14 contone RP EOL (LM=0) (CD > 0) clk width contone CSP 4 contone RP EOL (LM=0) clk sub-pixel scale factor (CSP=0) contone CSL 4 contone RP (CSL=0) EOL clk sub-line scale factor .sup.aRP (reset page) condition: external signal .sup.bEOL (end-of-line) condition: (D=0) (BD=0) (CD=0) TABLE-US-00027 TABLE 25 Clock enable generator output signal logic output signal condition output dot clock enable (D>0) EOP black dot clock enable (LM=0) (BD>0) EOP contone pixel clock enable (LM=0) (CD>0) (CSP=0) EOP contone line advance enable (CSL=0) EOP even E=0 margin (LM=0) (RM=0) .sup.aEOP (end-of-page) condition: L = 0 7.2.4.4 Timing The HCU 190 has an output rate of 124 M 4-bit CMYK pixels/s. Since it generates one pixel per clock, it must be clocked at at least 124 MHz. 7.3 Printhead Interface CePrint 10 uses an 8.5'' CMYK Memjet printhead 143, as described in Section 9. The printhead consists of 17 segments arranged in 2 segment groups. The first segment group contains 9 segments, and the second group contains 8 segments. There are 13,600 nozzles of each color in the printhead 143, making a total of 54,400 nozzles. The printhead interface 192 is a standard Memjet printhead interface, as described in Section 10, configured with the following operating parameters: MaxColors=4 SegmentsPerXfer=9 SegmentGroups=2 Although the printhead interface 192 has a number of external connections, not all are used for an 8.5'' printhead, so not all are connected to external pins on the CCP 180. Specifically, the value for SegmentGroups implies that there are only 2 SRClock pins and 2 SenseSegSelect pins. All 36 ColorData pins, however, are required. 7.3.1 Timing CePrint 10 prints an 8.3''.times.11.7'' page in 2 seconds. The printhead 143 must therefore print 18,720 lines (11.7''.times.1600 dpi ) in 2 seconds, which yields a line time of about 107 .mu.s. Within the printhead interface 192, a single Print Cycle and a single Load Cycle must both complete within this time. In addition, the paper 144 must advance by about 16 .mu.m in the same time. In high-speed print mode the Memjet printhead 143 can print an entire line in 100 .mu.s. Since all segments fire at the same time 544 nozzles are fired simultaneously with each firing pulse. This leaves 7 .mu.s for other tasks between each line. The 1600 SRClock pulses (800 each of SRClock1 and SRClock2) to the printhead 143 (SRClock1 has 36 bits of valid data, and SRClock2 has 32 bits of valid data) must also take place within the 107 .mu.s line time. Restricting the timing to 100 .mu.s, the length of an SRClock pulse cannot exceed 100 .mu.s/1600=62.5 ns. The printhead 143 must therefore be clocked at 16 MHz. The printhead interface 192 has a nominal pixel rate of 124M 4-bit CMYK pixels/s. However, because it is only active for 100 .mu.s out of every 107 .mu.s, it must be clocked at at least 140 MHz. This can be increased to 144 MHz to make it an integer multiple of the printhead speed. 7.4 Processor and Memory 7.4.1 Processor The processor 181 runs the control program which synchronizes the other functional units during page reception, expansion and printing. It also runs the device drivers for the various external interfaces, and responds to user actions through the user interface. It must have low interrupt latency, to provide efficient DMA management, but otherwise does not need to be particularly high-performance. 7.4.2 DMA Controller The DMA controller 200 supports single-address transfers on 29 channels (see Table 26). It generates vectored interrupts to the processor 181 on transfer completion. TABLE-US-00028 TABLE 26 DMA channel usage functional unit input channels output channels host interface -- 1 inter-CCP interface 1 1 EDRL expander 1 1 JPEG decoder 1 8 halftoner/compositor 2 8 speaker interface 1 -- printhead interface 4 -- 10 19 29 7.4.3 Program ROM A program ROM 298 holds the CCP 180 control program which is loaded into main memory 182 during system boot. 7.4.4 Rambus Interface The Rambus interface 198 provides the high-speed interface to the external 8 MB (64 Mbit) Rambus DRAM (RDRAM) 182. 7.5 External Interfaces 7.5.1 Host Interface The host interface 194 provides a connection to the host processor with a speed of at least 1.5 MB/s (or 3 MB/s for the double-sided version of CePrint). 7.5.2 Speaker Interface A speaker interface 300 (FIG. 29) contains a small FIFO 302 used for DMA-mediated transfers of sound clips from main memory 182, an 8-bit digital-to-analog converter (DAC) 304 which converts each 8-bit sample value to a voltage, and an amplifier 306 which feeds an external speaker 308 (FIG. 18). When the FIFO 302 is empty it outputs a zero value. The speaker interface 300 is clocked at the frequency of the sound clips. The processor 181 outputs a sound clip to the speaker 308 simply by programming the DMA channel of the speaker interface 300. 7.5.3 Parallel Interface A parallel interface 309 provides I/O on a number of parallel external signal lines. It allows the processor 181 to sense or control the devices listed in Table 27. TABLE-US-00029 TABLE 27 Parallel Interface devices parallel interface devices power button power LED out-of-paper LED out-of-ink LED media sensor paper pick-up roller position sensor paper tray drive position sensor paper pick-up motor paper tray ejector motor transfer roller stepper motor 7.5.4 Serial Interface A serial interface 310 provides two standard low-speed serial ports. One port is used to connect to the master QA chip 184. The other is used to connect to a QA chip 312 in the ink cartridge. The processor-mediated protocol between the two is used to authenticate the ink cartridge. The processor 181 can then retrieve ink characteristics from the QA chip 312, as well as the remaining volume of each ink. The processor 181 uses the ink characteristics to properly configure the Memjet printhead 143. It uses the remaining ink volumes, updated on a page-by-page basis with ink consumption information accumulated by the printhead interface 192, to ensure that it never allows the printhead 143 to be damaged by running dry. 7.5.4.1 Ink Cartridge QA Chip The QA chip 312 in the ink cartridge 32 contains information required for maintaining the best possible print quality, and is implemented using an authentication chip. The 256 bits of data in the authentication chip are allocated as follows: TABLE-US-00030 TABLE 28 Ink cartridge's 256 bits (16 entries of 16-bits) M[n] access width description 0 RO.sup.a 16 Basic header, flags etc. 1 RO 16 Serial number. 2 RO 16 Batch number. 3 RO 16 Reserved for future expansion. Must be 0. 4 RO 16 Cyan ink properties. 5 RO 16 Magenta ink properties. 6 RO 16 Yellow ink properties. 7 RO 16 Black ink properties. 8 9 DO.sup.b 32 Cyan ink remaining, in nanolitres. 10 11 DO 32 Magenta ink remaining, in nanolitres. 12 13 DO 32 Yellow ink remaining, in nanolitres. 14 15 DO 32 Black ink remaining, in nanolitres. .sup.aread only (RO) .sup.bdecrement only (DO) Before each page is printed, the processor 181 must check the amount of ink remaining to ensure there is enough for an entire worst-case page. Once the page has been printed, the processor 181 multiplies the total number of drops of each color (obtained from the printhead interface 192) by the drop volume. The amount of printed ink is subtracted from the amount of ink remaining. The unit of measurement for ink remaining is nanolitres, so 32 bits can represent over 4 liters of ink. The amount of ink used for a page must be rounded up to the nearest nanolitre (i.e. approximately 1000 printed dots). 7.5.5 Inter-CCP Interface An inter-CCP interface 314 provides a bi-directional high-speed serial communications link to a second CCP, and is used in multi-CCP configurations such as the double-sided version of the printer which contains two CCPs. The link has a minimum speed of 30 MB/s, to support timely distribution of page data, and may be implemented using a technology such as IEEE 1394 or Rambus. 7.5.6 JTAG Interface A standard JTAG (Joint Test Action Group) interface (not shown) is included for testing purposes. Due to the complexity of the chip, a variety of testing techniques are required, including BIST (Built In Self Test) and functional block isolation. An overhead of 10% in chip area is assumed for overall chip testing circuitry. 8 Double-Sided Printing The double-sided version of CePrint contains two complete print engines or printing units 140--one for the front of the paper, one for the back. Each printing unit 140 consists of a printer controller 178, a printhead assembly 142 containing a Memjet printhead 143, and a transfer roller 68. Both printing units 140 share the same ink supply. The back side, or lower, printing unit 140 acts as the master unit. It is responsible for global printer functions, such as communicating with the host, handling the ink cartridge 32, handling the user interface, and controlling the paper transport. The front side, or upper, printing unit 140 acts as a slave unit. It obtains pages from the host processor via the master unit, and is synchronized by the master unit during printing. Both printer controllers 178 consist of a CePrint central processor (CCP) 180 and a local 8 MB RDRAM 182. The external interfaces of the master unit are used in the same way as in the single-sided version of CePrint, but only the memory interface 198 and the printhead interface 192 of the slave unit are used. An external master/slave pin on the CCP 180 selects the mode of operation. This dual printer controller configuration is illustrated in FIG. 30. 8.1 Page Delivery and Distribution The master CCP 180M (FIG. 30) presents a unified view of the printer 10 to the host processor. It hides the presence of the slave CCP 180S. Pages are transmitted from the host processor to the printer 10 in page order. The first page of a document is always a front side page, and front side and back side pages are always interleaved. Thus odd-numbered pages are front side pages, and even-numbered pages are back side pages. To print in single-sided mode on either the front side or back side of the paper, the host must send appropriate blank pages to the printer 10. The printer 10 expects a page description for every page. When the master CCP 180M receives a page command from the host processor relating to an odd-numbered page it routes the command to the slave CCP 180S via the inter-CCP serial link 314. To avoid imposing undue restrictions on the host link and its protocol, each command is received in its entirety and stored in the master's local memory 182M before being forwarded to the memory 182S of the slave. This introduces only a small delay because the inter-CCP link 314 is fast. To ensure that the master CCP 180M always has a page buffer available for a page destined for the slave, the master is deliberately made the back side CCP, so that it receives the front side odd-numbered page before it receives the matching back side even-numbered page. 8.2 Synchronized Printing Once the master CCP 180M and the slave CCP 180S have received their pages, the master CCP 180M initiates actual printing. This consists of starting the page expansion and printing processes in the master CCP 180M, and initiating the same processes in the slave CCP 180S via a command sent over the inter-CCP serial link 314. To achieve perfect registration between the front side and back side printed pages, the printhead interfaces 192 of both CCPs are synchronized to a common line synchronization signal. The synchronization signal is generated by the master CCP 180M. Once the printing pipelines in both CCPs are sufficiently primed, as indicated by the stall status of the line loader/format unit (LLFU) of the printhead interface (Section 10.4), the master CCP 180M starts the line synchronization generator unit (LSGU) of the printhead interface 192 (Section 10.2). The master CCP 180M obtains the status of the slave CCP 180S LLFU via a poll sent over the inter-CCP serial link 314. After the printing of a page, or more frequently, the master 180M obtains ink consumption information from the slave 180S over the inter-CCP link 314. It uses this to update the remaining ink volume in the ink cartridge 32, as described in Section 7.5.4.1. The master and slave CCPs 180M, 180S also exchange error events and host-initiated printer reset commands over the inter-CCP link 314. 9 Memjet Printhead The Memjet printhead 143 is a drop-on-demand 1600 dpi inkjet printer that produces bi-level dots in up to 4 colors to produce a printed page of a particular width. Since the printhead prints dots at 1600 dpi, each dot is approximately 22.5 mm in diameter, and spaced 15.875 mm apart. Because the printing is bi-level, the input image should be dithered or error-diffused for best results. Typically a Memjet printhead for a particular application is page-width. This enables the printhead 143 to be stationary and allows the paper 144 to move past the printhead 143. FIG. 31 illustrates a typical configuration. The Memjet printhead 143 is composed of a number of identical 1/2 inch Memjet segments. The segment is therefore the basic building block for constructing the printhead 143. 9.1 The Structure of a Memjet Segment This section examines the structure of a single segment, the basic building block for constructing the Memjet printhead 143. 9.1.1 Grouping of Nozzles within a Segment The nozzles within a single segment are grouped for reasons of physical stability as well as minimization of power consumption during printing. In terms of physical stability, a total of 10 nozzles share the same ink reservoir. In terms of power consumption, groupings are made to enable a low-speed and a high-speed printing mode. Memjet segments support two printing speeds to allow speed/power consumption trade-offs to be made in different product configurations. In the low-speed printing mode, 4 nozzles of each color are fired from the segment at a time. The exact number of nozzles fired depends on how many colors are present in the printhead. In a four color (e.g. CMYK) printing environment this equates to 16 nozzles firing simultaneously. In a three color (e.g. CMY) printing environment this equates to 12 nozzles firing simultaneously. To fire all the nozzles in a segment, 200 different sets of nozzles must be fired. In the high-speed printing mode, 8 nozzles of each color are fired from the segment at a time. The exact number of nozzles fired depends on how many colors are present in the printhead. In a four color (e.g. CMYK) printing environment this equates to 32 nozzles firing simultaneously. In a three color (e.g. CMY) printing environment this equates to 24 nozzles firing simultaneously. To fire all the nozzles in a segment, 100 different sets of nozzles must be fired. The power consumption in the low-speed mode is half that of the high-speed mode. Note, however, that the energy consumed to print a page is the same in both cases. 9.1.1.1 Ten Nozzles Make a Pod A single pod consists of 10 nozzles sharing a common ink reservoir. 5 nozzles are in one row, and 5 are in another. Each nozzle produces dots 22.5 mm in diameter spaced on a 15.875 mm grid to print at 1600 dpi. FIG. 32 shows the arrangement of a single pod, with the nozzles numbered according to the order in which they must be fired. Although the nozzles are fired in this order, the relationship of nozzles and physical placement of dots on the printed page is different. The nozzles from one row represent the even dots from one line on the page, and the nozzles on the other row represent the odd dots from the adjacent line on the page. FIG. 33 shows the same pod with the nozzles numbered according to the order in which they must be loaded. The nozzles within a pod are therefore logically separated by the width of 1 dot. The exact distance between the nozzles will depend on the properties of the Memjet firing mechanism. The printhead 143 is designed with staggered nozzles designed to match the flow of paper. 9.1.1.2 One Pod of Each Color Makes a Chromapod One pod of each color are grouped together into a chromapod. The number of pods in a chromapod will depend on the particular application. In a monochrome printing system (such as one that prints only black), there is only a single color and hence a single pod. Photo printing application printheads require 3 colors (cyan, magenta, yellow), so Memjet segments used for these applications will have 3 pods per chromapod (one pod of each color). The expected maximum number of pods in a chromapod is 4, as used in a CMYK (cyan, magenta, yellow, black) printing system (such as a desktop printer). This maximum of 4 colors is not imposed by any physical constraints--it is merely an expected maximum from the expected applications (of course, as the number of colors increases the cost of the segment increases and the number of these larger segments that can be produced from a single silicon wafer decreases). A chromapod represents different color components of the same horizontal set of 10 dots on different lines. The exact distance between different color pods depends on the Memjet operating parameters, and may vary from one Memjet design to another. The distance is considered to be a constant number of dot-widths, and must therefore be taken into account when printing: the dots printed by the cyan nozzles will be for different lines than those printed by the magenta, yellow or black nozzles. The printing algorithm must allow for a variable distance up to about 8 dot-widths between colors. FIG. 34 illustrates a single chromapod for a CMYK printing application. 9.1.1.3 Five Chromapods Make a Podgroup Five chromapods are organized into a single podgroup. A podgroup therefore contains 50 nozzles for each color. The arrangement is shown in FIG. 35, with chromapods numbered 0 4 and using a CMYK chromapod as the example. Note that the distance between adjacent chromapods is exaggerated for clarity. 9.1.1.4 Two Podgroups Make a Phasegroup Two podgroups are organized into a single phasegroup. The phasegroup is so named because groups of nozzles within a phasegroup are fired simultaneously during a given firing phase (this is explained in more detail below). The formation of a phasegroup from 2 podgroups is ent |