WO2001018690A2 - Procede et dispositif d'homogeneisation de fichiers d'images graphiques et d'equilibrage de charge d'operations - Google Patents

Procede et dispositif d'homogeneisation de fichiers d'images graphiques et d'equilibrage de charge d'operations Download PDF

Info

Publication number
WO2001018690A2
WO2001018690A2 PCT/US2000/023829 US0023829W WO0118690A2 WO 2001018690 A2 WO2001018690 A2 WO 2001018690A2 US 0023829 W US0023829 W US 0023829W WO 0118690 A2 WO0118690 A2 WO 0118690A2
Authority
WO
WIPO (PCT)
Prior art keywords
file
postscript
eps
farm
job
Prior art date
Application number
PCT/US2000/023829
Other languages
English (en)
Other versions
WO2001018690A3 (fr
Inventor
Timothy A. Laverty
Cory E. Klatt
Brent A. Krum
Original Assignee
Imagex.Com, Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from US09/480,645 external-priority patent/US6903839B1/en
Priority claimed from US09/480,334 external-priority patent/US6633890B1/en
Application filed by Imagex.Com, Inc filed Critical Imagex.Com, Inc
Priority to AU73377/00A priority Critical patent/AU7337700A/en
Publication of WO2001018690A2 publication Critical patent/WO2001018690A2/fr
Publication of WO2001018690A3 publication Critical patent/WO2001018690A3/fr

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5005—Allocation of resources, e.g. of the central processing unit [CPU] to service a request
    • G06F9/5027—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals
    • G06F9/505—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals considering the load

Definitions

  • the present invention relates to a system and file structure for producing fast and consistent visual medium materials.
  • a hosted applications server is used to host Prepress applications.
  • One such Prepress application is a process used to wash graphical files before they are incorporated into a consistent Print Ready File (PRF) structure. Washing is done to ensure that Encapsulated PostScript (EPS) graphics are structured in a consistent format.
  • PRF Print Ready File
  • EPS Encapsulated PostScript
  • the present system provides for the automated creation of a PRF, as described in the incorporated references. Unlike prior art systems, this PRF has been configured to contain all the necessary information for printing a particular job. Once created, the PRF can be sent to many different vendors, over a variety of different mediums, and can be used to produce a consistent print job result each time.
  • the consistent processing of the file is also due, in part, to the treatment of the various jobs coming into the system.
  • jobs were sent to a server (or group of servers) and processed according to a certain priority queue. Often the priority queue proved to be inadequate to properly distribute the jobs among the various servers.
  • a more centralized system for handling many different client tasks is therefore needed, with effective load balancing provided between the various servers.
  • Postscript is a programming language that describes the appearance of a printed page. It was developed by Adobe in 1985 and has become an industry standard for printing and imaging. All major printer manufacturers make printers that contain or can be loaded with Postscript software. Such software also runs on all major operating system platforms.
  • a Postscript file can typically be identified by its ".ps" suffix. Postscript describes the text and graphic elements on a page to a black-and-white or color printer or other output device, such as a slide recorder, imagesetter, or screen display. Postscript handles industry-standard, scalable typefaces in the Type 1 and TrueType formats.
  • PDF files present the document's printed appearance on a display screen. Encapsulation is the inclusion within the file of all the resources needed for the file to be printed (or displayed). Other such centralized tasks might include creation, trapping, color separation, and imposition of Print Ready Files.
  • a set of business logic (or the like) can therefore be applied to a print job, in that the setup associated with such processes can be accomplished at the front-end by the user, when the user specifies the print job.
  • the centralized server can thereafter take all of the setup data and generate a completed print job, or in other words, a complete PRF for use by a print vendor.
  • a PRF is comprised of a combination of graphical, text, and line elements.
  • the graphical elements typically include EPS files.
  • a number of available software tools can be used by a human operator to create, review, and edit EPS files.
  • EPS files that ultimately come out of such software and Graphic Art products such as Illustrator, Quark, Pagemaker, or Photoshop all have certain differences, or eccentricities, which are difficult to account for and process on a consistent basis. Such differences might include the setting of parameters for fonts (i.e. leading, size, kerning), linescreen, angle, transfer functions (and other device specific PostScript operators), scaling of graphics, addition of spot colors, and so forth.
  • Still another resulting practice in creating files involves embedding EPS files within
  • EPS files (and so forth), wherein such files are eventually included in the overall PRF.
  • Such multi-layering of files can produce a tangled series of information, which can prove to be difficult to process when trying to parse color information (and the like) from the EPS file.
  • FIG. 1 a prior art block diagram is shown of certain representative steps 100 which might be used by an human operator (or user) to create an EPS file.
  • step 102 the user creates and/or imports graphical elements into a Graphic Art application.
  • step 104 the user sets various parameters associated with the file, as per the particular interface associated with the Graphic Art application. The parameters might include information such as type, fonts, leading, scaling, and color separation.
  • step 106 the user outputs the EPS file using the Graphic Art program, which is often in a proprietary format.
  • the prior art does not ensure referential integrity or consistent settings for color in such files. Software systems developed by different companies do not typically have a shared data structure for reference by the different applications.
  • the prior art does include Preflight checking and the like.
  • Such Preflight checking analyzes and detects problems in EPS files.
  • Such Preflight checking methods do nothing to fix (or standardize) the EPS file results. Accordingly, a solution is needed which will normalize the information used to produce an EPS file.
  • the EPS file should be "washed.” This will allow the various applications used to process a graphical file that will run in an automated environment wherein the color settings are set as policies, and can be managed, updated, and tested automatically.
  • the policies can be stored in a central database.
  • the washing process removes problems and anomalies, and creates an EPS file that can be commonly shared in known format.
  • the format might include PostScript Level 1 code, with removal of incompatible operators, and a PostScript header that is consistent between various files.
  • the present invention utilizes certain technology, along with an interface medium such as the Internet, to offer a fully automated, efficient and cost-effective solution for producing print jobs and the like.
  • the present invention reduces the number of times that human intervention is required in the process and thereby reduces labor intensity, labor cost, time, and high error rates.
  • color washing of EPS files is performed as one Pre-press operation in order to provide a consistent format for graphical files.
  • the Farm system can be configured to provide load balancing aspects, in association with performing a variety of operations, and in association with processing jobs submitted by clients using the system.
  • Each job is analyzed to provide an estimate of its relative impact on the overall system, based upon exemplary factors such as job size and CPU usage for each server.
  • the Farm system is scalable, and is controlled via a single point of contact called the Master Farmer. As different jobs are queued up by the Master Farmer, different Farm services can be brought online to process these various jobs.
  • Each job is handled by a particular Plot, and each Plot is controlled by a Field, which is specific to that Plot.
  • a Farm service might control several Fields, and the Master Farmer might control several Farm services.
  • Each different Plot is configured to run out-of-process from the Farm main process. This is to prevent crashes associated with one Plot. If a particular Farm service crashes, its jobs can be rerouted to other Farm services. When a client submits a particular job, the size of the job is used to estimate how long it will take to process. This estimate is returned to the client and updated periodically. In general, the Farm system utilizes very little overhead, and each Farm service can be configured to run any of the file processing tasks.
  • the Farm service might host a variety of Prepress applications that are used in association with automatically creating and processing the PRF.
  • the presently described (color) washing operation is one of several Prepress operations that can be automated in this fashion, namely by hosting the application on a server or other networked computer, and maintaining control of its operations as part of a distributed Prepress software operation.
  • Other operations might include, but are not limited to, creation, trapping, color separation, and imposition, all in association with the Print Ready Files.
  • a series of communication links back to a centralized system are necessary. Certain operations are specified to be performed in order to create a PRF, and the present system thereby processes these automatically to create PRF.
  • manual or discrete processes were performed on the file, by design houses, print shops, and the like. The processes were performed and recorded (or stored) back on a network or storage system. Each subsequent operation was then performed on the file by retrieving it, and returning to storage.
  • a system should have application server capability, and messaging capability about each particular application being run. Under such a system, a variety of applications can be run. but the CPU usage can be tracked according to job size, and the like. According to what kinds of files, and the size of the files to be run, load balancing can be performed.
  • Prior load balancing application servers would generally take any tasks placed on the network, and deal with emergency conditions as the criteria for passing work off to another server.
  • Such systems generally do not know what applications are running on them (i.e. Word, Excel, etc.), but simply watch for the emergency conditions. When such conditions occur, tasks are shunted off to another server.
  • the present system manages ahead of the processes, and keeps track of what jobs and loads are being placed on the different servers comprising a system.
  • the system employs knowledge of the different applications, and what kind of workload such applications will generate on a server.
  • Such metadata is built into the present Farm system in determining how underlying Fields will allocate incoming jobs.
  • EPS is a file format used in Prepress operations.
  • EPS contains the information required to create a printed document containing graphics images.
  • EPS files contain a variety of other data pertaining to reproduction of the image, for digital display or for print. Such other data might include, but is not limited to, color selections, color settings, scaling of graphics, embedded fonts, and so forth.
  • EPS files are a specialized example in the generalized use of "consistent PostScript" Print Ready Files, as described in the incorporated references.
  • the present invention provides a process to normalize (or "wash") the information that might be shared between a variety of software applications working on a file.
  • a shared data structure results. This permits such applications to run in an automated environment wherein the color settings are set as policies.
  • the policies can be managed, updated and tested automatically. These policies can be stored in the ILIAD database.
  • the washing process removes problems and anomalies, and creates an EPS file that is a "common denominator" EPS file. According to one aspect, all PostScript in this resulting file is converted to Level 1. Other Levels of PostScript might similarly be used. Incompatible operators are removed, and a PostScript header is created that is consistent and readable time after time.
  • Washing is therefore performed to provide EPS graphics that are structured in a consistent format.
  • washing can be used to: validate inks contained in the graphics as valid inks in a database (i.e. ILIAD, or otherwise); ensure that high resolution and low resolution versions of graphics contain the same inks; and to manipulate the size of low resolution graphics.
  • the process of washing accomplishes such structuring of graphics in a consistent format by using Adobe Acrobat Distiller and the PDF library thereby associated with it.
  • An EPS file is processed through Distiller, thereby creating a PDF.
  • the PDF is then exported to a new PostScript file using the PDF library.
  • the PDF library has the capability to rewrite the PDF format into a standard PostScript output.
  • Validation of inks is accomplished by parsing the standard exchange output Postscript file. Inks inside the file can be located and recorded. The inks are then checked against databased inks, and also against their low resolution/high resolution counterparts. In pre- washed EPS files, the various inks in the file can be located in different (and inconsistent) places throughout the file output structure.
  • the present invention provides a significant advantage over such prior art systems, in that it would be extremely difficult to find and record inks in such a pre-washed EPS file.
  • the size of the low resolution graphics can also be manipulated by using the Distiller down-sampling capabilities.
  • Distiller exposes an API, which can be used for manipulating the dpi (dot per inch) values of color, black and white, and grayscale images.
  • the resulting output from the automated washing process includes, but is not limited to the following advantages:
  • Washed EPS files are produced automatically by a hosted server application in an automated Prepress management system that is highly scalable; Unwashed EPS files are produced by human hands in error prone graphical art programs.
  • Washed EPS files produce PostScript in the same level. Any embedded files are converted to level 1 , creating a common denominator for EPS files; Unwashed EPS files can produce level 3 PostScript embedded within level 1 or level 2 PostScript documents causing some RIPs to crash.
  • Washed EPS PostScript headers are rewritten with accurate information. Any downstream applications using a washed file can rely upon consistent header information; Unwashed EPS files result in some applications generating PostScript headers with erroneous and/or inaccurate information. Applications downstream cannot rely upon consistent head information.
  • Washed EPS files are validated for use in the ILIAD system; Unwashed EPS files are not validated and have the possibility of producing errors in the ILIAD system.
  • Washed EPS files are tracked in the ILIAD system; Unwashed EPS files are not tracked.
  • Washed EPS files result in PostScript in an ASCII readable format; Unwashed EPS files can be in a binary, unreadable format.
  • a method for processing an image file and producing a consistent structure for visual medium materials contained within the file comprising: specifying source and destination file addresses on a storage medium; storing an unprocessed image file at the source address; retrieving the unprocessed image file and using at least a first conversion routine to thereby produce a vector-based medium file which is placed on the storage medium; retrieving the vector-based medium file and using at least a second conversion routine to produce a consistently structured file which is placed on the storage medium.
  • EPS Encapsulated PostScript
  • PDF Portable Document Format
  • load balancing of print jobs can be applied via analysis of the job size in relation to the processing capabilities of the associated device running the job processing application.
  • an apparatus for processing an image file and producing a consistent structure for visual medium materials contained within the file comprising: a storage medium, whereby source and destination file addresses are specified; an unprocessed image file stored at the source address; at least a first conversion routine that retrieves unprocessed image file uses it to produce a vector-based medium file which is placed on the storage medium; at least a second conversion routine that retrieves the vector-based medium file and uses it to produce a consistently structured file which is placed on the storage medium.
  • an apparatus to normalize the information in a file, as shared between a variety of software applications working on the file comprising: a source Encapsulated PostScript (EPS) file, whereby the EPS file contains unstructured information required to create a printed document containing graphics images; at least a first conversion module for converting the source EPS file to a Portable Document Format (PDF) file, whereby the file is structured using a PDF library of functions; at least a second conversion module converting the PDF file to a normalized EPS file having a shared data structure, whereby software applications can use the shared data structure to access the normalized file in a printing operation.
  • EPS Encapsulated PostScript
  • PDF Portable Document Format
  • a system for load balancing the processing of an incoming image processing job to a system comprising: a master farm service, whereby a user contacts the centralized master farm service to submit image processing jobs to the system; at least one farm service that provides status updates of the jobs associated with the farm server and the CPU usage of the farm service back to the master farm service; and at least one field associated with each farm service, the field managing at least one application plot for processing a job, wherein the master farm service analyzes the size of the incoming job and assigns the job to a farm service, a field, and an application plot based upon the job size and CPU usage of the farm services.
  • Figure 1 illustrates a representative prior art block diagram of certain steps performed by a human operator in forming an EPS file.
  • Figure 2 illustrates a representative prior art block diagram of certain steps found in the traditional creation of printable material by a print vendor.
  • Figure 2A illustrates, according to one aspect of the present invention, the setup process (for washing or otherwise) being performed before the Print Vendor of Figure 2.
  • Figure 2B illustrates, according to one aspect of the present invention, a representative series of steps that incorporates the washing process.
  • Figure 2C illustrates, according to one aspect of the present invention, a representative Print Ready File having washed EPS files.
  • Figure 3 illustrates, according to one aspect of the present invention, a generalized series of steps used in creating a print order.
  • Figure 4 illustrates, according to one aspect of the present invention, a block diagram of the overall ImageX.com automated system, as described more fully in the incorporated references.
  • Figure 4 A illustrates, according to one aspect of the present invention, further details regarding the ILIAD element of Figure 4.
  • Figure 4B illustrates, according to one aspect of the present invention, further details regarding the IOPC element as incorporated with the ILIAD element of Figure 4a.
  • FIG. 4C illustrates, according to one aspect of the present invention, further details regarding the Asset Management File Server of Figure 4.
  • Figure 5 A illustrates, according to one aspect of the present invention, the Farm Service of Figure 4, which hosts a variety of Prepress operations.
  • Figure 5B illustrates, according to one aspect of the present, a Master Farmer over many Farm services.
  • Figure 6 illustrates, according to one aspect of the present invention, an example Master
  • Farmer interacting with a Farmer Server, and a client.
  • Figure 7 illustrates, according to one aspect of the present invention, load balancing associated with the processing of jobs.
  • FIG. 8 illustrates, according to one aspect of the present invention, certain representative steps used in performing the washing operation.
  • Figure 9 illustrates, according to one aspect of the present invention, certain representative steps for validating EPS files by the rendering engine.
  • Figure 10 illustrates, according to one aspect of the present invention, a block diagram of elements used to provide both low resolution and high (full) resolution washed EPS files.
  • Figure 11 illustrates, according to one aspect of the present invention, a block diagram of representative elements in the washing process block of Figure 10.
  • Figure 12 illustrates, according to one aspect of the present invention, a block diagram of the relationship between the low resolution and high (full) resolution washed EPS files and the Print Ready File.
  • Figure 13 illustrates example header contents from a prior art unwashed EPS file.
  • Figure 14 illustrates, according to one aspect of the present invention, example header and footer contents of a washed EPS file.
  • Appendix A illustrates, according to one aspect of the present invention, a table showing a portion of the Adobe Distiller API with representative parameters that can be customized for print and preview graphics.
  • Appendix B illustrates, according to one aspect of the present invention, a table showing a portion of the Adobe PDF Library API with representative parameters that can be customized for print and preview graphics.
  • An invention is described herein for improving the efficiency and consistency in generating a print job from customer data (i.e. textual, graphical, and line element information).
  • customer data i.e. textual, graphical, and line element information.
  • numerous specific details are set forth in order to provide a thorough understanding of the present invention. It will be apparent, however, to one skilled in the art, that the present invention may be practiced without some or all of these specific details. In other instances, well known structures, software, devices, and/or process steps have not been described in detail, so as to not unnecessarily obscure the present invention.
  • the system of the present invention includes two main pieces: the Print Ready File format, which stores the PostScript data according to the present invention, and the related PostScript applications, which read and process the data in the file format according to the present invention.
  • an Internet-based ordering system provides the customer with the ability to interact with the system to preview and approve orders.
  • the figures below will provide an overview of the ordering system in order to demonstrate the context in which customers make use of the system. The detailed description will further provide a detailed description of the Print Ready File format and how it works with the related PostScript applications. It should be noted that the present invention would also work with other ordering techniques.
  • the Internet-based ordering system described below is one example of how the invention may be used.
  • Figure 2 illustrates a prior art block diagram 200 of representative steps in the process. The sections below, in association with Figure 2. will describe certain stages in the traditional process and delineate potential problems.
  • the process begins with a customer providing the print vendor with the information to be composed on the product.
  • the customer will typically provide the information on an order form, make annotations to a physical sample, and/or communicate the data verbally.
  • the print vendor's job is to create a layout of the print, product for the customer to preview and approve.
  • the print vendor will typically interpret the customer's information and compose a preview layout of the product in a publishing tool such as Pagemaker or Quark XPress. In Figure 2, this is shown by the print vendor computer 202 creating a preview layout 204, which results in a preview layout file 206.
  • the vendor begins the Prepress process. It is important to note that the "preview" that the customer is approving is a faxed copy of a low-quality print out. Because the quality is so low, it is possible (even under the best of conditions) that the final printed product may look slightly different from the proof that the customer approved. If the customer is very demanding or detail-oriented, these differences may not be acceptable and will require that the vendor re-print the order.
  • Step 208 in Figure 2 shows the next process step of composition.
  • the vendor must create a layout that is suitable for printing. To do this, all of the mastered elements that were included in the preview layout must be removed. This means that the vendor must open the preview layout file and manipulate the file data manually (or "by hand"). This is problematic, however, because the vendor is changing a file (or data structure) that the customer has already approved. It is possible that alterations will be made, either intentionally or accidentally, that will change the content or appearance of the product when it is finally printed.
  • Step 210 shows the print layout file, as so modified.
  • keyboard shortcuts Many professionals use a series of keyboard shortcuts (as offered by various programs) instead of a mouse (or other pointing device) to save time in performing simple tasks. These shortcuts typically require the user to press a modifier key (such as "ALT” or "CTRL”) and then press the desired shortcut key. Sometimes, however, the user will mistype and accidentally end up inserting text into a document inadvertently. For example, if the user is trying to cut a graphic or piece of text from a document, the user might use the keyboard shortcut for "Cut" (which might be CRTL-X).
  • Still other common problems involve maintaining consistency in at least the following: object spacing, lines, margins, color adjustment and selection, font spacing, justifications, kerning, and leading.
  • the goal, as yet unattained by prior devices or methods, is to ensure the integrity of text, line and graphic elements in both print and preview operations.
  • the act of opening the file can lead to the common problem of "font substitution.”
  • the preview layout file does not (generally) contain the font data necessary to display the text.
  • the file simply refers to a font file that is stored on the computer used to open the document. If the computer does not have one or more of the fonts referred to by the preview layout file, the closest possible match will generally be substituted from the fonts available. This is known as "font substitution.” Publishing programs may not inform the user that font substitution is taking place, which means that if the user does not notice the swap, then the substituted fonts will be saved with the new document.
  • the vendor finally exports the data as a PostScript file for printing, the file will refer to the substituted fonts, not the original fonts.
  • Step 212 next shows the imposition being performed on the print layout file 210.
  • Imposition is the process of preparing the "print layout" for production on a press.
  • the main goal of imposition is to arrange multiple pages and/or images in the proper order for efficient printing. For example, it is far more efficient to impose four or more business cards onto a single plate than to print each business card individually.
  • the imposition process also requires the addition of elements such as crop marks, registration marks, fold marks, color bars, die marks, and the like to the original print layout file. Imposition can be performed manually or via an automated program.
  • Automated Imposition Some vendors use software products such as Preps by ScenicSoft to build the imposed layout file. Although automated imposition is less susceptible to human error, the process is less than foolproof. For example, it is common for the automated imposition tool to run on a different computer than the original system used to produce the preview layout. This means that the layout file, when exposed to the automated imposition process is subject to, for instance, font substitution errors, graphic substitution errors, and the like.
  • Color separation is the process of separating a color image into a series of single color images that will be used to produce plates. When each single-color plate is printed on top of one another, the result is a composite color image.
  • the color separation step produces an imposed color separated file 218.
  • PostScript is converted 220 to PostScript, or a plate file 222, for processing by a RIP 224.
  • PostScript file may include font subsetting as well as OPI (Open Prepress Interface) comments (or executable segments of code) that are processed by the RIP device. In either of these cases, it is possible to introduce font and graphic substitution errors.
  • the output from the RIP (which is generally a bitmap file) is sent to an output device 226. which might include a Recorder or Image Setter.
  • the output device 226 places the image on a medium to be used by the press device 228.
  • Such media might include film or digiplate, with direct to plate referring to a media process for taking the image and putting it on a media.
  • the digital or binary file 230 could be received directly by a digital press device 232 for printing.
  • Prepress operations can be performed on the graphical (or other types) of files. These Prepress operations can be performed by the Farm service, (or one of the service hosting machines comprising a multi-server Farm).
  • the setup process 250 is performed before the Print Vendor element 202 of Figure 2.
  • Figure 2B shows a series of representative steps that might comprise the setup process.
  • a customer 260 supplies specifications for a product 262.
  • the customer might interact with a product specialist, who aids the customer in setting up the product, as shown in step 264.
  • Graphical files provided by the customer will be washed according to the present invention in step 266. Any resulting files can thereafter be rendered in step 268.
  • a Print Ready File is comprised of line, text, and graphical elements.
  • the text and line elements might be variable, or static.
  • the resulting Print Ready File is a representative example, and is shown to include a first washed EPS file 272 as a graphical element, a second washed EPS file 274 as a graphical element, a variable text data element 276, and a variable line data element 278.
  • the washed EPS files resulted from the Prepress washing operation, and where later included in the consistent PostScript PRF 270.
  • Figure 3 shows a block diagram 300 a generalized series of steps used in creating a print order.
  • a customer 302 contacts a website via the computer 304.
  • the customer inputs data on the website according to data prompts needed to generate the customer's desired print job.
  • the system of the present invention creates a Print Ready File (PRF), as shown in element 306.
  • PRF Print Ready File
  • the PRF 306 is shown to the customer 302 for on-screen proofing 308 of various elements comprising the product.
  • step 310 shows the order being sent to the printer via the engine of the present invention (described in further detail below).
  • the PRF 306 is thereafter sent to printer as a print order 312, and the manufacturing (or printing) process begins.
  • the steps of the present invention provide an elapsed time to order of approximately 10 minutes, or less.
  • a "setup phase” is used wherein the Print Ready File system is configured to produce a Print Ready File for each of the products that the customer wishes to order.
  • the Print Ready File system also configures an Internet front-end to provide a custom web site for that customer. The customer goes to a web site and selects a particular product to order. The web site loads a pre-configured order form for the selected product, and the customer enters the data they wish to appear on the card. The web site then transmits the data to the Print Ready File system, which generates the Print Ready File (e.g. as a unique PostScript file).
  • the web site takes this Print Ready File and uses it to create the preview layout. It does this by sending the Print Ready File to a viewer program (i.e. the Adobe Acrobat Distiller program), which reads the Print Ready File and creates a Portable Document Format (PDF) file.
  • PDF Portable Document Format
  • This file is then sent to the customer via the Internet and is viewed on the computer screen of the customer.
  • the preview is displayed as a PDF file. While other types of files might be used (GIF, etc.) PDF files are preferred because first, they are extremely high in resolution quality, and second, a PDF file provides a customer with a well- known format to process and view the preview layout. The customer then views the file and determines approval (or not) of the item.
  • the customer desires to change their individual data, the customer then views the order form again, changes their data, and the system generates a new preview file. If the item is approved, the customer clicks a button that tells the system to save the order.
  • the order data for the customer i.e. quantity, shipping address, etc.
  • the order data for the customer is saved to a back-end database, and the Print Ready File is saved on a server. Once the order is saved, it may be tagged as a "pending" order or a
  • FIG 400 is shown of the Print Ready File system and the interaction of representative components.
  • this Figure describes an overview of an Internet-based ordering system (as stated above, other ordering modes might be used).
  • the customer 402 is shown interacting with a customer computer 404.
  • a website residing on the primary webserver 408 is contacted via the Internet link 406.
  • An Image Logic Information Database (ILIAD) 410 is coupled to the server 408.
  • IILIAD Image Logic Information Database
  • ILIAD 410 The general data composition of ILIAD 410 is further described in Figure 4a.
  • Product and design information are shown generally as element 460, and is shown to further include asset information 462.
  • Asset information is intended to include various customer logos, text, or fonts (i.e. "assets" of the customer) to be used on the printed products. Such information might be provided as data files, or via menu prompts and the like, from the customer.
  • Specifications and costs 464 would include information pertaining to individualized costs for implementation of certain designs, and the like.
  • Layout rules 466 would include the various rules to be used in arranging figures or text on the printed product, so that conflicts and inappropriate layout schemes do not occur.
  • Customization rules and options 468 might provide for further custom design capabilities in arranging unique layouts.
  • ILIAD 410 is also shown to include manufacturing information 470.
  • manufacturer information might include (but is not limited to) imposition rules 472, separation rules 474, vendor information 476, and trapping rules 478. These various rules are used in the production engine for arranging and preparing the images and/or elements in the Print Ready File (PRF).
  • Order processing and work-in-progress (WIP) information 480 is also shown. Such information might include (but is not limited to) customer information 482, work orders 484, shipping information 486. and pricing information 488.
  • An IOPC (ImageX Online Printing Center) database 490, or similar Online Printing Center module, is shown incorporated with ILIAD, with further details regarding its data contents described in Figure 4b. The IOPC database might also exist separately from the ILIAD, but is shown incorporated here as one embodiment.
  • the IOPC 490 is shown to include (but is not limited to) corporate procurement rules 491. Such rules might further include users/roles 492, privileges 493, purchasing rules 494, and billing/shipping rules 495. Customer Products/Assets 496 are shown further comprising IOPC 490. This data grouping 496 might include design/brand information 461 , asset information 463, catalogs-products-kits 465, and customization rules/forms 467. The IOPC 490 is shown to further include a variable information database 497. This data store contains information that regularly changes, such as locations, departments, titles, etc. 469. Employees 471 are also included in this data grouping 497. Referring again to Figure 4, the PRF 412 is next sent to the Farm 414 (or "the Farm").
  • the Farm 414 is generally comprised of at least one, and usually several, high powered computers (e.g. a PCs running Windows NT).
  • the farm is designed to load balance file processing tasks by determining system impact of various jobs and distributing them accordingly.
  • the Farm is also highly scalable, with control being routed through a single point of contact (i.e. a server, which might be referred to as a "Master Farmer").
  • Each different file processing module (or “Farm Plot”) runs out of process from The Farm main process.
  • each Plot is controlled by a "Field” which is specific to the plot.
  • the Field communicates with the Plot and handles all the specific interactions with the Plot. Jobs can be re-routed if failures occur within any particular Farm, Field, or Plot.
  • the Farm in general, introduces little overhead in processing of tasks, and each different Farm service can be configured to run any of the file processing tasks.
  • the Farm 414 provides a platform apart from the webserver 408 for running processing steps on the PRF. It should be noted that any such processing could also be done on the webserver 408.
  • the completed PRF 416 is thereafter passed onto the Asset Management File Server
  • AMFS AMFS 418.
  • the general data composition of the AMFS is further described in Figure 4c.
  • the AMFS 418 is file server (or database or the like) used to store components relating to a client's product which should generally not change. In other words, these are the "Assets" of the client, such as company logos and the like. Such components are intended to include (for example) Encapsulated PostScript (EPS) files containing customer logos and graphics. Further included are diagrams, illustrations, static text and the like. Referring now to Figure 4c, the AMFS 418 is shown to contain representative data, including for example low resolution EPS files 419, high resolution EPS files 421, Preview PDF files 423, and PostScript Fonts 425.
  • EPS Encapsulated PostScript
  • the user can also request a preview of the PRF 420.
  • the Farm 414 reads back the preview PRF 422 from the AMFS 418 data store.
  • the preview PRF 422 is then sent back to the web server 408 which applies software such as the Adobe Acrobat Distiller program. This (or similar) software reads the PRF and creates a PDF or similar file.
  • the preview PRF file 422 is then sent to the user via the Internet and is viewed on the customer's computer screen.
  • a batcher 426 and plater 428 are shown which are each typically comprised of a PC or the like.
  • the batcher 426 receives the PRF 424 and performs logical imposition on the data. This would include server based software for automatic imposition.
  • the plater 428 performs further steps including, for instance, imposition and color separation, and the formation of a high resolution print file.
  • Both the batcher 426 and the plater 428 communicate via link 41 1 with the ILIAD 410 in order to read and use the rules stored therein in performing their designated tasks.
  • the batcher 426 and plater 428 also communicate via link 427, which might include an TCP/IP link or the like.
  • a plate file 430 is thereafter stored in the AMFS 418.
  • the plate file 430 is also sent to a vendor order system (VOS) 432.
  • the VOS 432 is typically comprised of a PC or the like.
  • the VOS 432 serves as a transactional machine, or a gate for all other vendors which might exist downstream.
  • the VOS 432 might process tasks or information, including but not limited to, job instructions, purchase orders, invoices, payments, and shipping status of orders.
  • the VOS 432 includes a link 434 to the ILIAD in order to retrieve various business information pertaining to particular customers.
  • the VOS 432 receives a plate file 430 from the plater 428.
  • the plate file 430 is yet another type of PostScript file (whereas other types might be used).
  • VOS 432 might be used to send the consistent plate file to any other system or request source via any reasonable medium.
  • Such information could be (for example) traded, auctioned off, or distributed across many different markets, in many different ways, and across many different mediums. It could be supplied by various customers and aggregated for processing by VOS and ILIAD.
  • an Internet connection 436 is shown wherein a vendor computer 438 interacts with the VOS 432.
  • the vendor computer 438 negotiates an order with the VOS 432 and receives the plate file 430. Many other such vendor computers might exist and contact the VOS 432.
  • Vendor computer 438 thereafter sends the plate file 430 to a Raster Image Processor (RIP) 442.
  • the RIP 442 is typically a PC or the like running RIP software.
  • the RIP produces a bitmap file 443 which is sent to a Recorder 444.
  • the recorder 444 is an image setting device which takes the raw bits from the RIP and translates them into a press input medium 446.
  • Such media 446 might include film, RC paper, or whatever input source the press 448 is looking for.
  • the press 448 takes the input medium source and produces the end result, in this case a business card 450.
  • the business card 450 is shipped or routed 452 back to the customer 402 to complete the overall process.
  • the overall process 400 described in Figure 4 makes use of an inventive Print Ready File that provides many advantages, including but not limited to the following: (1) The file preferably maintains its state, even if the elements that comprise the file are altered in the creating application. For example, high resolution files can be logically embedded for access and processing at an appropriate point in the Prepress process described herein. (2) The file contains both elements that the customer wants to see in a preview, and elements that a print vendor needs to see for a printing, each one being potentially mutually exclusive. (3) The file can be fed, or converted and fed, into imposition software, and color separation software. (4) The file can be fed, or converted and fed, into software to generate a PDF file or bitmapped image for a preview. (5) The file can create basic elements (e.g. ten.
  • the file supports three representative element types: text, line, and embedded graphic (raster or vector).
  • the file preserves the integrity of embedded graphics which originate from customers using standard graphics programs such as FreeHand, Quark. Illustrator. PhotoShop and PageMaker.
  • the file maintains the integrity of text, line, and graphic elements in both print and preview. This integrity can be demonstrated in the way of fonts, kerning, leading, line widths, and graphical reproduction.
  • raster images may be downsampled when converting to a preview file type.
  • the output to the print vendor should preferably be in Level 1 PostScript, to support all possible RIPs.
  • the preferred embodiment implements the Print Ready File in the Adobe PostScript language. It should be noted that other languages aside from PostScript can also be used that support the above conditions. For example, other page composition languages/formats can be used. Also, other RIPs or specialized equipment can be supported for custom print orders, and the like.
  • the present invention provides for running any of a variety of operations on the Farm Service, or associated services.
  • Prepress operations can be performed.
  • a representative Farm service 500 is shown running the operations of: creation of Print Ready Files 502, Trapping 504. Color Separation 506, and Imposition 508 (all in relation to formation of the PRF).
  • other operations might also be performed.
  • a Master Farmer 550 is shown interacting with a plurality of Farm services 552, 554, 556, and 558. Still other Farm services might also be connected to the Master Farmer, as indicated by the continuation symbol 560. The collective interaction of the Master Farmer and the Farm Services will be referred to as the Farm.
  • Figure 6 shows the interaction between the Master Farmer and Farm services in more detail.
  • a first machine N 600 is shown hosting (or running) the Master Farmer 602.
  • a second machine N+l 604 is shown hosting (or running) the Farm 606.
  • the Master Farmer 602 interacts with the Farm 606 via link 603. This link might be over any of a variety of transmission mediums, including the Internet.
  • Still other machines i.e. machine N+M (640), can be included to host other Farms, and interact with the Master Farmer via link 642.
  • the basic structure underneath a Farm service includes Fields, e.g. 608 and 610.
  • the purpose of a Field is to communicate with a specific Plot (e.g. 612, 614, 616, and 618).
  • a Plot is an application (or the like) that can be made to run out-of-process from the Farm.
  • a Plot is generally a device that runs a secondary application with job data, in order to generate an output.
  • the Plot is essentially the device responsible for making sure the task (or job) gets completed.
  • the Plot is used to turn the job packet, which is also referred to as the Crop, into a format that a particular application can understand. It is generally the function of the Plot to monitor the job and encapsulate the time estimation for completing the job.
  • Sowing When the Master Farmer passes a crop to the Farm, it is referred to as Sowing.
  • the Farm hands the task off to the Field it is can be referred to as "Planting."
  • This out-of-process structure of Plots is maintained so that if something were to go wrong with the Plot, it does not necessarily affect (in an adverse way) the running of the Farm system.
  • Each Plot processes a file or task, and each Plot is tied to one application.
  • the Field serves as a place for the Farm service to find out the status of the Plots.
  • the Field is generally configured to run as part of the Farm service process. If the Field goes down, then the associated Farm service also goes down. Plots, however, generally need to run out-of-process since the system will have little control over third party applications. If a third party application ceases to work, then it will not take down the whole associated system.
  • a client 620 (as typically shown using a CPU) interacts with the Master Farmer 602 via link 605.
  • the client provides tasks or jobs, such as files or the like, to be processed by the system. These tasks or jobs are represented as job A (622), job B (624), and so forth through job E (626).
  • job A (622), job B (624), and so forth through job E (626).
  • job A (622), job B (624), and so forth through job E (626).
  • An example Plot might include Adobe Acrobat Distiller, which converts a PostScript file into a PDF file.
  • PDF Portable Document Format
  • PDF files are created using Adobe Acrobat, Acrobat Capture, or other comparable products.
  • the Acrobat Reader is typically used.
  • PDF files are particularly useful for documents such as magazine articles, product brochures, or flyers, when it is desired to preserve the original graphical appearance of the pages.
  • Viper is used to generate Consistent PostScript files.
  • the overall system structure might include many such Plots, each of which are capable of running the same application such as Distiller, Viper (or others). Such redundancy allows for simultaneous processing of similar tasks or jobs.
  • Each separate Plot is configured to communicate with its associated Field, and the Farm will "oversee” (manage, monitor, etc.) the Fields underneath it.
  • the system is designed to let any number of Fields run on a particular Farm. If it is determined that any particular Plot is too processor intensive, that particular Plot can be run on a single Farm service, and/or on a single Farm machine. This can be used to speed up the processing of Plot applications on other Farm machines.
  • the different elements of this system can be segregated and moved very readily from one machine to another. For instance, a Field (with all of its Plots) running on a particular machine can be moved onto a different machine. This can provide extra processing speed for Fields remaining on the original machine.
  • the Farm system is generally scalable, since the system is controlled by a single point of contact, namely the Master Farmer.
  • the Master Farmer distributes work among the Farm services.
  • Each machine in the Farm system has an instance of the Farm service running on it.
  • Each Farm communicates with the Master Farmer, thereby making itself available for jobs.
  • Each Farm can have one or all of the file processing tasks running on it. As many new machines as are needed can be added to run the Farm service, and thereby accommodate varying loads.
  • Each Farm service can include configurable parameters to control its system usage (e.g. Windows NT threads, or the like).
  • the service can also be tuned to particular tasks that the service performs, and to the machine that the service is running on.
  • the Farm system can take advantage of multiple processors, and be made to scale upwards (or downwards) according to the system on which it is running.
  • System failures are when a particular Farm service, Field, or Plot fails unexpectedly when trying to process a task. This failure would generally be in an area that should not be failure. In such a case, the Farm service will alert the Master Farmer that it will no longer accept tasks, and shut itself down. When a particular Farm has shut itself down, or stopped communicating, the Master Farmer will route all tasks running on that Farm to other Farm machines running that specific file processing task.
  • the Master Farmer therefore serves as a central load balancing area.
  • the overall Farm i.e. the combination of the Master Farmer and Farm services
  • the Farm determines how processor intensive each particular application is, and processes the file either locally or remotely.
  • the Farm is configured to determine the system impact by the size of the job rather than the actual task being performed.
  • Each different type of file processing task judges the relative size of each task and the Farm uses this size, and the current processor load, to determine how to distribute (or load balance) the various tasks.
  • Example jobs might include: creating a consistent PostScript file, converting a PostScript file into a PDF file, or converting a PostScript file into a BitMap file.
  • the Master Farmer has one or more Farm machines connected to it.
  • the Master Farmer machine might also be configured to have a Farm process running on that same machine.
  • the Master Farmer is constantly receiving updates from each Farm machine (or server), wherein the Farm machine provides feedback on the burden level of the Master Farmer.
  • the burden level relates to how long a particular job will take on that Farm Service.
  • Each Farm 702 receives jobs A. B, ...E from the Master Farmer.
  • the Farm sends the respective jobs to a Field, which has associated Plots 706, 708, and 710.
  • the jobs are sent to the respective Plots according to the job type. For instance, if a client wants to convert a PostScript file into a PDF, the client sends that particular request to the Master Farmer.
  • the Master Farmer determines which particular Field has the necessary application (or Plot) associated with it to accomplish this task.
  • the Master Farmer maintains an evolving list of the Farm services and associated Fields and Plots. The Master Farmer walks through each Farm service, and determines which potential Plots might be able to process the task.
  • the Master Farmer also determines the level of burden for each Farm service.
  • the level of burden is a function of the CPU usage for the machine associated with the Farm service, and the size of the jobs being processed by each set of Plots associated with a Field.
  • Each task being sent to the Master Farmer has a size associated with it. This is a relative number that is used to estimate and load balance the task.
  • Each Field maintains its own chart 712 of CPU usage versus job size, in order to provide an estimate of how long the particular job will take.
  • Figure 7B shows a representative example of such a chart 712 in more detail.
  • the charts are compiled into an overall level of burden on the Farm service, and the Master Farmer decides which Farm service will receive any particular incoming task based upon the relative burden level for such Farm services.
  • An estimate of how long it will take to process the job is sent back to the client.
  • the job is sent to a particular Farm service, and the Farm service provides an update of the time estimate to complete the job, which in turn is again sent back to the client.
  • the Master Farmer might detect that a job is going to take longer than it should, and thereafter re-estimate how long the job will take, in light of all the other traffic on the system. Clients can also request new estimates.
  • the chart therefore serves as an indication of how busy the farm is over a given period of time, and/or provides a historical curve of performance for a particular applications, such as Image Alchemy or the like. Over certain time periods, each Field is updating this chart, and the Farm service packages up all this information and updates the Master Farmer with such information.
  • an X-Y performance curve for Distiller over a time period for instance the last few hours, will exist for estimation purposes. If an incoming file is 2 MB, then an estimate can be made regarding processing a file of this size.
  • An important feature of the present systems is that it looks at pending files. If for instance a 600 MB file were pending, then estimates would be adjusted accordingly.
  • the chart is analyzed for each Farm in light of the size of the incoming jobs for that Farm.
  • a job might be shifted and queued up to be fifth in line on a first Farm service, as opposed to first in line on second Farm service, because it has been estimated that the job will run faster despite being fifth in line on the first Farm Service.
  • the time estimate for completion will control the ultimate placement of the job on a Farm service. Both queuing and historical performance estimates are thereby used in deciding which Farm service will handle the job.
  • Prepress applications are very file intensive. As a result, the system is constantly reading and writing to such files during the course of processing them. This allows estimates on system usage to be based upon system impact assumptions (and predictions) relating to such file usage. For instance, Prepress applications generally have a large impact on the system; and/or a large impact on the network card if the application is reading and writing to the network; and/or a large impact on the drive if the application is reading and writing to the local disk; and so forth along similar relations. Hence, a chart can be constructed regarding system impact.
  • the size of the job is generally easy to determine. For instance, if a PostScript file comes into the system having a certain file size, then it is relatively straightforward to estimate how large the resulting PDF file will be. For most Prepress applications, there are generally input files and output files, which follow similar predictive patterns. In other systems ⁇ which might host business logic or the like — it is generally difficult to predict the impact that different jobs might have on the general applications server. File (or job) sizes, however, provide for more regular estimation.
  • the present invention is also configured to introduce little to no overhead in the processing of tasks. Certain speed advantages might be realized by running an application locally on a client machine. However, the present Farm system passes the job request from the Master Farmer to the Farm, and to the Field, and to the Plot, with no significant tradeoffs in speed. Moreover, a very large file might be processed more quickly on the larger machine (or machines) comprising the Farm System, as compared the smaller (less powerful) local machine.
  • the present Farm system is also easily expandable, wherein each of the Farm services can be configured to run any of the file processing tasks. If a particular task is very resource intensive, it can be ran alone on the system. When each Farm service tells the Master Farmer that is running and ready for tasks, it also identifies the tasks that it is servicing. Adding of new file processing tasks is as simple as placing the new Field and Plot on a machine, and in a particular directory. Color Washing
  • washing is described in the above referenced provisional application no. 60/152,521.
  • the more generalized process of washing is a process for manipulating encapsulated PostScript (EPS) files and producing a file in a consistent format for use by other applications. Washing is one of many Prepress operations that can be automated by hosting the associated application on a server or other networked computer.
  • a client application communicates with the Master Farmer and requests the Master Farmer service to perform certain tasks. For example, the client might ask the Master Farmer to take a PostScript file and convert it into a PDF file. Additionally, the client might request that the PDF file be converted into an EPS file. Each such job or task will carry with it a different set of parameters. Additionally, the job will operate on a source file and produce a destination file. In the present system, these files are stored in the Asset Management File Server (AMFS).
  • AMFS Asset Management File Server
  • a block (or flow) diagram 800 is shown of certain representative elements used in the color washing process.
  • the client forms and specifies a design that the client wishes to have washed.
  • the client creates and passes parameter files with certain settings.
  • the source and destination files are created and stored on the Asset Management File Server.
  • Each Farm service functions essentially as a large file processor, and will take input parameters that point to stored source and destination files.
  • the client will place an unwashed EPS file on the AMFS, and provide directions and input parameters for a Plot (or washing module) to perform a certain operation on the file.
  • the washing process utilizes two Plots, or conversion modules 810 and 816.
  • a Level 2 or Level 3 PostScript file is supplied as the source file. This file may have many embedded problems, such as multiple embedded EPS files.
  • the unwashed EPS file 808 is retrieved from the AMFS 814 and used by the PostScript to PDF conversion module 810. or Distiller Plot, to RIP the file and break it down into a known (or public) format.
  • the Distiller Plot 810 then writes the resulting PDF file 812 back onto the AMFS 814.
  • the PDF to PostScript conversion module 816 retrieves the PDF file 818 from the AMFS 814.
  • This routine or function is part of a PDF Library of routines, any of which might be used to perform operations on certain source or destination files.
  • the PDFExport routine takes the PDF file 818 from the AMFS 814, and writes an ASCII Level 1 Postscript file (which is a "washed" EPS file) as shown in block 820.
  • This resulting Level 1 file is stored on the AMFS 814 in the specified destination file location.
  • the client communicates with the Master Farmer 806 through a specific set of parameters. The client essentially supplies the input files and the desired location for the output files. A collection of settings are supplied regarding how to create the output file.
  • the AMFS serves as common storage.
  • the client stores the unwashed EPS file (i.e a raw PostScript file) on the AMFS before invoking this series of steps (in Figure 8, or otherwise) by talking to, or interacting with, the Master Farmer.
  • the resulting washed EPS file will be embedded in the final PRF file.
  • the process is automated.
  • the PDF file is created with predefined settings from the unwashed EPS file.
  • the PDF file is thereafter converted into the Level 1 ASCII PostScript format.
  • the user of the Distiller program would set up their own local parameters to run Distiller (or the like). Similar local parameters would be used in converting (or exporting) PDF to PostScript to form the washed EPS. As such, the user would control (among other things) the fonts, letting, turning, setting, scaling, and the like. This level of unguided user control makes for irregular results.
  • the present system provides a consistent and predefined method for manipulation of the file.
  • the referential integrity are the result of the normalization (or washing) process that permits applications to run in an automated environment, wherein the color settings are set as policies.
  • Policies are input parameters for processing of the files, i.e., whether the files are going to have font subsetting, or whether the fonts are going to be embedded, and the like. These policies are managed, updated, and tested automatically.
  • an EPS file goes through the Distiller (under control of the PostScript to
  • PDF conversion module 810) which simply turns the PostScript into PDF.
  • Distiller has the capability to convert any PostScript file to PDF format. Exceptions exist, however, including files with duotones where RIP specific device transfer functions are used.
  • Print graphics are converted to PDF format unchanged.
  • Preview graphics are downsampled (changing their dpi values for images) and converted to RGB color space using Distiller parameters. Preview graphics are manipulated to force them to smaller sizes to facilitate viewing over the IOPC (or similar device).
  • Distiller allows control of internal parameters used in conversion to PDF format by placement of Distiller specific operators in PostScript files.
  • the PostScript to PDF conversion module 810 (the hosted application), writes a new PostScript file containing the Distiller-specific parameters and links to the target EPS file(s) being washed.
  • a table of parameters are shown, with certain representative settings, in Appendix A. These parameters are the policies to be used in color settings, and the like.
  • an API application program interface
  • Appendix A represents the custom parameters of an API, with settings that may be specified for Print and Preview graphics according to the present color washing process.
  • the resulting PDF file is exported back into EPS format using the Adobe PDF library as a Level 1 ASCII PostScript file.
  • the Adobe PDF library exposes functionality through use of an API. This exposed functionality is used by the PDF to PostScript conversion module 816 (a hosted application), to control EPS output.
  • the settings are stored in a structure and there is a user-defined type with parameters, these parameters becoming the actual variable names.
  • the variables are placed in the structure with values and then a particular function is called. In the present instance, customer parameters may be specified for print and preview graphics with reference to the API listed in Appendix B.
  • the function call used to export the PDF file format to EPS file format in the PDF library is "PDFLPrintPDF.” This function definition is as follows:
  • Appendix B (e.g., incBaseFonts, PDInclusion, incEmbeddedFonts, etc.) are members of this structure.
  • the aforementioned PDF library is very large, with thousands of functions available to clients.
  • the present solution uses one such function with the same parameter names as defined by the PDF Library. Hence, a programmer familiar with the Adobe PDF library would find these same parameter names for this function.
  • a comparative table can be created which allows the process to automatically determine and convert setup parameters for the particular application. When parsing through a PostScript file, settings can be determined which are "off and "on.”
  • the present system allows conversion of the set parameters to ones that will ultimately be used by the system. For instance, for creating a Print file there are certain policies that will be used. For creating a Preview file, still other policies will be used.
  • validation can be performed in the system of the file to be viewed or printed.
  • the image (or image asset) that is ultimately going to be displayed or printed is the one that is valid in the ILIAD database.
  • the image is valid because the process described herein has been performed properly, and the results are stored for access by a variety of applications.
  • a client might perform color washing, color separation, or trapping on the image themselves.
  • the present system provides such a record, so that whatever else is done with the image, it can be validated that the proper image has been pulled from ILIAD and used to generate previews onscreen or printed documents.
  • a number of other applications can use ILIAD and this type of process to validate the images they are using, as well as processing them.
  • the recorded Metadata about images in a particular job can be reused.
  • Validation of inks is accomplished by parsing the standard exchange output PostScript file. Inks inside the file are located and recorded. The inks are then checked against inks in a database, and also against their low resolution/high resolution counterparts.
  • pre-washed EPS files in the prior art the various inks in the file can be located in different (and inconsistent) places throughout the file output structure.
  • the present invention provides a significant advantage over such prior art systems, in that it would be extremely difficult to find and record inks in such a pre-washed prior art EPS file.
  • the size of the low resolution graphics can also be manipulated by using the Distiller down-sampling capabilities.
  • Distiller exposes an API which can be used for manipulating the dpi (dots per inch) values of color, black and white, and grayscale images.
  • the present invention provides for maintaining the application centrally and in a controlled fashion so that applications can be used to generate a consistent output.
  • the present process may be embedded with any suitable application, such as a Forms Design application, or the like. In general, it makes no difference who is asking for the washing to be performed. Any application, such as a web site design tool, that manipulates color images may so benefit. For instance, a web site user interface might be used to create the washed EPS files. If a user were hosting a website, and wanted to use the herein mentioned system to produce the correct logo for a client, an appropriate function call could be made. The network connection with the AMFS would allow access to a stored bitmap image, or printed document, and the appropriate level of the image could thereby be generated.
  • the chosen client application is a product setup module 409 (or tool) for creating new business cards and the like.
  • the module is shown running on the web server 408, but might similarly be processed at the customer computer 404, or elsewhere.
  • the client might use a business card development application called "Forms Design" or the like.
  • the same process could similarly be coded into other types of client applications.
  • Clients might even author their own documents, using their own layout tools or third party layout tools.
  • the process could be inserted into the middle of existing (or other types of) applications, with the results being merged for viewing documents, or for storing documents.
  • the present product setup module utilizes the benefits of the present invention by feeding back a viewable image so that a proof of the business card can be generated with the washed imagery therein.
  • the process When adding a new template to the product setup module 409, the process will wash the EPS automatically and report if the EPS contains any colors not in the ILIAD database, or if the colors are spelled differently from their ILIAD counterparts. If the color information is incorrect, the product setup module 409 will not allow the graphic into the system until it is corrected. The product setup module will import the color information into ILIAD only if it correctly identifies the colors in the EPS file created by module 816. When creating Print Ready Files, the system will preferably not accept unwashed EPS files. As a result, no unwashed graphics are used in such a system. Figure 9 shows validation of such EPS files.
  • a validation module 902 is shown giving or providing unwashed EPS files 904 to the Asset Management File Server (AMFS) 908.
  • This validation module might include a rendering engine, or the like. The process described above washes the EPS file and the validation module 902 obtains the washed EPS files 906 from the AMFS 418. The rendering engine 1102 thereafter validates that the EPS files are washed, and will not accept such unwashed files.
  • high resolution refers to graphics that are actually sent to a vendor's imagesetter at the time for printing.
  • Low resolution refers to graphics that are previewed by customers from the IOPC web site (or OPC module), in the place of their high resolution counterparts. High resolution graphics can be extremely large and would be very unwieldy for viewing over the limited bandwidth connections that many customers use.
  • FIG 10 a block diagram 1000 is shown of certain representative elements used to create washed low and high resolution EPS files.
  • a source EPS file 1002 is shown being directed into washing subsystem 1204.
  • the washing subsystem can be used to create either a lower resolution washed EPS file 1208, or a full (or high) resolution washed EPS file 1210. As mentioned above, these washed files are stored on the AMFS 418.
  • the source EPS file 1 102 is fed into a PostScript to PDF conversion module 810.
  • a PDF file 1106 results (as stored on the AMFS).
  • the PDF file is fed into the PDF to PostScript conversion module 816.
  • the washed EPS file 11 10 results, and is stored on the AMFS.
  • Figure 12 shows the flag settings for use in a consistent PostScript file (or PRF 1206) to select wash/validate/preview (low resolution) or print (high resolution).
  • the associated flag settings 1204 include an embedded graphic element, and the Preview flag is set.
  • associated flag settings 1210 include an OPI linked graphic element, and the Print flag is set.
  • FIG 13 shows an example of a Document Structuring Convention (DSC) header for an unwashed EPS file (with an EPS file embedded in it).
  • Figure 14 shows an example of a washed Print EPS file header and footer. Note that a normalized bounding box and additional colors are now shown in the DSC comments for the file. DSC comments are shown with a leading "%%" sign. Regular PostScript comments are preceded with a leading "%” sign. DSC comments are published by Adobe so that anyone looking at a particular file can find the bounding box, or other standard Postscript information, and appropriately read it.
  • DSC Document Structuring Convention
  • the contrasting header/footers in Figures 13 and 14 show the differences between a washed and an unwashed EPS file.
  • black was the only color showing in the DSC documented color comments.
  • the EPS file actually has another EPS file embedded in it, which has three process colors.
  • the application which created the file created it improperly. Since the comments are not necessary to have the file processed by the PostScript interpreter, the application wrote the colors incorrectly. After washing, the colors magenta, yellow, and black are also shown. Hence after washing, this necessary information from the internal PostScript files is moved into the DSC comments outside.
  • EPS files with any random application (i.e., Freehand, Photoshop, or the like). Such users might generate these files improperly, and such files would need to be parsed specifically for every possible variation. For instance, an outside PostScript file might have one font in it, and an inside PostScript file might have another four or five other fonts embedded in it. The outside comments would not show those internal fonts unless washing were performed to correct such comments. Still another benefit of washing is that the fonts are identified and the file can be rejected if the proper font is not found.
  • the present system preferably requires that all the files have the necessary fonts included within them, and that such files cannot refer to any outside documents.
  • Creating bitmaps of the unwashed/washed files should show no differences in the visible appearance of the files. Washing should generally only produce differences regarding the file's internal structure. An exception is the Preview file, which is downsampled. Differences might exist if the user is looking at washed preview downsampled images for a source EPS file that was a rastered file, and the source had significantly larger dots per inch (dpi) than the downsampled version. This preview file might look slightly "worse" than the print image. The desired result of washing would be for the file to look identical to the human eye. Washing should not affect the quality or actual image that comes out. It is important to the customer using the system that the output looks essentially the same.
  • policies might readily be changed to accomplish other end results. For example, more policies might be added, or existing ones removed. Also, if it were desired to generate level 2 PostScript for a vendor, the policies could readily be changed to accomplish this. The image resolution might also be changed. The policies are therefore specifically defined for a particular set of needs. If different file formats are needed, the policies would be changed to accommodate the new file format. If such new file formats were required, then the policies would be predefined in order to generate consistent file formats. All files of that type would then be generated according to the predefined policies. The central hosting of this type of metadata allows for changes in the file format to be recorded as to what types of jobs are affected. On the print management side (i.e.

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

L'invention concerne un procédé et un dispositif servant à produire des fichiers d'images graphiques normalisés (ou homogénéisés) qui possèdent une structure de fichier homogène, ces fichiers d'images graphiques étant ensuite utilisés pour produire une structure de fichier homogène prêt pour l'impression. Un fichier d'image source, ou non traité, est d'abord converti en un fichier support à base de vecteurs et mis en mémoire. Ce support à base de vecteurs comprend un format de fichier PDF, le sous-programme de conversion utilisant Adobe Distiller pour produire des fichiers PDF. Le fichier support à base de vecteurs est ensuite récupéré et converti en un fichier structuré de manière homogène, qui peut être utilisé par diverses applications associées à un procédé d'impression. Le fichier de structure homogène comprend le langage PostScript, et en particulier PostScript ASCII de niveau 1. Le sous-programme de lavage est destiné à être mis en oeuvre comme opération de prépresse en vue de produire le fichier sus-jacent prêt pour l'impression, et peut être automatisé si nécessaire. Cette opération de prépresse peut être exécutée sur un service de batterie de processeurs et peut être gérée par un serveur de batterie de processeurs principal, et comporte un équilibrage de charge d'opérations de prépresse pour améliorer les performances du système dans son ensemble.
PCT/US2000/023829 1999-09-03 2000-08-30 Procede et dispositif d'homogeneisation de fichiers d'images graphiques et d'equilibrage de charge d'operations WO2001018690A2 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
AU73377/00A AU7337700A (en) 1999-09-03 2000-08-30 Method and apparatus for washing of graphic image files and load balancing of operations

Applications Claiming Priority (8)

Application Number Priority Date Filing Date Title
US15252199P 1999-09-03 1999-09-03
US60/152,521 1999-09-03
US48018500A 2000-01-10 2000-01-10
US09/480,334 2000-01-10
US09/480,185 2000-01-10
US09/480,645 US6903839B1 (en) 1999-09-03 2000-01-10 Apparatus for washing of graphic image files
US09/480,334 US6633890B1 (en) 1999-09-03 2000-01-10 Method for washing of graphic image files
US09/480,645 2000-01-10

Publications (2)

Publication Number Publication Date
WO2001018690A2 true WO2001018690A2 (fr) 2001-03-15
WO2001018690A3 WO2001018690A3 (fr) 2001-06-14

Family

ID=27496029

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2000/023829 WO2001018690A2 (fr) 1999-09-03 2000-08-30 Procede et dispositif d'homogeneisation de fichiers d'images graphiques et d'equilibrage de charge d'operations

Country Status (2)

Country Link
AU (1) AU7337700A (fr)
WO (1) WO2001018690A2 (fr)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN108804055A (zh) * 2018-05-18 2018-11-13 禧图纸品印刷（深圳）有限公司 基于gracol2013标准的经济型印刷方法、装置、终端与计算机可读存储介质
US12014092B2 (en) 2019-06-21 2024-06-18 Esko Software Bvba System and method for object-annotated trapping

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5287194A (en) * 1992-11-25 1994-02-15 Xerox Corporation Distributed printing
EP0605210A2 (fr) * 1992-12-28 1994-07-06 Canon Kabushiki Kaisha Procédé et appareil de traitement d'images et fac-similé
EP0692763A1 (fr) * 1994-07-13 1996-01-17 Bull S.A. Système informatique ouvert à serveurs multiples
US5644720A (en) * 1995-07-31 1997-07-01 West Publishing Company Interprocess communications interface for managing transaction requests
US5813348A (en) * 1995-06-17 1998-09-29 Man Roland Druckmaschinen Print job allocation system
EP0919909A1 (fr) * 1996-03-04 1999-06-02 Copyer Co., Ltd. Processeur d'images

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5287194A (en) * 1992-11-25 1994-02-15 Xerox Corporation Distributed printing
EP0605210A2 (fr) * 1992-12-28 1994-07-06 Canon Kabushiki Kaisha Procédé et appareil de traitement d'images et fac-similé
EP0692763A1 (fr) * 1994-07-13 1996-01-17 Bull S.A. Système informatique ouvert à serveurs multiples
US5813348A (en) * 1995-06-17 1998-09-29 Man Roland Druckmaschinen Print job allocation system
US5644720A (en) * 1995-07-31 1997-07-01 West Publishing Company Interprocess communications interface for managing transaction requests
EP0919909A1 (fr) * 1996-03-04 1999-06-02 Copyer Co., Ltd. Processeur d'images

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
BEALE S: "Get prepress ready PDFs from QuarkXPress" MACWORLD, JUNE 1998, MACWORLD COMMUN, USA, [Online] vol. 15, no. 6, pages 101-103, XP002152791 ISSN: 0741-8647 Retrieved from the Internet: <URL:http://www.computer-select.com/> [retrieved on 2000-11-14] *
FUCHS W ET AL: "DARSTELLUNG, KONVERTIERUNG UND FARBREDUKTION VON RASTERBILDERN AUF BASIS EINES UNIVERSELLEN ZWISCHENFORMATES VISUALIZATION, ADAPTATION, AND COLOR REDUCTION OF RASTER IMAGES BASED ON A UNIVERSAL, INTERMEDIARY FORMAT" IT + TI INFORMATIONSTECHNIK UND TECHNISCHE INFORMATIK,DE,OLDENBOURG VERLAG. MUNCHEN, vol. 36, no. 3, 1 March 1994 (1994-03-01), pages 30-37, XP000460255 ISSN: 0944-2774 *

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN108804055A (zh) * 2018-05-18 2018-11-13 禧图纸品印刷（深圳）有限公司 基于gracol2013标准的经济型印刷方法、装置、终端与计算机可读存储介质
US12014092B2 (en) 2019-06-21 2024-06-18 Esko Software Bvba System and method for object-annotated trapping

Also Published As

Publication number Publication date
WO2001018690A3 (fr) 2001-06-14
AU7337700A (en) 2001-04-10

Similar Documents

Publication Publication Date Title
US6429947B1 (en) Automated, hosted prepress application
US6396593B1 (en) Postscript to bitmap conversion of graphic image files
US6771384B1 (en) Imposition of graphic image files
US6353483B1 (en) Postscript to bitmap conversion of graphic image files
US6362895B1 (en) PDF to PostScript conversion of graphic image files
US6633890B1 (en) Method for washing of graphic image files
US6381032B1 (en) Postscript to PDF conversion of graphic image files
US6559966B1 (en) Trapping of graphic image files
US10089560B2 (en) ePOS printing
EP2482198B1 (fr) Système et procédé d&#39;identification de sauts de lignes
US6717686B1 (en) Electronic printing system and method
CN101059754B (zh) Java打印机
US6903839B1 (en) Apparatus for washing of graphic image files
EP1437663A2 (fr) Système et procédé de composition de documents
US20040049738A1 (en) Computer implemented system and method of transforming a source file into a transfprmed file using a set of trigger instructions
US7180614B1 (en) Distributed rendering of print jobs
US7239408B1 (en) Print processing system and method with document advisor service
JP2004341675A (ja) 開発システム、電子フォーム利用システム、サーバ、プログラム及び記録媒体
US20040153332A1 (en) Printed materials procurement system
US7339694B2 (en) Chit printing system, chit printing apparatus and chit printing method
US20070180353A1 (en) Systems and methods for generating documents using multimedia data gathering tools
WO2001018690A2 (fr) Procede et dispositif d&#39;homogeneisation de fichiers d&#39;images graphiques et d&#39;equilibrage de charge d&#39;operations
US6556308B1 (en) Color separation of graphic image files
WO2000067153A1 (fr) Systeme et structure de fichier offrant une copie de previsualisation et une copie finale a un client internet a partir du meme fichier de specification d&#39;impression
JP3221092B2 (ja) プリンタ制御装置

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A2

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BY BZ CA CH CN CR CU CZ DE DK DM DZ EE ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NO NZ PL PT RO RU SD SE SG SI SK SL TJ TM TR TT TZ UA UG US UZ VN YU ZA ZW

AL Designated countries for regional patents

Kind code of ref document: A2

Designated state(s): GH GM KE LS MW MZ SD SL SZ TZ UG ZW AM AZ BY KG KZ MD RU TJ TM AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE BF BJ CF CG CI CM GA GN GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
AK Designated states

Kind code of ref document: A3

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BY BZ CA CH CN CR CU CZ DE DK DM DZ EE ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NO NZ PL PT RO RU SD SE SG SI SK SL TJ TM TR TT TZ UA UG US UZ VN YU ZA ZW

AL Designated countries for regional patents

Kind code of ref document: A3

Designated state(s): GH GM KE LS MW MZ SD SL SZ TZ UG ZW AM AZ BY KG KZ MD RU TJ TM AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE BF BJ CF CG CI CM GA GN GW ML MR NE SN TD TG

DFPE Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed before 20040101)
REG Reference to national code

Ref country code: DE

Ref legal event code: 8642

122 Ep: pct application non-entry in european phase
NENP Non-entry into the national phase

Ref country code: JP