The teachings provided herein are directed generally to network printer job control, to interpreting jobs written in one of a plurality of page description languages for printing with a printing apparatus, and more particularly to a method directed at resolving different print drivers and print job headers in a centralized print job environment.
Personal computers have become commonplace on the desks of most office workers. Typically, much of the work product of such computers is intended to be transformed into hardcopy via a printer using digital imaging technology. A typical printer configuration for this purpose comprises a dedicated printer coupled to a personal computer.
However, printers used for this purpose are typically small laser printers which have limited functions and features such as a limited tray capacity which restricts the number and types of copy sheets that can be used to make prints on, or which do not have a finishing capability, etc. Small printers also typically do not following the PostScript™ Printer Control Language standards, employing some proprietary page description language instead, typically handling only some subset of a full page description language.
Larger high speed laser printers normally have a great deal of finishing and copy sheet capability which would allow the personal computer user to have, for example, custom printing and finishing of the work product, an option which for many personal computer users would be highly desirable.
In practice, the personal computers can be used advantageously with a network printing system of the type combining a number of client inputs, such as the personal computers, or the like, and one or more printer outputs. In one example of such network printing systems, a client at one of the inputs sends electronic documents that comprise a job over a local area network (local area network) to one of the printers selected for printing of the job.
In particular, local area networks provide users running dedicated processors the ability to share resources such as printers, file servers, and scanners. Integration of shared resources has been a problem addressed by local area network managers. Local area network managers have made different network protocols transparent to devices running different network protocols. Local area networks also have a variety of print drivers emitting different page description languages, which are directed to specific printer devices.
A page description language is a method of describing printed page(s) in a printer independent format. No standard page description language presently exists, and as a result a number of industry standards have emerged. A page description language establishes an interface between a print driver or client and a print server or printer. Existing page description languages include PostScript™, Hewlett-Packard™ Printer Control Language, and Interpress™ Page Description Language.
Many printing manufacturers provide differing print drivers, which place device dependent information into the page description language print streams as handled by centralized print systems. When it is desirable to redirect this page description language stream to a different printer, this can result in scenarios ranging from outright print job failure, to corrupted print jobs, to undesirable required involvement from an operator in order to direct a print job to completion.
It would therefore be desirable for such a system if there was a homogenous page description language that could be shared among many devices. There are many examples of systems that would be improved by device independent page description languages—such as load balancing systems and print control systems. This need has been solved in the past by generic printer drivers, which place page description language elements that are commonly shared among most devices into their streams.
However, generic printer driver solutions require costly administrative overhead and require the replacement and use of only the customized queues. The generic printer driver solutions may also limit users to a small sub-set of functionality and disable native driver features.
Other output management systems do not attempt to solve the problem regarding device independent page description language streams. The output management systems instead require that an administrator group the hardware devices into compatible or similar families of devices. If any devices cannot be made part of the group, those devices cannot be used by the technology. Examples of such systems include roaming printing or device error detection systems.
Requiring such grouping of hardware is difficult and expensive, particularly for organizations that already have a substantial hardware investment. It may also mean underutilization of devices in the output management systems or necessitate unnecessary purchases of new equipment.
Therefore, it would be desirable to utilize a homogenous page description language that could be shared among many devices.
The drawings are only for purposes of illustrating various embodiments and are not to be construed as limiting, wherein:
For a general understanding, reference is made to the drawings. In the drawings, like references have been used throughout to designate identical or equivalent elements. It is also noted that the drawings may not have been drawn to scale and that certain regions may have been purposely drawn disproportionately so that the features and concepts could be properly illustrated.
As described below in more detail, an automatic device-independent adaptation of page description language data streams methodology automatically adapts page description language streams into compliance for a majority of printing devices. No changes to the existing printer driver queues are necessary—device dependent printer drivers are left intact on the system. Page description language data streams are captured before the page description language data streams are sent to a print device and adapted programmatically to ensure conformance across many devices.
One source of the incompatibilities between device controllers is page description language headers. As described below in more detail, the automatic device-independent adaptation of page description language data streams methodology mitigates the page description language header differences and sends a pure page description language stream to a print device wherein the header of the page description language stream has been removed and the page description language stream has been altered to provide device independence.
The system and methodology described below enable a network with a plurality of independent computers, with differing print drivers having generated various otherwise potentially incompatible page description language print jobs, to successfully interface with a centralized printer system through a plurality of lines by virtue of on-the-fly adaptation of the page description language stream job headers, prior to the jobs being received by a subsequently designated print device.
The header is first consumed and parsed to mitigate print-stream header differences by transforming the header commands into page description language commands and imbedding the page description language commands in the original page description language data, and therefrom sending a resulting pure page description language stream.
The resulting pure page description language stream is necessarily a modification of the original page description language data designed to produce a result compliant with the request as manifest in the originating header. If the header commands cannot be honored, different mitigating courses of action may be taken such as notification of the user, or the non-compliance may simply be ignored and an as best-can-do job printed anyway.
Referring to
Referring to
As will be clarified from the discussion below, the page description language of print document 63 may be either written in Postscript™ or Hewlett-Packard™ Printer Control Language or other image data language.
The print document 63 are electronic in form, consisting of image signals or pixels generated, for example, by scanning hard copy documents and converting the document images to image signals or pixels, directly by a keyboard, taken from memory, or consisting of page format and/or graphic output commands all encoded in one of the page description language encodings.
The content of the job files may be compressed to increase bandwidth and reduce the amount of storage required. The image signals, pixels, or page description language instructions in print document 63 are arranged as electronic documents or pages for printing on a print media such as paper stock or sheets.
The server 25 of
The printing system 35 of
In
Referring to
The host processor 72 is capable of transferring data to and from the accelerator coprocessor card 74 through a sliding shared memory window. The accelerator coprocessor card 74 also can use a small section of the host processor's input/output address space. By writing to an input/output data port of the accelerator coprocessor card 74, the host processor 72 is able to send commands to the accelerator coprocessor card 74.
In turn, by reading the input/output data port, the host processor 72 is able to receive acknowledgement messages back from the accelerator coprocessor card 74. These messages are typically used to synchronize the actual data transfers in shared memory. For example, the data ports may be used to communicate synchronizing swap requests and acknowledgements between the accelerator coprocessor card 74 and the host processor 72 prior to the actual transfer of page description language decomposer code and font cache data.
Referring still to
Referring now to
As illustrated in
The page description language interpretation code facilitates translation of the job page description language file 60 from a first page description language, such as Interpress™, PostScript™, or Hewlett-Packard™ Printer Control Language; into a second page description language file, which is provided without a header, the header commands having been embedded within each page.
It should be appreciated that only selected portions of the system section 84 are shown. Much of the software for the section 84 simply serves as one of various approaches for implementing the processes illustrated in
It will be recognized by those skilled in the art that, in practice, various software tools, such as tables, e.g., fault, system procedure and control tables, timers and controls therefore, control implementations, storage locations, stacks and debuggers would typically be employed in to implement the system section 84.
Referring to
Referring specifically to
Upon processing a job page description language file 60, the interpreted page description language file can be transmitted to one of a plurality of output or printing devices.
For example, the interpreted page description language file may be expressed in Interpress™, and is transmitted to the printer 50 which may include a decomposer and an image output terminal.
In operating the printer 50, the interpreted output from the host processor 72 is transmitted to the decomposer where it is decomposed into graphics and text for printing by the printer 50.
Many printing manufacturers provide differing print drivers that get widely installed on various workstations 14, and which thus place device dependent corrupted print jobs into the page description language print streams when print jobs are sent on into centralized print systems. The large number of, and changing updated nature of, these device dependent print drivers makes administration difficult.
The automatic device-independent adaptation of page description language data streams methodology parses the page description language header, and implements high-level pseudo-code logic for each unique line or high-level identifiable token (hereinafter called an element) in the header. The most common header type syntaxes are understood and adapted into the most common page description language-specific language syntaxes.
With respect to the discussion below, the page description language-specific language portion of a page description language is referred to as the page description language body.
At step 500, the print page description language job 60 is parsed to delineate the page description language header and each element in the header, from the page description language body image data which originated from the print document 63. Each page description language header comment is examined to determine if the page description language header may be handled in page description language specific language, at step 510.
If the determination is made that the page description language header can be handled in page description language specific language, the header element is changed into a page description language-specific language and is imbedded into the page description language stream, at step 520.
At step 540, the original header element is stripped or redacted from the page description language stream. This parse and replace routine is repeated until every header element has been examined and either transformed/adapted, or it is determined that the element cannot be transformed/adapted into a suitable page description language command.
The resultant new page description language data print job data stream is then directed to the most suitable of one or more available print devices. At step 530 those scenarios, which a given page description language header element cannot be adapted, are identified.
There are a number of times when a header element cannot be adapted and thus cannot be embedded in the transformed page description language stream. For example, many print streams contain customized extensions in their page description language headers, and certain other headers are interpretable only by particular device controllers.
In such situations, a number of different solution scenarios may be taken. Depending on the print system and the available print devices, the print job may be passed on and directed to a particular print device which can handle those header elements that could not be adapted or translated.
In the alternative, however, the print job can be refused, and notification provided to the originating user that the job cannot be printed as submitted.
In yet another alternative, the job could be passed on and printed, on a best can-do basis.
Further, in all the above scenarios notification may be provided to the originating user providing the user with the option of selecting what result or redirection is to be performed.
The automatic device-independent adaptation of page description language data streams methodology adapts particular header elements into the page description language body depending on the nature of the header element the automatic device-independent adaptation of page description language data streams methodology encounters. Some elements can be more easily adapted than others into the page description language body. One example of a more easily adapted element is a copy count element, the pseudo code for which is depicted in Table 1 that follows:
The copy count parameter specified in the header simply can be placed into the page description language body with the appropriate new syntax when the resident page description language-specific language supports such a document-wide copy count setting.
Depending on the page description language-specific language used, some settings may be imbedded at various locations within the page description language body. For instance, for copy count information expressed in the header (where the document is not collated) and when the page description language-specific language does not support a document-wide copy count setting, see Table 2.
In this case, the header element must be expressed throughout the page description language body. In that situation, the automatic device-independent adaptation of page description language data streams methodology algorithms may obtain a copy count setting from the header element and then for each page in the document, place that copy count setting on each individual page.
A different approach may be utilized when the document is to be collated. In that situation, the algorithms may obtain a copy count and repeat the entire document image data stream for each of the required number of copies in excess of one. See Table 3.
Although this last example results in an increase in the size of the page description language stream, it is worth noting that this type of logic is employed in such a way as to make it effective for all applications and drivers, since the stream is adapted after the application and printer driver have generated the page description language. Thus, this type of adaptation has been deemed as an acceptable concept applied to page description language streams and headers which are potentially not compliant with various other print devices.
It will be apparent to one skilled in the art that this same concept of moving various page description language header elements into the page description language body may be applied to many other types of header element commands. The most commonly used settings found in print jobs that may be specified in page description language headers will be handled. Examples of such include, but are not limited to: simplex/duplex, media size, orientation, etc.
It is recognized that not all header elements can be handled in the page description language-specific language command syntax. However, many of the most common and important header elements used in a typical print job nevertheless can be expressed, either in the page description language-specific language, or as an expression of a more advanced finishing option which is not essential to successful printing. For cases where an advanced finishing option is requested, the system employing the automatic device-independent adaptation of page description language data streams methodology may notify the user if desired, as discussed above, and allow the user to make a determination of the desirability of this advanced finishing option when it is not available.
The automatic device-independent adaptation of page description language data streams methodology described above handles page description language compliance by adapting the page description language stream just before it goes to the device. Other approaches deal with page description language compliance at the source (where the page description language is generated) or at the destination (the devices) rather than in-stream on the server.
The above-described automatic device-independent adaptation of page description language data streams approach allows output management systems to more optimally direct a given job to the most appropriate print device thereby maximizing throughput. By modifying the page description language stream on-the-fly, the mapping of various sources to various destinations is enabled and thus does not force a sole source or small destination group of print devices.
The automatic device-independent adaptation of page description language data streams methodology described above also does not interfere with existing printing infrastructure, and the automatic device-independent adaptation of page description language data streams methodology described above does not need to be reinstalled when infrastructure changes do occur.
In summary, a method enables device independent adaptation of print jobs by receiving a print job having a print job header and page description language, parsing the received print job to delineate the print job header commands and the page description language commands for headers which contain custom operations instead of page description language standard operations. The print job header commands are transformed into suitable page description language commands and then redacted from the print job to leave as remaining the page description language. The transformed suitable page description language commands are imbedded into the remaining page description language data of the redacted print job to create a resultant page description language only print job. That resultant page description language only print job is sent job to a print system.
Moreover, a method enables device independent adaptation of print jobs by receiving a print job having a print job header and page description language, parsing the received print job to delineate the print job header elements and the page description language commands. Each print job header element is examined to determine its adaptability for transformation into page description language and those determined as adaptable are transformed into suitable page description language commands. The print job header elements determined as adaptable are redacted from the print job. The transformed suitable page description language commands are imbedded into the remaining page description language data of the redacted print job to create a resultant new page description language data which is directed to the selected alternate printer. In an another arrangement the resultant new page description language data is directed to the most suitable of one or more available print devices as based upon the relative success in transforming the print job header elements.
In addition, a system for device independent adaptation of print jobs in a page description language includes a print job server for an at least one network connected print device, which intercepts any print jobs directed at the at least one network connected print device. Located on the print job server is a print job header parsing application, which when a print job is intercepted will parse and remove the print job header from the page description language; transform print job header commands into page description language commands; imbed those page description language commands in the original page description language data; and there-from send on a resulting page description language stream.
It will be appreciated that various of the above-disclosed and other features and functions, or alternatives thereof, may be desirably combined into many other different systems or applications. Also that various presently unforeseen or unanticipated alternatives, modifications, variations or improvements therein may be subsequently made by those skilled in the art which are also intended to be encompassed by the following claims.