Abstract:
A method and system for automatically generating page exception programming based on user-defined rules is disclosed. A page specific metadata in a PDL file can be evaluated against specific rules to automatically create page exception programming. An embedded PDL device control instructions can also be evaluated and converted into page exception programming thereby producing an integrating representation of all page exception programming for a print job. The PDL page extracted as an exception page can then be displayed on a graphical user interface which provides an operator to confirm pages for editing.

Description:
TECHNICAL FIELD 
     Embodiments are generally related to data-processing methods and systems. Embodiments are also related to rendering devices and document management systems. Embodiments are additionally related to methods and systems for automatically generating page exception programming utilizing metadata. 
     BACKGROUND OF THE INVENTION 
     Reproduction machines such as copiers and printers have become more complex and versatile with respect to the jobs they perform. The user interface between the machine and the operator or user, which in essence permits the dialogue between the operator and the machine, must necessarily be expanded if full and efficient utilization of the machine is to be realized. A suitable interface must not only provide the controls, displays, and messages necessary to activate, program, monitor, and maintain the machine, but must be able to accurately and efficiently program machine instructions for a complex reproduction run. Such reproduction runs generally include a set of documents with most of the documents requiring common features. However, often several documents of the set require special features or exceptions to the common features of most of the documents of the set. This requires operator attention and selection to program the exceptions for each such document requiring an exception. 
     Exception page programming is a process for expressing and recording the instructions for deviating from the baseline or common job programming for the print job. Typically, exception page programming is accomplished by a user reviewing the job pages and indicating the exception programming for specified pages. This process is labor intensive and prone to error because there is difficulty in unambiguously specifying the pages when page numbers shift as a result of insert sheets, chapter starts or simplex/duplex changes. 
     One prior art approach that offers a primitive implementation of automated exception page programming for host based composition systems involves the use of each section of a document as a separate PDF file with recognizable file name suffixes for inserts. These files are concatenated under control of a script that performs special actions when a file with an “insert” file name suffix is encountered. This approach results in the coupling of the document creation process to the automated exception page programming, which is undesirable because it is not flexible. 
     A difficulty with such prior art systems is that often the same exceptions apply to several documents. It is then necessary for the operator to painstakingly select the exceptions (i.e., there may be several such as chapter start, special paper or insert, copy quality or image shift) for each document, repeating the same exceptions until the process has been completed for each document. Each time the operator is called upon to make a selection, the possibility of an error in the selection process is increased. Errors in selection can result not only in an inaccurate work product which will need to be at least partially redone, but also can result in conflicting exceptions or requirements which may render the job impossible to initiate. The selections must then be reviewed and rechecked to uncover the source of conflict. This can be a very time consuming and inefficient process. 
     Based on the foregoing it is believed that a need exists for an improved system and method for automatically generating page exception programming based on user defined rules utilizing metadata. 
     BRIEF SUMMARY 
     The following summary is provided to facilitate an understanding of some of the innovative features unique to the embodiments disclosed and is not intended to be a full description. A full appreciation of the various aspects of the embodiments can be gained by taking the entire specification, claims, drawings, and abstract as a whole. 
     It is, therefore, one aspect of the present invention to provide for an improved data-processing method and system. 
     It is another aspect of the present invention to provide for improved document management methods and systems. 
     It is a further aspect of the present invention to provide for an improved method and system for automatically generating page exception programming utilizing metadata. 
     The aforementioned aspects and other objectives and advantages can now be achieved as described herein. A method and system for automatically generating page exception programming based on user-defined rules is disclosed. Page specific metadata in a PDL (Page Description Language) file can be evaluated against specific page exception rules to automatically create page exception programming. Embedded PDL device control instructions can also be evaluated and converted into page exception programming, thereby producing an integrated representation of all page exception programming for a print job. The PDL page extracted as an exception page can then be displayed on a GUI (Graphical User Interface) that permits an operator to confirm pages for editing. 
     In accordance with one embodiment, an input window for exception page programming can be provided. One or more page exception rules can be generated for recognizing exception programming triggers and associated programming. The metadata associated with the pages and the page content can thereafter be extracted. Next, the page exception rules can be applied to the information obtained from the metadata and the page content. The page exception programming can be automatically generated based on the page exception rules. 
     The page exception rules can be associated with a specific input method so that the system can receive jobs, and inspect and evaluate such jobs against the defined page exception rules in order generate page exception programming that can be utilized by an associated RIP (Raster Image Processor) and rendering device. The auto generated page exception programming can be combined with any embedded PDL device control instructions. The integrated list of exception page programming is preferably utilized when reviewing the job programming or any displays that include job programming effects. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
       The accompanying figures, in which like reference numerals refer to identical or functionally-similar elements throughout the separate views and which are incorporated in and form a part of the specification, further illustrate the embodiments and, together with the detailed description, serve to explain the embodiments disclosed herein. 
         FIG. 1  illustrates a block diagram of a data-processing apparatus, which can be utilized for page exception programming, in accordance with a preferred embodiment; 
         FIG. 2  illustrates a block diagram of a system for page exception programming, which can be implemented in accordance with a preferred embodiment; 
         FIG. 3  illustrates a high level flow chart of operations illustrating logical operational steps of a method for page exception programming utilizing metadata, in accordance with a preferred embodiment; and 
         FIG. 4  illustrates a high level flow chart of operations illustrating logical operational steps of a method for page exception programming rules, in accordance with a preferred embodiment. 
     
    
    
     DETAILED DESCRIPTION 
     The particular values and configurations discussed in these non-limiting examples can be varied and are cited merely to illustrate at least one embodiment and are not intended to limit the scope thereof. 
     The embodiments described herein can be implemented in the context of a host operating system and one or more modules. Such modules may constitute hardware modules, such as, for example, electronic components of a computer system. Such modules may also constitute software modules. In the computer programming arts, a software “module” can be typically implemented as a collection of routines and data structures that performs particular tasks or implements a particular abstract data type. 
     Software modules generally can include instruction media storable within a memory location of an image processing apparatus and are typically composed of two parts. First, a software module may list the constants, data types, variable, routines and the like that can be accessed by other modules or routines. Second, a software module can be configured as an implementation, which can be private (i.e., accessible perhaps only to the module), and that contains the source code that actually implements the routines or subroutines upon which the module is based. The term “module” as utilized herein can therefore generally refer to software modules or implementations thereof. Such modules can be utilized separately or together to form a program product that can be implemented through signal-bearing media, including transmission media and/or recordable media. An example of such a module is module  111  depicted in  FIG. 1 . 
     It is important to note that, although the embodiments are described in the context of a fully functional image processing system (e.g., a computer system), those skilled in the art will appreciate that the mechanisms of the embodiments are capable of being distributed as a program product in a variety of forms, and that the present invention applies equally regardless of the particular type of signal-bearing media utilized to actually carry out the distribution. Examples of signal bearing media include, but are not limited to, recordable-type media such as media storage or CD ROMs and transmission-type media such as analogue or digital communications links. The logical operation steps depicted in  FIGS. 3-4  can, for example, be implemented in the context of such a software module. 
     Referring to the drawings and in particular to  FIG. 1 , there is depicted a data-processing apparatus  100  which can be utilized for automatically programming page exception in accordance with a preferred embodiment. Page exception programming refers to alternate processing applied to a subset of the pages in a PDL. This can be achieved via several mechanisms including the modification of job programming or making changes to the Page Description Language file content that will affect the rendered output. Data-processing apparatus  100  represents one of many possible data-processing and/or computing devices, which can be utilized in accordance with the disclosed embodiments. It can be appreciated that data-processing apparatus  100  and its components are presented for generally illustrative purposes only and do not constitute limiting features of the disclosed embodiments. 
     As depicted in  FIG. 1 , a memory  105 , a processor (CPU)  110 , a Read-Only memory (ROM)  115 , and a Random-Access Memory (RAM)  120  are generally connected to a system bus  125  of data-processing apparatus  100 . Memory  105  can be implemented as a ROM, RAM, a combination thereof, or simply a general memory unit. Module  111  can be stored within memory  105  and then retrieved and processed via processor  110  to perform a particular task. A user input device  140 , such as a keyboard, mouse, or another pointing device, can be connected to PCI (Peripheral Component Interconnect) bus  145 . 
     Data-process apparatus  100  thus includes CPU  110 , ROM  115 , RAM  120 , and a rendering device  190  (e.g., printer, copier, scanner, etc.), which are also coupled to a PCI (Peripheral Component Interconnect) local bus  145  of data-processing apparatus  100  through PCI host-bridge  135 . The PCI Host Bridge  135  can provide a low latency path through which processor  110  may directly access PCI devices mapped anywhere within bus memory and/or input/output (I/O) address spaces. PCI Host Bridge  135  also can provide a high bandwidth path for allowing PCI devices to directly access RAM  120 . 
     A communications adapter  155 , a small computer system interface (SCSI)  150 , a raster image processor (RIP)  180 , and an expansion bus-bridge  170  are also attached to PCI local bus  145 . The communications adapter  155  can be utilized for connecting data-processing apparatus  100  to a network  165 . SCSI  150  can be utilized to control high-speed SCSI disk drive  160 . An expansion bus-bridge  170 , such as a PCI-to-ISA bus bridge, may be utilized for coupling ISA bus  175  to PCI local bus  145 . Note that PCI local bus  145  can further be connected to a monitor  130 , which functions as a display (e.g., a video monitor) for displaying data and information for a user and also for interactively displaying a graphical user interface (GUI)  185 . 
     Note that the term “GUI” generally refers to a type of environment that represents programs, files, options and so forth by means of graphically displayed icons, menus, and dialog boxes on a computer monitor screen. A user can interact with the GUI  185  to select and activate such options by pointing and clicking with a user input device such as, for example, a pointing device such as a mouse, and/or with a keyboard. A particular item can function in the same manner to the user in all applications because the GUI  185  provides standard software routines (e.g., module  111 ) to handle these elements and reports the user&#39;s actions. 
     The user interface  185  allows for the modification of certain characteristics of a printed image, such as, for example, lightness/darkness, contrast, highlights, shadows, and color cast. In this regard, a user actuates the appropriate keys on the user interface  185  to adjust the parameters of a print job. The rendering device  190  may also require the use of DFE (Digital Front End) data, which can be supplied by an RIP (Raster Image Processor)  180 , in order to assemble the complete picture, separate the images into the appropriate colors, and send the information to the rendering device  190 . The print driver (not shown) is accessible to a user via a graphical user interface (GUI)  185 . 
     The graphical user interface  185  provides an interface that enables a user to select and communicate job programming attributes to the data-processing system  100 . Job programming attributes describe selected parameters by which a print job may be processed and may include parameters for page layout (e.g., size, orientation, duplex), color options (e.g., brightness, contrast, saturation), media type, finishing options (e.g., output tray, collate, staple, binding), and the like. In addition to selecting parameters for the print job, the graphical user interface  185  and the print driver may be utilized to set additional or alternate job attributes on a per-page basis for selected pages. These special attributes to be used for selected pages within a job are often referred to as page exceptions. Similarly, the ability to set different attributes on a per-page basis is sometimes referred to as page-exception programming. 
     Referring to  FIG. 2  a block diagram of a system  200  for page exception programming is illustrated, which can be implemented in accordance with a preferred embodiment. The system  200  can be implemented by a module such as module  111  depicted in  FIG. 1  or may utilize one or more such software modules in association with a data-processing apparatus, such as, for example, the data-processing apparatus  100  depicted in  FIG. 1 . Each block such as blocks  210 ,  220  and so forth can represent a module such as module  111  depicted in  FIG. 1  or a process step. System  200  can include, for example, a PDL file as indicated at block  210 . The metadata streams as indicated at block  220  can be extracted from the PDL file. The exception programmer  230  can configure the system prior to sending jobs to the rendering device  190 . The exception programmer  230  can also use a job programming tool on one or more jobs to “teach” the system the rules for recognizing exception programming triggers and the associated programming. 
     The exception programmer  230  can create page exception rules as indicated at block  240  as required in order to leverage various forms of metadata available in the input PDL. These rules can then be saved as a collection that can be associated with a specific input mechanism, e.g. virtual printer, queue, or hot folder. Furthermore, these rule collections can contain disparate evaluation criteria methods that can be applied to the same file. For example, a rule collection can evaluate input files to assign chapter starts based on a specific style sheet, assign inserts based on color space and assign tabs based on whether a specific font style can be utilized in a given page. The exception programmer  230  is preferably implemented with one or more data objects or other programs stored in memory, either primary or secondary, of a document processor  250 . 
     Referring to  FIG. 3  a high level flow chart of operations illustrating logical operational steps of a method  300  for the page exception programming utilizing metadata, in accordance with a preferred embodiment. Note that the method  300  depicted in  FIG. 3  can be implemented in the context of a software module such as, for example, the module  111  of apparatus  100  depicted in  FIG. 1 . The process depicted in  FIG. 3  can be initiated, as indicated at block  310 . Thereafter, as depicted at block  320 , an input window for exception page programming can be configured. As described next at block  330 , the page exception rules can be generated for recognizing exception programming triggers and the associated programming. 
     Metadata associated with the pages and the page content can be extracted, as depicted at block  340 . Metadata is data about data. For example, the title, subject, author, and size of a file constitute metadata about a file. With respect to graphics, the current position, color, and size of a primitive, such as a box, constitute metadata for the box. With respect to a primitive, in computer graphics, a shape, such as a line, circle, curve, or polygon, that can be drawn, stored, and manipulated as a discrete entity by a graphics program. A primitive is one of the elements from which a large graphic design is created. The page exception rules can be applied to the information obtained from the metadata and the page content, as indicated at block  350 . The page exception programming can be automatically generated based on the page exception rules, as illustrated at block  360 . The process can then terminate, as indicated at block  370 . 
     Referring to  FIG. 4 , a high level flow chart of operations illustrating logical operational steps of a method  400  for implementing page exception programming rules is illustrated, in accordance with a preferred embodiment. As indicated at block  410 , PDL metadata can be evaluated to automate page exception programming. The metadata can be data, such as, for example, PDF bookmarks, page dimensions, color spaces, document structure information such as style sheets, etc. The metadata values can be utilized to define the page exception programming selection. For example, the name of a specific PDF Bookmark (e.g. Insert) can be utilized to search and select the proper page exception programming. A user is able to store a set of page exception programming selections under a specific name that can be used for comparison. A specific page property can also be used to define page exception programming e.g. color pages printed to a monochrome printers can be automatically programmed as insert sheets or pages of a given dimension such as 9×11 on an 8.5×11 document can be associated with specific page exception programming. 
     Next, as shown at block  420 , PDL page object attributes can be evaluated. The page attributes can be keywords or patterns that can be used to search for. For example, changes to the chapter name in a header or footer or changes to the page number prefix in hyphenated page numbering styles. Thereafter, embedded job programming can also be evaluated, as depicted at block  430 . Multiple methods can be combined to automate page exception programming as a part of “single rule” collection, as illustrated at block  440 . Thereafter, as depicted at block  450 , media characteristics can be enabled utilizing “document default”. For example, the media selected for page exception programming can be defined as having a media color of “Blue” with all other choices set to “document default”. This rule can be used with a queue so that any pages with a PDF Bookmark with name “Blue” can be printed on media that matched the media selected for the job in every aspect except for the media color. This allows a single page exception rule to be used on jobs with a variety of selected media sizes and weights. 
     The metadata can also be used to control specific page exception selections. For example, the name of a PDF Bookmark (e.g. 5 Blue Insert) can be evaluated in order to determine the page exception programming that can be used. The system can then go to the inserts rule for the specific job. Within the rule, certain media exception parameters can be defined as further evaluations against the PDF bookmark so that if the name of a valid Media Color is found the page defined by the exception programming is printed on that media. Similarly, another media programming rule can look for numbers in the string and use them to define the number of times the associated page can be printed within the collated document. The media parameters can be set to “document default” values if the rules did not find the required data. The page exception programming can also be extended to include print quantity which can cover any and all page exception functionality, as shown at block  460 . 
     The page exception rules can be associated with a specific input method. The system can receive jobs inspect and evaluate the received jobs against the user defined page exception rules and generate page exception programming that can be used by the associated RIP (Raster Image Processor) and print engine. The auto generated page exception programming created can be combined with any embedded PDL device control instructions, e.g. PostScript SetPageDevice instructions and the HP PCL equivalents. The integrated list of exception page programming can be useful when reviewing the job programming or any displays that include job programming effects. 
     It will be appreciated that variations 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.