AU2003204222B2 - Variable page composition with page elements cut in strips - Google Patents

Description

i

AUSTRALIA

Patents Act COMPLETE SPECIFICATION

(ORIGINAL)

Class Int. Class Application Number: Lodged: Complete Specification Lodged: Accepted: Published: Priority Related Art: Name of Applicant: Electronics for Imaging, Inc.

Actual Inventor(s): Gahilad Dziesietinik, Luis Trabb Pardo Address for Service and Correspondence: PHILLIPS ORMONDE FITZPATRICK Patent and Trade Mark Attorneys 367 Collins Street Melbourne 3000 AUSTRALIA Invention Title: VARIABLE PAGE COMPOSITION WITH PAGE ELEMENTS CUT IN STRIPS Our Ref POF Code: 694389 459433/341666 The following statement is a full description of this invention, including the best method of performing it known to applicant(s): -1- VARIABLE PAGE COMPOSITION WITH PAGE ELEMENTS CUT IN STRIPS BACKGROUND OF THE INVENTION TECHNICAL FIELD The invention relates to printing data that are stored in an electronic format. More particularly, the invention relates to a method and apparatus for printing variable data.

DESCRIPTION OF THE PRIOR ART A personalized print job is a description of a document composed of a number of copies, where each copy can be uniquely customized for the intended recipient. The pages are composed of text, graphics, and images which can be unique to just that copy, identical on every copy, or used on some copies of the document but not on others. For example, in a customized product brochure, unique elements can include the recipient's name and address, while the product company name and logo are identical on every copy, and the picture of the specific product that the recipient is interested in is found on some copies of the document, but not on others.

A personalization system includes every component that is required to build and print a personalized job. The front end of the system is the job creation process, which is generally driven by a database and authoring applications which build the description of a personalized job. The system also includes a raster image processor (RIP) and a printing system on the back end, which is optimized for the characteristics of the job, i.e. to print the job as fast as is possible.

The RIPing system needs to be able to deliver pages at least as fast as the rated engine speed of the output device. To this end, it must be possible to design a document that is largely made up of reusable page elements. Page tA elements can be text, graphics, images, or a combination thereof. Each peirsonalized copy of a job can contain some unique information and some subset of these reusable page elements arranged by the document designer.

Some of these elements are only used once, some are used on every copy of the document, and some are used only on select copies.

In a personalized job, page elements need only be RIPed once, then combined at the print engine. By only RIPing each element one time, unique documents can be delivered on-the-fly as quickly as possible.

Until now, personalized printing has been limited primarily to mass mailings such as utility and credit card bills, and specialized direct mail pieces. Applications are highly specialized for these specific uses and are costly to implement. Typically such applications have a high development cost, but generate very large volumes resulting in a low per-copy cost that tends to justify the initial high development cost.

For example, target marketing is generally considered to be less expensive and more effective than mass campaigns. Using demographic information to customize messages to the target audience produces significantly higher response rates. As time goes on, more and more information is collected from customer transactions. Companies use this information to customize their messages to their audience. They are then able to minimize their costs while realizing a greater return on investment.

Fig. 1 is a block schematic diagram that shows a general description of the data flow of a personalization front end system. The front end of a personalization system is composed of all of the applications necessary to build a personalized job that is delivered to the RIP. Fig. 1 depicts a simple data flow of the front end applications. It does not show the work flow which is described in more detail later. Such applications come in many shapes and sizes. Most personalization applications contain the above components in one form or another, but do not necessarily use them in the same ways. The majority of the front end applications are built by third party developers specializing in layout design, building graphics, and database design and access.

The following is a general description of the components of a front end system.

Database 14: Contains all of the information that are queried to generate the data set. It may contain demographics for target customers'who receive customized bills or sales information. It could also contain information about a region of the country to drive specific versions of a sale catalog. For example, prices may differ by region, or depending on the current weather in the area, specific kinds of clothes could be chosen.

Page Elements 10: Page definition language describes a picture graphics, or text) to be applied on a page.

A page element is defined in terms of (PDL) PostScript, or HP PCL) or any other graphic format TIFF or HTML).

Layout Description 12: A description of the layout location, bounding box, orientation) of the elements on a page. A job might have layouts for several different pages. Each copy of the document could be made up of a different number of pages using, and possibly reusing, some or all of the layouts. The following convention is used to describe a page layout: Page (Application 1, Application 2, Application); where an Application applies a page element at a page location x,y for purposes of rendering the page element.

Merger 16: Builds the personalization specification file of the job. It uses the layout descriptions, page elements, and database queries to build a description of the final print job. The output of the Merger is a personalized job 18.

In the above example, the components of the process for building a personalized job are separate. Ideally, there are different people with different areas of expertise building each of the components of the job.

The page elements library is built by different artists, or potentially by scanning in different elements. There may be many sources of input for each page element.

The layout description is built by a graphic artist or report designer who creates the layout of the document. This person needs some minimal information about the page elements (such as size and rotation) but does not need to have direct access to the data to build the design. The artist also wants to take into account 3 what database fields contain information to be used in the layout. Again, the specific data are not needed, just information about it. Tools are built to make this design process as easy as possible by providing a clean user interface for describing the representation of the page elements, including location, rotation, scale, and bounding box.

The database is most likely built by an information systems professional. The data can be directly generated from different sources of input such as credit card purchase information and past orders from mail catalogs.

Fig. 2 is a block schematic diagram that illustrates how the personalization components fit into a prior art RIPing system. In the prior art (such as the Supra product manufactured by Adobe Systems Inc.(see Personalized Printing, Adobe Systems Inc. (Octobe. 1996)); see, also D. Punater, R. Gaspar, V.

Kubert, M. Duchesne, Printing Press and Method, U.S. Patent No. 5,043,749 (27 August 1991) and D. Punater, R. Gaspar, V. Kubert, M. Duchesne, Printing Press and Method, U.S. Patent No. 5,136,316 (4 August 1992), the focus is on RIPing jobs on a page parallel basis for fast throughput. The RIPed pages are then combined at the print engine. The prior art provides the ability to cache and reuse RIPed page elements. Multiple RIPs are used to process page elements in parallel. When this is combined with the reusability of those page elements, the result is improved performance for printing personalized jobs.

The 'merging is an automatic process generally done on a server. There should be no manual intervention necessary. All of the rules regulating database queries and'what to do with nonstandard data should be defined before the merging takes place. The merger is tasked with building a personalized job. It queries the database to determine which information to place in each copy of the persbnalized document. It also specifies how many pages go in each copy, which template to use for each page, and which page elements to use in each of the fields in the layout description.

The 'output of the merging process is a personalized job. This job contains a description of the unique data for every copy of the document, as well as the page elements and layout descriptions. It also describes how to access each component.

The RIPing component of a prior art personalization system lies in between the front end system and the print engine. It receives as input from the front end.

4 The RIP is also tightly integrated with the print engine which outputs the resulting personalized print run.

Personalized jobs 18 are delivered to the coordinator 20 inside Adobe's Supra product. The personalization module 22 is notified, and it then begins processing the file. The primary purpose of the personalization module is the.management of page elements which are contained in the page element store 23. The personalization module controls their flow in and out of the system, their rasterization by the various RIPs 27a-27c, and their caching. As the variable data information comes in from the job source, the personalization module determines which page elements are required, whether they have already been rasterized, and which layout descriptions are required for the page. It also processes this information into a simplified form, which it then passes to the compositor (described below). The conpositor, in conjunction with an assembler 24, then uses this information to compose the rasterized page elements into the finished page which is delivered to the print engine 26 for printing.

The page store contains the variable information, page elements, and layout descriptions. Because the page elements and layout descriptions are only referenced in the variable data stream, they must be accessed and cached locally to optimize performance. The page element store, which in a nonpersonalization system contains only full-page raster data, contains rasterized page elements during a personalized job. The personalization module does not send elements to the RIPs twice.

ithe resource checker 21 communicates directly with the personalization module to verify that all the necessarypage elements and templates are present. It does a preflight operation to ensure that the job prints successfully.

the compositor is responsible for combining the rasterized page elements into a final form for delivery to the print engine in real time. It knows the order in which to paint the page elements. Compositors have a full frame buffer of memory to use, several frame buffers, or maybe only enough memory for several bands.

Some compositors composite multiple page elements at once, reading multiple channels simultaneously from the bitmap cache.

One disadvantage of such prior art techniques is the amount of memory and processing power required to store and merge the various elements of a job.

Further, although there is some speed enhancement with such approaches, performance is still far short of that required for most commercial applications.

It would be advantageous to provide a system in which jobs and applications require less compute power and less storage space, and in which RIPing and processing speed is increased.

The discussion of the background to the invention herein is included to explain the context of the invention. This is not to be taken as an admission that any of the material referred to was published, known or part of the common general knowledge in Australia as at the priority date of any of the claims.

SUMMARY OF THE INVENTION The invention concerns variable data printing in which many pages are generated, where each page is defined as a sequence of applications of a label to a page.

For purposes of the discussion herein, the terms "label" and "page element" will be used interchangeably. For purposes of the invention, each application may be described as point of application, label description Thus, a variable data Job (varJob) is made out of variable data pages (varPages). VarPages are composed by merging pregenerated labels. Labels are color separated, encoded Using document compression comprising SDSO and JPEG) rectangular patches. SDO is a. run length based encoding scheme that overlays another compression scheme which may be grid aligned and applied arbitrarily to a page (such as JPEG). See, for example L. Pardo, Image Rendering for Page Printers, PCT Application No. PCT/US96/1 44 and Y. Accad, Apparatus and Method for Hybrid Compression of Raster Data, U.S. Patent Application Serial No. .08/773,65 filed .24 December 1996.

Labels are applied on any position in the page. All necessary clipping is preferably performed before labels are submitted to the VarJob. Optionally, the invention may include hardware for performing such clipping.

Labels'are preprocessed as soon as they become available. Presumably many labels are generated once and applied many times, albeit at different positions in the page. A label preprocessor processes labels after their submission to the job by cutting them into swaths and creating auxiliary information for further planning and scheduling purposes. A page planner analyzes the page composition, estimates times and bandwidth requirements, w:\marieGA6 NODEL5 7893c.doc 6a and prepares a page composition descriptor (PCDesc) that specifies the way that the page is composed. A page composer takes in a PCDesc and the necessary preprocessed labels and composes the page. The resulting page is again color separated and encoded.

According to the present invention there is provided an apparatus for variable data printing, the apparatus including: a multitude of hardware composers operating in parallel, dividing variable data pages into bands, each band assigned to a corresponding one of the hardware composers, wherein a partial composition task is submitted simultaneously to the hardware composers for implementing a label composition scheme; and wherein each hardware composer includes: means for composing the variable data pages by merging pregenerated labels divided into the bands; means for composing a variable data job from the variable data pages; and means for outputting a resulting page.

BRIEF DESCRIPTION OF THE DRAWINGS A preferred embodiment of the present invention will now be described with reference to the accompanying drawings wherein: W:madle\GABNODELvDiv-of-57893-g.doc Fig. 1 is a block schematic diagram that shows a general description of the data flow of a personalization front-end system; Fig. 2 is a block schematic diagram that illustrates how the personalization components fit into a prior art RIPing system; Fig. 3 is a block diagram showing label preprocessing according to the invention; Fig. 4 is a block diagram showing label application according to the invention; Fig. 5 is a block diagram showing a label preprocessor according to the invention; Fig. 6 is a block diagram showing a page planner according to the invention; Fig. 7 is a clock diagram showing a batch planner according to the invention; Fig. 8 is a block diagram showing an adobe interface according to the invention; Fig. 9 is a block diagram showing a page element cache according to the invention; Fig. 10 is a block schematic diagram showing the structure of a hardware composer according to the invention; Fig. 11 is a block schematic diagram showing information flow and structure according to the invention; Fig. 12 is a block schematic diagram of a paint subsystem according to the invention; Fig. 13 is a block schematic diagram of a ComPrep subsystem according to the invention; Fig. 14 is a block schematic diagram of a SendOff subsystem according to the invention; and Fig. 15 is a block schematic representation of a partition scheme showing SRAM control according to the invention.

.7 -8- DETAILED DESCRIPTION OF THE INVENTION The invention concerns variable data printing in which many pages are generated, where each page is defined as a sequence of applications of a label to a page. For purposes of the discussion herein, the terms "label" and "page element" will be used interchangeably. For purposes of the invention, each application may be described as point of application, label description>. Thus, a variable data Job (varJob) is made out of variable data pages (varPages).

VarPages are composed by merging pregenerated labels. Labels are color separated, encoded Using document compression comprising SDSO and JPEG) rectangular patches. SDO is a run length based encoding scheme that overlays another compression scheme which may be grid aligned and applied arbitrarily to a page (such as JPEG). See, for example L. Pardo, Image Rendering for Page Printers, PCT Application No. PCT/US96/1144 and Y.

Accad, Apparatus and Method for Hybrid Compression of Raster Data, U.S.

Patent Application Serial No. 08/773,65 filed 24 December 1996.

Labels are applied on anyposition in the page. All necessary clipping is preferably performed before labels are submitted to the VarJob. Optionally, the invention may include hardware for performing such clipping.

Application of the invention follows the standard opaque set raster operation provided in the PostScript language (manufactured by Adobe Systems, Inc. of San Jose, CA), with a simple generalization that there is a special transparent color that allows for the color below it to be seen. Although the preferred embodiment of the invention is described in connection with the PostScript language, the invention is readily applied to other imaging methods.

Labels are preprocessed as soon as they become available.

Presumably many labels are generated once and applied many times, albeit at different positions in the page. A label preprocessor processes labels after their submission to the job by cutting them into swaths and creating auxiliary information for further planning and scheduling purposes. A page planner analyzes the page composition, estimates times and bandwidth requirements, and prepares a page composition descriptor (PCDesc) that specifies the way the page is composed.

A page composer takes in a PCDesc and the necessary preprocessed labels and composes the page. The resulting page is again color separated and encoded.

W:Amare\GABNODEL%57893c.doc Hardware Composer The Hardware Composer (HWC) implements the label composition algorithm described above. The HWC is connected to a system (Main System) via a bus, e.g. a PCI bus.

Inputs and Output The HWC receives, via the system PCI bus: A series of compose commands, defining the page to be created as a sequence of label applications; The preprocessed labels to be applied; and Pregenerated information about the resulting page, i.e. a pixel type map and a JPEG map.

The HWC, either through the system PCI bus or through an alternative ShipPCI bus, outputs the resulting page encoded and color separated, where such encoding may be accomplished any known encoding scheme.

The HWC processes information at the rate of its components. An HWC based system may parallel process pages by dividing them into as many segments as the number of HWC units it contains, assigning those parts to a unit and submitting the partial composition task simultaneously to all units.

.Label Preprocessing Label preprocessing (Fig. 3) transforms an encoded CMYK label into a color separated representation. This representation is such that an expander may be started at the beginning of any of a set of special scanlines which impose a swath structure onto the label. Label preprocessing also creates a Pixel Type Map of the label. This map defines each pixel's characteristics (discussed in greater detail below).

A system wide parameter: swathHt k jpegStripHt defines the swath height. The swath grid is congruent to the JPEG grid. A special table, the Swath Index, points to the beginning of each swath within the label.

Each entry points to: The beginning SDSO scanline for the swath (this scanline is "absolute" in the sense that it contains no references to the previousscanline). There is one pointer for each color separation; The beginning JPEG strip for the swath. Again, there is one pointer for each color separation; and The corresponding beginning line in the Pixel Type map.

Label Application The application of a label (Fig. 4) defines: An application point in the page: app.coord and An application time app.time. This time is the order of application, s o that if appA is applied before appB, then appA.time appB.time.

Composing by Banding A page is composed by dividing it into bands of height: band.ht m swath.ht Label application is realized by applying labels to each band in appTime order.

Labels are applied to bands by applying only the subsequent swaths that actually overlap with the band, when are located by using the label's Swath Index.

Composing: One preferred method for composing is based on the following tenets: It simplifies compression by using selecting ACS or JPEG compressors based on the decision made in the source labels; It should allow multiple composers with little overhead; SIt should be possible to isolate any full raster access to the inside of the composers. Traffic to and from the composers is only compressed streams.

The composition has two parts: SFirst, compute the Pixel Map for the resulting page, based on the Page Composition Commands and the precomputed label maps; Then, process the page, band by band, composing and compacting each band.

Precompute Page Pixel Map.

This step may be performed on the whole page, or on a band per band basis. It may also be performed as part of the page preprocess (using the main CPU) or as part of the composition process (using the composer CPU).

Compose the Page, band per band.

The Composer works on successive bands, and for each band it performs the following steps: SApply labels: in appTime order. This application generates a Pixel Array for the band; Compress resulting band: using the resulting Pixel Array and the precomputed Pixel Map.

Applying labels to a band.

The following pseudo code listing describes the actual composition for a band: for all (labels that overlap the band) Using label's Swath Index select first swath that overlaps the band; Start ECT Expansion at the selected swath (this.

generates pixels left to right, top to bottom) for all (generated pixel's) if (pixel is above band) Skip part of first swath above band continue; else if (pixel is below band) Done with band break; else if (pixel.tag SDSOTransparent) Inside band: apply bandPixel.color pixel.color; bandPixel.tag pixel.tag; Stop ECT Expansion (for all pixels below band); Compressing the Pixel array for a band.

All pixels in the band are sent to the appropriate compressor (ACS or JPEG).

Tags for band pixels are extracted from the Page Pixel Map.

for all (pixel's in band) switch (pixel.tag) JPEGOpaque: Send pixel.color to JPEG compressor; Send ECTColor to SDSO compressor; break; SDSOOpaque: Send pixel.color of SDSO compressor; Send blank color to JPEG compressor; break; SDSOTransp: Send background.color to SDSO compressor; Send blank color to JPEG compressor; break; Parallel Composing Composers may be used in parallel, one composer per band. After the bands are composed, a stitching process ties all the bands together into the resulting page.

Top Level Modules Label Preprocessor (Fig. Module: Parallel Color Separation, with swath generation.

Module: Swath Index Generation Module: JPEG/Transparency Map Generation Module: ECT Parsing, Color Separation and Generation services Page Planner (Fig. 6) Module: Resulting Page Map computation Module: Resulting JPEG Vector Generation.

13 Module: Estimate Page Complexity, Bandwidth requirements needed to compose the resulting page and design a way to describe them (Page Complexity Descriptor).

Module: Generate Page Composition Descriptor.

Batch Planner (Fig. 7) This subsystem maximizes the engine paper movement. The Engine Page FlowDescriptor summarizes the engine characteristics start and stop delays, warm and rev up times) Module: Batcher: gets Page Complexity Descriptors and decides on page batches given engine characteristics.

Adobe Interface (Fig. 8) Module: "Adobe Page Commands" to Page Composition Commands Module: Page Element Cache (top level interface) (Fig. 9) Rotation Option Assume a Page Composer with Rotate180 Capabilities.

Extend Page Elt. Cache Extend Page Planner.

Multiple Storage Hierarchy Option Extend Cache, including local memory and disk storage.

Module: Object location and swapping layers.

Module: Storage management policy. (Use standard operating systems paging strategies) Module: Bandwidth management.

Structure Fig. 10 is a block schematic diagram showing the structure of an HWC according to the invention. The preferred embodiment of the invention isolates the composer into an autonomous unit, with its own internal local PCI bus 31, communicating with the rest of the system via two PCI bridges 30, 32.

The local PClbus 31 handles all internal traffic between modules, including all the component setup via CSR setting. For purposes of the discussion herein, PCI refers to a bus and protocol therefor, and CSR refers to control and status registers. Writing to and reading from the CSR registers establishes control and communications between hardware elements in the bus. The system PCI bridge 32 handles all of HWC inputs that are received through this bus. In many systems, the system PCI bridge also carries the resulting pages. Communication and synchronization with the main system (not shown) (by means of a messaging protocol) also takes place through the system PCI bridge. The main CPU and composer communicate via a stream of commands created by the main CPU.

The commands carry information about how to apply labels.

The shipOut PCI bridge 30 connects to the shipOut bus, which is dedicated to the transport of resulting pages to the printer queue. The shipOut bus is used in very high page rate systems and systems that require a fairly unloaded system PCI bus. Other embodiments of the invention may use the system PCI bridge for transport of print jobs to the printer queue.

An expander subsystem 43 has two input streams, i.e. an SDSO stream and a JPEG stream. For output, the video signal is synchronized by a signal provided by a synch bus. The video bus 48 provides a CMYK color stream, which is the aggregation of four single plane color outputs (32 bits).

The expander module 43 is controlled by the composer CPU 36, which sets input streams for each expander and which stops the expanders after each label application.

A JPEG compressor subsystem 44 receives an input which consists of sets of 8 by 8 pixel blocks that are generated by the data flow controller (DFC) 34. The compressor output consists of JPEG encoded blocks, including space for JPEG block vectors.

The compressor subsystem 44 is controlled by the composer CPU 36, which sets input streams for each JPEG strip and which records the output address for each strip to fill in JPEG block vectors later.

The (DFC) 34 controls a large portion of the information exchange between modules in the HWC. The data flow controller 34 is at the core of the composer hardware, staging the actual data traffic between components. The DFC is comprised of three main subsystems: Paint 40, CompPrep 41, and SendOff 42. These subsystems operate in parallel as follows: SPaint and the pair (CompPrep, SendOff) operate by pipelining successive bands using the SDram 38 as pipe storage; and CompPrep and SendOff pipeline strips within a band using the BSram 39 as pipe storage.

The paint subsystem 40 paints in all the labels that need to be applied onto a band. Labels are received from the expander subsystem 43 as a CMYK video stream. The CompPrep subsystem 41 prepares a band that has previously been painted by the paint subsystem for compression. For each band, the CompPrep subsystem separates the pixels to be compressed by SDSO and those to be compressed by JPEG, basing its decision on a pixel type map precomputed by the main system.

For each strip within a band, the CompPrep subsystem 41 prepares and stores five streams in BSRAM 39: JPEG expanded strips, one for each color plane, containing the blocks to be JPEG compressed; and The SDSO non-differential representation of the rest of the strip, i.e. a CMYK SDSO stream containing no DIFF* commands.

The SendOff subsystem 42 directs the output of each one of the five streams already prepared by the CompPrep module. The SendOff subsystem operates on strips that have been previously prepared.

The composer CPU 36 implements the top level of the HWC. It controls all of the different modules in the HWC, communicates with the main system via a messaging interface, and serves as an intermediate data storage for streams that are sent to other modules in the HWC.

The composer CPU also executes various software functions for the composition process, which include finishing the JPEG output streams by inserting the JPEG block vectors and partitioning the compose commands into band based Scommands.

Fig. 11 is a block schematic diagram showing information flow and structure according to the invention. Information flows mostly in the form of streams.

Input streams carry the label representation to be applied on each band. The input streams comprise a preprocessed, color separated encoded stream 120 consisting of an SDSO stream and a JPEG stream. Thus, there are a total of eight streams, i.e. SDSO for C, M, Y, and K planes and JPEG for C, M, Y, and K planes. For each band, labels are applied in composition order. Label sources are stored in system memory and are accessed via the system PCI bridge 32.

The video stream 48 carries the expanded label. The video stream is a CMYK pixel stream in which pixels are organized as a pixel array in row major order. The pixel array overlaps the band, possibly starting at an earlier scan line. When the stream starts above the band, the DFC paint subsystem 40 clips the pixels as needed. Routing of the video stream is generated by the expander modules 43.

Flow of the video streams is controlled by the paint subsystem The paint stream 110 comprises actual label pixels to be applied on a band, 'where all extra pixels have been discarded by the DFC paint subsystem The paint stream is a sequence of color applications color value, address) to be written into the current band in the SDram module 38. The DFC SDram output module (55; Fig. 5) controls writing of the paint stream to the SDram module from the paint subsystem. Transparent color is not painted. Rather, a skip in the SDram address is generated.

The band stream 112 is generated once per band and contains the final expanded pixel array for the band. The band stream comprises a pixel array arranged in row major order. The DFC SDram input module (53; Fig. 5) controls reading of the band stream from the SDram module to the CompPrep subsystem.

For each JPEG stream (in each color plane), the expanded strips stream 104 contains the expanded (8 by 8) blocks to be compressed by the Comp modules 44. Only the non-empty blocks are generated. The CompPrep subsystem 41 generates the expanded strips stream on a strip by strip basis.

The stream is stored in the BSRAM.

The pixel type map (118, 122) defines the pixel characteristics of the resulting page. The map is encoded differentially. Map lines are 32 bit word aligned and made up commands that are nibble encoded. Encoding is intended to make hardware simple, rather than achieving the ultimate compression rate.

The pixel type map is created by the main system in advance of the actual page composition. The composer CPU 36 receives the pixel type map before a band needs to be processed by the CompPrep subsystem 41., and then stores the pixel type map in a corresponding BSram module 39 region in advance of DFC 34 access to it.

The JPEG map (118, 122) defines which JPEG blocks are non-empty in the resulting page. The JPEG map is created by the main system in advance of the actual page composition. The composer CPU 36 receives the JPEG map before a band needs to be processed by the CompPrep module 41 and stores it in the corresponding BSram module 39 region.

The strip store and fetch streams 114, 116 are storage operations for the JPEG and SDSO strips produced by the CompPrep subsystem and consumed by the SendOff subsystem 42. Their organization is only relevant as part as the general handling and allocation of the BSram module and is discussed below in connection with the DFC BSram description.

The compose commands stream (118, 122) defines the application order, position (and other parameters) of labels onto the page.

Compose commands defining the whole page composition are created by the main system. The composer CPU 36 receives the compose commands at the beginning of a page and partitions them into band congruent commands. These new band commands are then stored in band dispatch order in the command region of the BSram module for use by the paint subsystem.

Paint Subsystem Fig. 12 is a block schematic diagram of a paint subsystem according to the invention. The paint subsystem implements the label application process to the current band. It effectively transforms the video stream 48 (Fig. 11) into the paint stream (110).

The PaintTop module 59 controls the rest of the paint subsystem. Its main functions include command processing, which receives and interprets compose commands; state information setting, which sets information according to commands; and controlling the collector and applicator modules 58.

The video stream from the expander subsystem is staged into the SDram output via the video stage 54. The video stage module provides any necessary FIFO buffering. The size of this buffering depends on how the SDram module is organized. If the SDram module is organized as two separate 32 bit wide banks, then only a staging register is required. On the other hand, a double width (64 bit) single bank SDram module requires a large FIFO to allow for sharing with the CompPrep module.

The applicator module 58 steps the SDram module writing of the applied colors.

The input colors are checked for transparency. When a pixel's color equals Transparent Color, then the pixel is not applied its corresponding address is skipped). This assumes that the SDram out module 55 is able to skip writes when a transparent pixel is applied. The condition pixelslnBounds is kept by means of two control registers, i.e. leftSkipCnt and writeCnt, as shown by the pseudo code listing below: always (posedge clock) begin if (ineSync) begin IInitialize at horizontal sync leftSkipCnt leftMargin; write~nt lineWidth; pixelisInBounds leftMargin lineWidib I= 0; end else if (VideoStageAdv) begin if (leftSkipCnt 0) begin J/ Advance left margin leftSkipCnt leftSkipCnt 1; pixellsinBounds false; end else if (write~nt 0) begin Advance inside of line writeCnt write~nt 1; pixeilslnBounds true; ens else pixeilslnBounds false; end end The basic flow control is based on the availability of data at the output of the video stage module, and the SlDramn module being ready to take in an application, as shown by the pseudo-code listing below: if (VideoStageRdy) begin if (colorlsTransparent) begin ncrease SkipCount; VideoStageAdv true if pixel Isl nBounds) begin VideoStageAdv true; ResetSkipCount; end else if (SDramOutAdv) begin SendColorAndSkipToSD ram; ResetSkipCount; end else VideoStageAdv false; end Fig. 13 is a block schematic diagram of a ComPrep subsystem according to the invention. With regard to data distribution, the band is read from the corresponding SDram bank 63. Pixels come in as a stream. At the end of every scan line, the last few pixels may be skipped if needed when the scan line is allocated a larger buffer than its width). The pixel stream is used in full by the SDSOGen module 68. Each one of the pixel planes is routed as input into the corresponding JPCOL module 69.

The band controller module 62 keeps track of where in the band various activities are happening. The band controller module generates the necessary end of line signals.

The SDSOGen module 68 generates SDSO based on the current pixel type (provided by the PixelType module 71) and the current pixel color (from the SDram input stream). The SDSOGen module first considers the current pixel. If the current pixel is SDSOTransparent, then the pixel's color is set to BackgroundColor.

SDSO runs start by issuing a CSET command. The run lengths keep increasing while the color remains the same. When color changes, or a JPEG pixel appears, the length is issued by means of an RL command. Similarly for JPEG runs, the runs start by issuing a YSET command. After that, the length keeps increasing until the pixel type changes. The end of line condition generated by the band controller 62 forces the generation of an EOL command.

The JPEG block collector (JPCOL) modules 69 are one-row stages for the collected 8-bit colors. Collection occurs any time JPEGDoColl is active. The band controller 62 generates the endOfJPEGBlock signal necessary to pass on the collected rows to the SRAM Out module 66.

The PixelType module 71 decodes the current pixel type run and advances synchronously with the rest of the subsystem. When the current run is exhausted, the next run is brought in from the BSram pixel map region through the corresponding FIFO.

The JPEGDoColl module 70 decodes the current JPEG Vector and advances synchronously with the rest of the CompPrep subsystem. When the current run is exhausted, the next run is brought in from the BSram pixel map region through the corresponding FIFO.

Fig. 14 is a block schematic diagram of the SendOff subsystem 42 according to the invention. The SendOff subsystem 42 is essentially an intelligent processor for the PCI read requests. It interprets the addresses and fetches the right information from the BSram module.

The SendOff controller module 73 synchronizes band advances and maintains the producer/consumer synchronization with the CompPrep module.

Address Generation for SendOff and direct read is accomplished as follows: The PCI read address selects the region to read. This selection activates the corresponding address generator 77, 78, 79. The DFC module implements PCI slave mode only. All transfers to and from the DFC module are mastered by other components.

There are three read modes: S Read SDSO Region: This reads the next SDSO sequence available.

Read JPCOL Regions M, Y, This reads the next color sequence available.

Direct: This is a direct mapping of the whole BSRam, and allows to access any of its contents.

Notice that in all cases the address mapped must be at least as large as the whole region to allow for DMA in the master component to increase their address and stay within the region. The read accesses are buffered to allow for a slower PCI clock.

The only write access mode available is direct. Access is unbuffered, directly into the BSram module. Clients may only access the BSram module to store very small amounts of information maps and compose commands).

Fig. 15 is a block schematic representation of a partition scheme showing SRAM control according to the invention. A first column 80 identifies the various regions of the SRAM, a second column 81 identifies the actual memory allocation for such regions, and a third column 82 identifies the characteristic of the region.

I I The SDram module is divided into two banks, assigned in a ping-pong fashion to the Band-in-Paint and to the Band-in-Compress, respectively, which simplifies intemrnal data paths and increases pin out. For 8K pixel scan lines, and 256 scan lines per band, each band requires 2M words, or two banks of 2M by 32 bits each.

For read access, a read stream is created to read the Band-in-Compress. For write access, the paint subsystem submits writes to the SDram module, in sequential (with skipping) order. Priority scheduling is not an issue if two banks are used. Otherwise, the read and write accesses should be buffered and scheduled round robin.

Although the invention is described herein with reference to the preferred embodiment, one skilled in the art will readily appreciate that other applications may be substituted for those set forth herein without departing from the spirit and scope of the present invention. Accordingly, the invention should only be limited by the Claims included below.

Claims (16)

1. Apparatus for variable data printing, the apparatus including: a multitude of hardware composers operating in parallel, dividing variable data pages into bands, each band assigned to a corresponding one of the hardware composers, wherein a partial composition task is submitted simultaneously to the hardware composers for implementing a label composition scheme; and wherein each hardware composer includes: means for composing the variable data pages by merging pregenerated labels divided into the bands; means for composing a variable data job from the variable data pages; and means for outputting a resulting page.

2. The apparatus of claim 1, wherein each hardware composer receives, via a system bus: a series of compose commands that define a page to be created as a sequence of label applications; preprocessed labels; and pregenerated information about a resulting page.

3. The apparatus of claim 2, wherein the pregenerated information includes a pixel type map.

4. The apparatus of claim 1, wherein each hardware composer is an autonomous unit that includes an internal local bus and that communicates with an image processing system via a bridge.

5. The apparatus of claim 4, wherein the bridge includes a system bridge by which communication and synchronization is established with image processing system. W:marie\GABNODEL'Div-of-57893-9g.doc -u

6. The apparatus of claim 4, wherein the bridge includes a shipOut PCI bridge that is dedicated to the transport of resulting pages to a printer queue.

7. The apparatus of claim 1, wherein each hardware composer further includes a data flow controller for controlling a portion of the information exchange between modules in the hardware composer.

8. The apparatus of claim 7, further including: a first memory; a second memory; and wherein the data flow controller further includes: a paint subsystem for painting the labels that need to be applied to a band and for storing the labels in the first memory as a paint stream; a CompPrep subsystem for preparing each strip within a band stream that has previously been painted by the paint subsystem and for storing a strip stream in the second memory; and a SendOff system for directing the output of each strip stream prepared by the CompPrep subsystem, the SendOff subsystem operating on strips that have been previously prepared.

9. The apparatus of claim 8, wherein: the paint subsystem operates by pipelining successive bands using the first memory as pipe storage; and wherein the CompPrep subsystem and the SendOff subsystem pipeline strips within a band using the second memory as pipe storage. The apparatus of claim 8, wherein the paint stream includes actual label pixels to be applied to a band; wherein the paint stream is a sequence of color applications to be written into a current band in the first memory; and wherein transparent color is not painted.

W:'madre\GABNODEL'DIv-of-57893-9g.doc

11. The apparatus of claim 8, wherein the band stream is generated once per band and contains a final expanded pixel array for each band, and includes a pixel array arranged in row major order.

12. The apparatus of claim 8, wherein the SendOff subsystem produces an output stream that contains a representation for a resulting band in which all transparent pixels are replaced by a background color.

13. The apparatus of claim 8, wherein a pixel type map is created by the image processing system in advance of actual page composition, the apparatus further including a composer CPU for receiving the pixel type map before a band needs to be processed by the CompPrep subsystem, and for storing the pixel type map in a corresponding region of the second memory in advance of data flow controller access to the pixel type map.

14. The apparatus of claim 13, wherein the composer CPU provides a compose commands stream that defines application order, position, and other parameters of labels onto a page; wherein the composer CPU receives compose commands at the beginning of a page and partitions them into band congruent commands; and wherein the new band commands are then stored in band dispatch order in a command region of the second memory for use by the paint subsystem.

15. The apparatus of any one of the preceding claims, wherein the labels are grid aligned and applied arbitrarily to the data pages.

16. The apparatus of claim 1 substantially as herein described with reference to the accompanying drawings. DATED: 15 May, 2003 PHILLIPS ORMONDE FITZPATRICK Attorneys for: ELECTRONICS FOR IMAGING, INC. WA,1ahle\GABNODELDivof-57893-9gdoc