WO2000067153A1 - 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'impression - Google Patents

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'impression Download PDF

Info

Publication number
WO2000067153A1
WO2000067153A1 PCT/US2000/010456 US0010456W WO0067153A1 WO 2000067153 A1 WO2000067153 A1 WO 2000067153A1 US 0010456 W US0010456 W US 0010456W WO 0067153 A1 WO0067153 A1 WO 0067153A1
Authority
WO
WIPO (PCT)
Prior art keywords
file
print
preview
elements
print ready
Prior art date
Application number
PCT/US2000/010456
Other languages
English (en)
Inventor
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
Application filed by Imagex.Com, Inc. filed Critical Imagex.Com, Inc.
Priority to AU44690/00A priority Critical patent/AU4469000A/en
Publication of WO2000067153A1 publication Critical patent/WO2000067153A1/fr

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00—Commerce
    • G06Q30/02—Marketing; Price estimation or determination; Fundraising
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/12—Digital output to print unit, e.g. line printer, chain printer
    • G06F3/1201—Dedicated interfaces to print systems
    • G06F3/1202—Dedicated interfaces to print systems specifically adapted to achieve a particular effect
    • G06F3/1203—Improving or facilitating administration, e.g. print management
    • G06F3/1208—Improving or facilitating administration, e.g. print management resulting in improved quality of the output result, e.g. print layout, colours, workflows, print preview
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/12—Digital output to print unit, e.g. line printer, chain printer
    • G06F3/1201—Dedicated interfaces to print systems
    • G06F3/1223—Dedicated interfaces to print systems specifically adapted to use a particular technique
    • G06F3/1237—Print job management
    • G06F3/1253—Configuration of print job parameters, e.g. using UI at the client
    • G06F3/1256—User feedback, e.g. print preview, test print, proofing, pre-flight checks
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/12—Digital output to print unit, e.g. line printer, chain printer
    • G06F3/1201—Dedicated interfaces to print systems
    • G06F3/1278—Dedicated interfaces to print systems specifically adapted to adopt a particular infrastructure
    • G06F3/1285—Remote printer device, e.g. being remote from client or server
    • G06F3/1288—Remote printer device, e.g. being remote from client or server in client-server-printer device configuration

Definitions

  • the present invention relates to a system and file structure for producing fast and consistent visual medium materials.
  • the visual medium will be a printed object, i.e. a business card or the like, resulting from a file which contains text elements, line elements, and graphical elements.
  • the elements are arranged and processed in a manner unique to the present invention.
  • the visual medium might also include an electronic display, such as a computer monitor, or the like.
  • a representative block diagram 100 is shown of certain steps that might be used to procure an order by a customer. While the order might consist of any textual or graphical material, a business card example is used throughout to facilitate discussion.
  • an administrator in an organization must collect data from the employee who desires the business cards. Such data might include name, title, telephone and fax numbers, mobile phone number, e-mail address, etc. This data then gets telephoned or faxed to the printer as shown in step 102.
  • the printer typesets the information in step 104, and then faxes back a proof to the administrator in step 106.
  • the administrator then typically sends the proof to the employee for verification, and receives the returned proof with marked-up corrections.
  • the proof is then sent back to the printer in step 108.
  • the printer typesets the corrections in step 1 10 and faxes the proof back to the customer in step 112. Steps 108-112 might be repeated several times until the customer approves the proof in step 1 14.
  • the printer must go through several additional steps before the order is printed. For instance, the customer service department might enter the job into the printer's internal tracking and billing system. The job then goes to the Prepress department in step 1 16. which reproduces the content into a format so that it is ready to print. The manufacturing process is applied in step 118 and the order is printed. Getting through this queue of events with the printer usually takes several days.
  • 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. Preview
  • 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.
  • this task is made more complicated by a common practice called
  • the preview layout To control costs in printing, it is common to pre-print or "master” stock in bulk with certain static elements. In many cases the static elements are “spot color” or “process color” graphics (while the variable information is usually in a single color, often black). In order to provide a preview of what the printed product will actually look like, the preview layout must contain both the variable information and the mastered elements. Once the preview layout is completed, it is then printed and faxed to the customer for their approval.
  • 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. The errors that can occur are numerous and varied. Even simple procedures can result in major problems.
  • 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 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. When the vendor finally exports the data as a PostScript file for printing, the file will refer to the substituted fonts, not the original fonts. Sometimes the substituted fonts are very similar to the correct fonts, so they might look fine.
  • 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.
  • Imposed Layout File shown as 214. (It is important to note that some customers like to approve the final imposed layout. As a result, some vendors perform imposition during the preview stage.) Because the imposition process is manual, the errors common to the composition stage can also occur during imposition. Another problem is that because the traditional process for print production is so time-consuming, the information that is to appear on an order may change during the process. In many cases, additional last-minute orders can be added by the customer at any stage in the process, requiring the vendor to go back and make changes to the imposed layout.
  • 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 Once an imposed color separated file is produced it is converted 220 to PostScript, or a plate file 222. for processing by a RIP 224.
  • PostScript file There are many techniques used to create PostScript files. Depending on the workflow employed by the print vendor, the 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
  • the output device 226 places the image on a medium to be used by the press device 228.
  • a medium 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.
  • One proposed solution includes attempting to automate the process of preview and print layout generation by writing custom plug-ins to commercially-available publishing programs such as Quark XPress or Adobe PageMaker.
  • Example drawbacks to this solution include: (1) The modified software cannot generally keep track of which elements in a layout are mastered and which are not. This means that at least two PostScript files must be generated: one for the preview layout and one for the print layout; and (2) The modified software lacks the ability to store special production information in the PostScript file, such as ink codes, stock information, and other details. The overall solution therefore relies on humans to properly recall this information, or the solution must retrieve such information from yet another document, without any assurance of the accuracy of the production information in the other document. Moreover, these systems do not maintain a reference for standard corporate design or procurement rules for printed matter, and as such are prone to error and not susceptible to automated validation.
  • Another solution involves using Open Prepress Interface, or OPI.
  • OPI Open Prepress Interface
  • OPI Open Prepress Interface
  • Both desktop Prepress software and high-end Prepress systems can use OPI comments to minimize network traffic and image storage requirements. Certain functionality is desired, however, which OPI does not inherently provide. Example of such drawbacks include, but are not limited to, the following: (1) OPI does not generate preview or print layouts.
  • OPI itself cannot determine whether the system is printing the preview layout or the print layout. Moreover, even if OPI could discern which layout it is printing, it lacks the logic to decide which image to use in which situation. (3) OPI only works for graphic images. For instance, it cannot be used to control text data.
  • PostScript is a programming language for imaging devices.
  • the PostScript language does not constitute a complete solution to the aforementioned problems.
  • the PostScript language does not contain any concept that differentiates between preview and print elements and cannot automatically solve the problems with consistency in the print process.
  • the system should eliminate the various sources of error described above.
  • the system should differentiate between print and preview jobs in order to speed user interaction.
  • the system should allow the user to freely edit and preview the desired print job in a fast and efficient manner.
  • a single, consistent output file should be produced for use by a printer, or other output or processing destination.
  • 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.
  • the present invention utilizes a single electronic file format, or a "Print Ready File” (PRF) format, that can be used at all stages of the process.
  • PRF Print Ready File
  • This format provides the ability to tag certain elements to indicate whether they should be included in the preview layout, the print layout, or both.
  • PRF Print Ready File
  • the software programs that read and process the information check these tags to determine the exact content required at that stage.
  • the Print Ready File has each element precisely mapped. Because no human is required to alter it, the data for the product and the location of its elements need not change. This eliminates a large source of human error.
  • the present system uses the PostScript language (or its equivalents), the present system does not necessarily need to employ commercial page layout software.
  • the present system allows the font and graphic information to be embedded directly into the file. This eliminates errors, including for instance the font and graphic substitution errors common to the traditional process.
  • the present solution allows the creation of a single file that contains all of the data needed for the entire process.
  • the file that the customer previews is the same file that is sent to the vendor (or ultimately the printer). This leads to consistency throughout the life of a print order, and provides for extremely low error rates overall.
  • an Internet site is built to provide a printing service embodying the present invention. Once the Internet site is set up. the customer can modify, order, proof, and control its printed and graphic materials.
  • the solution provided by the present invention eliminates the back and forth process between the customer and the printer. Additionally, the present invention bypasses the printer's customer service and
  • Prepress processes (i.e. human intervention processes) altogether.
  • the sequence of events is (in a generalized manner) as follows: (1) The customer inputs the data on the Internet site of the present invention. (2) The customer approves the proof on-screen. (3) The document is sent as a single PostScript-language file (or its functional equivalent) directly to the printer. (4) The printing plate is made from the digital file. As a result, the printing process is simpler, faster, and less prone to error, resulting in printed business materials that conform according to the customer ' s corporate specifications.
  • the aforementioned single file — or Print Ready File — contains line elements, text elements, and/or graphical elements.
  • Each file is assigned a global flag with states for indicating whether a print or preview operation should be performed on the Print Ready File.
  • Each element is assigned a state flag with states such as print, preview, both (or none) for indicating which operations should be performed on the individual elements within the file. The user is provided the ability to set these state flags for each element.
  • Processor-based comments are used, which are generally processed only during print operations.
  • the file utilizes a different method for accessing graphical elements.
  • a preview operation embeds the graphical element directly in the file, with a link to a blank graphical file.
  • a print operation embeds a blank graphical element, and provides a link to an external file with the graphical element.
  • a "both" operation embeds a low resolution graphical element in the file for preview operations, and provides a link to a high resolution graphical element for print operations.
  • the Print Ready File can be kept to a more manageable size, and yet still use whatever graphical elements are necessary to complete any particular operation.
  • Still another aspect of the present invention provides for a database with various rules for completing a customer's order.
  • the rules are developed for a particular user's printing needs and are used to properly define the end Print Ready File result.
  • Various assets pertaining to the customer i.e. logos and such
  • Figure 1 illustrates a representative prior art block diagram of certain steps found in a traditional print job ordering process.
  • 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 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 system.
  • Figure 4a 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 5a illustrates, according to one aspect of the present invention, a basic data construct of certain elements of a Print Ready File.
  • Figure 5b illustrates, according to one aspect of the present invention, a flowchart of the global flag comparison logic referred to in Figure 5a.
  • Figure 5c illustrates, according to one aspect of the present invention, a representative construct of certain elements of a Print Ready File when the "preview" state flag is set on the graphic element shown.
  • Figure 5d illustrates, according to one aspect of the present invention, a representative construct of certain elements of a Print Ready File when the "print" state flag is set on the graphic element shown.
  • Figure 5e illustrates, according to one aspect of the present invention, a representative construct of certain elements of a Print Ready File when the "both" state flag is set on the graphic element shown.
  • Figure 6 illustrates, according to one aspect of the present invention, a resulting preview to the user of a sample product, e.g. a business card.
  • Figure 7 illustrates, according to one aspect of the present invention, the representative business card of Figure 6 after the imposition stage.
  • Figure 8a illustrates, according to one aspect of the present invention, a first representative color separation of the business card of Figure 6.
  • Figure 8b illustrates, according to one aspect of the present invention, a second representative color separation of the business card of Figure 6.
  • Figure 8c illustrates, according to one aspect of the present invention, a third representative color separation of the business card of Figure 6.
  • Figure 9 illustrates, according to one aspect of the present invention, a representative flowchart of the overall process.
  • Figure 10 illustrates, according to one aspect of the present invention, further representative steps comprising the "customer setup" element of Figure 9.
  • Figure 1 1 illustrates, according to one aspect of the present invention, further representative steps of the "create PRF (composition)" element of Figure 9.
  • Figure 12 illustrates, according to one aspect of the present invention, further representative steps of the "generate preview file” element of Figure 9.
  • FIG. 13 illustrates, according to one aspect of the present invention, further representative steps of the "imposition" element of Figure 9.
  • FIG 14 illustrates, according to one aspect of the present invention, further representative steps of the "color separation" element of Figure 9.
  • Figures 15A and 15B illustrate a computer system suitable for implementing embodiments of 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 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 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
  • 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. If 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 "released” order. (Some customers wish for all of their orders to be stored in a holding queue so that an administrator may grant them final approval. These are considered “pending" orders. Once the administrator grants final approval, the "pending" order is marked as a "released” order.)
  • FIG 400 A block diagram 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.
  • ILIAD Image Logic Information Database
  • the general data composition of ILIAD 410 is further described in Figure 4a.
  • the elements shown are meant to be illustrative, and are not meant to limit the data structure of ILIAD to such elements.
  • 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 Oniine Printing Center) database 490 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.
  • the Farm 414 is generally comprised of at least one. and usually several, high powered computers (e.g. a PC 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. Time estimates can also be provided regarding the processing of jobs.
  • 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, with load balancing of the job processing managed there.
  • the completed PRF 416 is thereafter passed onto the Asset Management File Server (AMFS) 418.
  • AMFS Asset Management File Server
  • 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 Pre-press 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.
  • 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.
  • Resulting features of the present invention include, but are not limited to, the following: (1) The system or site contains all of the data the customer needs in order to print the customer's materials. (2) Data are completely secure and is the property of the customer. (3) The system or site incorporates rules to ensure that no matter what party might happen to input data, the resulting printed materials are printed in a manner consistent with the corporate image and design policies that have been approved. (4) The system or site incorporates a variety of business logic, including procurement, authorization security and billing rules defined by the Company. These rules often set up an authorization process whereby an employee puts in an order and it is routed to the authorized party. The purchasing administrator might then release the particular order to be sent to the printer.
  • PRINT READY FILE In order to accommodate the "state" of the file (e.g. Print or Preview), a global numeric variable, or "flag", is used to indicate which elements will image when this file is processed.
  • this flag is a PostScript integer and will be used for bitmasking each of the state flags of the individual elements.
  • Each element has four possible states: Print, Preview, Both, and none.
  • This global flag is written into the PostScript stream such that an application can find the position of the flag within the file, and alter the value as needed.
  • the default or original value of the flag will be set to include elements that are in a Preview or Both state. It is a unique and efficient aspect of this invention that a single flag may be used. However, alternative embodiments might use multiple flags, comparative elements, or runtime logic to evaluate the appropriate state and direct processing, all within the spirit of the invention.
  • the Line and Text elements will each check their respective state flag against the global flag to see if their bit values are contained within the global flag, using a standard bitmasking technique of a logical AND operator. If the elemental state flag bits are not within the global flag (a zero result from the logical AND), a function is utilized to move the PostScript interpreter's file pointer past the end of that particular element. The element is thereby skipped, and the element does not image (see. e.g., Figure 5b below). Embedded graphics will use a different method than Line and Text elements for selecting Print. Preview, and Both states. When writing a graphic with a state of Preview, the graphic is embedded in the file, but OPI comments are used to link to a blank PostScript file.
  • the blank PostScript file is used instead of the Preview one that is embedded within the file.
  • a blank PostScript file is embedded, and OPI comments are used to link to the graphic.
  • the graphic is embedded with no OPI.
  • One purpose of the present system is to create a file that is relatively small, thereby enhancing speed in working with the file.
  • the OPI comments are used to facilitate a solution.
  • the low-resolution version of the graphic is embedded in the file, and the OPI comments are used to link to the high-resolution version.
  • the low-resolution graphic is seen.
  • the high-resolution file is used.
  • the programs used for creating Previews of the PostScript file are preferably configured to remove the OPI comments.
  • the programs that utilize the PostScript file in a Print state should preferably be configured to process the OPI comments.
  • OPI links to external documents are important features.
  • each of the externally referenced files need not change. This is implemented, in part, by securing the directory where the graphics reside, and using operating system security. Only applications controlled by the present system might be used to add files to this directory. These applications might not allow the modification or deletion of any of these files, but only the adding of new files. In this manner the externally referenced files are secured such that they cannot be altered by accident, or on purpose. They can also be secured by access codes or authorization, as between print and preview modes.
  • a global flag 502 is used to indicate which elements can print. This flag is numeric and is used to apply a bitmask to the elements. For example the value “0 1 " indicates that the elements only in the "Preview” state will not print, while those in "Print” state should be printed. In this example, it is shown as a 32-bit PostScript integer. Additionally, shown is a text element 504. a line element 506. and a graphical element 508. Each text and line element has associated with it four "states”: Print, Preview, Both, and none. However, the graphical element does not use the "none" state. Preferably, these states of an element are represented in a 32-bit integer, similar to the global flag, termed a "state” flag.
  • the text and line elements 504 and 506 will each check their respective state flags against the global flag to see if they should be imaged. If the text or line element state flag does not match with the global flag, then the present invention will apply a routine of PostScript operators to move the interpreter's file pointer past the end of the element in question, thereby skipping that element such that it does not image. For example, if text element has its "Preview” bit set, it would still not be imaged during a preview unless the "Preview” bit of the global flag was also set.
  • This routine hereafter referred to as "Global Flag Comparison Logic" is shown encompassing the text element 504 with a start function 510 and an end function 512.
  • FIG. 5b shows a flowchart 520 of the Global Flag Comparison Logic.
  • Process 522 shows that for each text and line element, the state flags of the element are compared to the global flag in 524. If the global flag matches the state flags, then the element is processed in 526. If the global flag does not match the state flags, then the element is not processed. The preferred embodiment skips the element by moving the pointer past the element via a PostScript routine. The Global Flag Comparision Logic then loops back via 528 until each element is completed.
  • Embedded graphic elements will use a different method depending upon the setting of the Print, Preview, and the Both state flags.
  • the Print Ready File is being passed from point to point. In general, it is desired to keep the size of the Print Ready File down to a minimum for certain operations, thereby increasing the efficiency of the overall system. This is done by directly embedding a low resolution graphical object into the file for preview operations. For print operations, the preview graphic is removed and a link to a high resolution graphic is supplied instead. When the flag is set for "both,” then a low resolution graphic is embedded in the file, and a link is provided to a high resolution graphic.
  • Figure 5c shows the elements of a representative Print Ready File structure 530
  • the Preview flag is set for the graphic element 508.
  • the file 530 uses Open Prepress Interface (OPI) comments 532 (shown as OPI start) and 534 (shown as OPI end) which are placed around the embedded graphic element 533, and an OPI link 531 to a blank extended PostScript file 536.
  • OPI Open Prepress Interface
  • the process of OPI takes an embedded EPS file and replaces it with an external EPS file. This replacement is done by software which processes the OPI comments. If a PostScript processing software (such as the one used for previewing a file) does not process OPI comments, then the embedded EPS files are viewed.
  • the present system utilizes a property of the OPI code — which generally needs to find a link to a high resolution graphic (blank or otherwise).
  • the OPI comments are thereby generally used for designating preview and print EPS files. It should be noted that other "comment code” or the like, could also be used to direct the workflow.
  • Figure 5c again shows a preview mode example. If an EPS file is set for preview, then it is embedded directly in the PostScript file. A link is still provided for the OPI code - - however, this link is to a blank file. Hence, a preview operation (when "preview" of the global flag is set) will show the embedded graphic element. However, when using this file during a print operation (where the OPI is processed), the blank PostScript file is used instead of the preview graphic element 533 that is embedded within the file. In this fashion, the preview EPS image is removed from the final printed image. For a print operation, an opposite tactic is performed. A blank EPS file is embedded in the Print Ready File, with an OPI link to the actual print EPS file. When previewing, no print image is shown.
  • Print Ready File structure 550 (with certain similar elements numbered as per Figure 5b).
  • the print flag is set for the graphic element.
  • a blank PostScript graphic element 556 is embedded in the file.
  • the OPI comments 552 (start) and 554 (end) are used via the OPI link 558 to link to the graphic 560.
  • the printed graphic is shown as the print EPS file 560.
  • Figure 5e shows a representative Print Ready File structure 570 (with certain similar elements numbered as per Figure 5b).
  • the Both flag is set on the graphic element 576.
  • two files are used, a low resolution file and a high resolution file.
  • the low resolution graphic element 576 is embedded directly in the file structure 570.
  • An OPI link 578 is used to link to an external high resolution EPS file 580.
  • the OPI start 572, OPI end 574, and linking comments there between facilitate this linking operation.
  • the file for Preview the low-resolution graphic is seen (as the OPI comments are not processed).
  • the high-resolution file is used, as the high resolution EPS file is linked in per the processed OPI comments.
  • the preferred embodiment would use programs for creating Previews of the PostScript file that are configured to remove the OPI comments.
  • the programs used for processing the PostScript file in a Print state should preferably be configured to process the OPI comments.
  • the global flag will be written into the PostScript stream such that an application can find the position of the flag within the file, and alter the value for its present needs.
  • the default or original value of the flag will be set to include elements in that are in a Preview or Both state.
  • This state can be added to a current system that is used to create printing products, or integrated with, or translated from, systems in which the state is static, or in which it is set by program logic.
  • the user will be able to select the state for each element within the product.
  • the application creating the PostScript file will then need to use the provided state for comparison against the global flag.
  • FIGS. 8 and 8c show the respective color separations 810, 820, and 830 for the preview file (also further described below).
  • Embedded graphics that were in a Print state are now visible. For instance, two embedded graphics might show up on separations called emboss (830) and deboss (820). These two separations are used for creating special dies that make impressions in the final printed product, such that it either "sticks out"
  • PRINT PRODUCTION PROCESS FLOW In order to take advantage of the unique data in the Print Ready File format, certain applications are needed. The applications have knowledge of the format, and are capable of utilizing the data contained therein. Different PRF applications are used at different stages of the print production process. Below, an overall flow of the process steps are first described. Thereafter, certain stages of the print production process are described in further detail. While described as flowchart steps, it is generally recognized that persons of ordinary skill in the art will recognize how to implement such applications from the flowchart descriptions.
  • FIG 9 shows an overall flowchart 900 of the print production process.
  • the user first provides business information to a person responsible for setting up the user account. This first step involves considerable human interaction, but the step generally needs to be done only once in order to properly set up the account. Such information might relate to: purchase orders, authorizations, employee information, employee lists, product styles, style guides, samples, graphical information and fonts. Products would include items such as business cards, envelopes, stationery and the like.
  • Step 904 involves a customer setup application, wherein the elements within a business card or product are defined and stored. Customer setup 904 is described in further detail in Figure 10.
  • Step 906 involves the customer providing information regarding the product by using the customer website referred to in Figure 10.
  • composition step in 908 Composition creates the Print Ready File according to steps further detailed in Figure 1 1.
  • the user will request a preview file in step 910 in order to view the results on-screen before printing.
  • the steps involved in the generation of the preview file are further described in Figure 12.
  • the decision block 91 1 sends the user back to step 906 if further changes are desired. If the preview file is acceptable, then the order is placed in step 912. Thereafter, the process of imposition (or batching and plating) of the PRF is performed in step 914.
  • the imposition steps are further described in Figure 13.
  • Color separation 916 is next performed, with steps described in further detail in Figure 14. Color separation produces color separation plate files which are transported to the print vendor in step 918.
  • Step 920 shows the processing of the color separation plate file by submitting the file to a Raster Image Processor (RIP).
  • the RIP generally produces a bitmap file which is converted into the printed product 922.
  • the product is thereafter shipped to the customer in step 924.
  • Figure 10 shows certain more detailed steps associated with the customer setup application 904 from Figure 9.
  • product setup software is used to create each of the basic elements, and associate a state flag with each one. This software therefore identifies the position, size, contents, etc. of each element type.
  • Step 1002 is the process of determining the printing requirements of a product. This is generally done via a human specialist interacting with the customer to gather and generate graphic and textual materials pertaining to that customer.
  • Step 1004 next is the performance of the Prepress process. This typically consists of generating and verifying the customer assets (e.g. EPS files and fonts). These assets are then added to the Asset Management File Server (AMFS 418 as per Figure 4), or other such database.
  • AMFS 418 Asset Management File Server
  • An EPS is a file format used in Prepress operations, and generally contains information required to create a printed document containing graphics images. Along with the imaging bits. EPS files contain other data respecting reproduction of the image for digital display, or for print, such as color selections, color settings, scaling of graphics, embedded fonts and so forth. Such files often need to be "Washed” or converted into a consistent format for automated processing. Washing is one of several Prepress operations that can be automated by hosting the application on a server, or other networked computer, and maintaining control of certain operations as part of a distributed Prepress software operation.
  • Prepress operations that can be automated (in a similar fashion) include, but are not intended to be limited to. creation of Print Ready Files, trapping, color separation, and imposition of Print Ready Files.
  • step 1006 the user is further prompted for information regarding the product, as might be needed for a particular print job.
  • Step 1008 shows the process of defining the composition rules for each of the particular elements.
  • Step 1010 further shows that for each element, the x, y, and z position of the element in the product is defined.
  • step 1012 a type and state is assigned to each element. The "type” includes line, text, and graphical, whereas the "state” includes Preview. Print, Both, or none.
  • Step 1014 next shows the assignment of various other properties (as needed) to each of these elements. Once finalized, this information is stored via step 1016 in the rules database (or ILIAD 410 as per Figure 4).
  • a customer website is created in step 1018.
  • the customer accesses the website to provide various customer information.
  • the user is prompted for information in step 906.
  • Text elements might require a prompt, in that the user is providing textual information in response to a question.
  • Line and graphical elements might be retrieved directly from the appropriate database via a locator, index, or the like.
  • the Print Ready File in the preferred embodiment follows PostScript conventions including, for instance, DCS standards, platform independent operators, and color separation functions.
  • the file might also include a bounding box, which is not required for a multi-page PostScript file, but might be used by other applications in the process to identify the size of the image to be rendered.
  • step 1 102 the web server (408) requests the PRF from the Farm (414), along with related user information.
  • step 1 104 the rules regarding the product setup are read from the ILIAD (410) database.
  • the global flag is next written into the PRF with a default setting of "Preview" as shown in step 1106.
  • a loop is then performed for each element of the product 1108.
  • the element information is retrieved, e.g. data source, component data, and state. Based upon this information, and the logic described above, the element is written into the PRF in step 1112.
  • the loop continues via link 1114 until each element of the product is completed and written into the PRF.
  • the PRF is stored in the Asset Management File Server (418).
  • An alternative embodiment could substitute receipt of one or more data streams in response to the web server request in step 102, as with XML output from one or multiple machines performing the required pre-press operations. The rest of the operations described proceed as depicted.
  • a preview file is generated as will now be explained, and then summarized in Figure 12.
  • An example preview image of a business card is shown in Figure 6. Since PostScript is a page description language, a PostScript interpreter is used to process the Print Ready File which is generated in PostScript. In order to preview such, the Print Ready File is preferably first interpreted and then rasterized.
  • Rasterizing is the process of interpreting the PostScript file and converting it into raster image data, or pixels for a bitmapped image. As the target audience is a human previewer, it is desired to convert the Print Ready File to a format that will allow the user to view the data.
  • the process of rasterizing PostScript fixes the image into a static bitmapped image.
  • One drawback of this format is that the static image does not allow for "zooming" operations. In other words, the static image also does not allow for greater detail at higher zoom factors, since the image is already a fixed bitmapped resolution.
  • One preferred embodiment therefore uses a format that supports vector images and can be selectively scaled and rasterized on the fly when presenting the data to a user.
  • PDF is an example of a format that allows for rasterization on the fly by using a vector source file (with the option of embedded pre- rasterized images).
  • a PDF file can be created directly, or by using tools which convert PostScript to PDF. Adobe's Acrobat Distiller is an example of one such tool. The settings on these tools are an important consideration. With the present implementation of OPI, the OPI comments should be stripped out, particularly since a preview is being created. All preview graphics are embedded in the file, and should pass through without OPI replacement, or external links. Because PDF is a page description language that is devoid of logic, all of the related state flags are processed in the creation of the PDF file. Distiller has a PostScript interpreter built in. and instead of rasterizing the PostScript, it generates PDF operators. Since it is a PostScript interpreter, it can process each element using the aforementioned Global Flag Comparison Logic (see Figure 5b)
  • settings are also important for the creation of a preview PDF file. These settings include, but are not limited to: raster image compression, raster image downsampling, and font subsetting.
  • raster image compression many embedded graphics contain both vector and raster data, and since the goal is to have a very small preview file, it is desired to compress the raster image data, but not to the point of distortion.
  • PDF allows for images to use lossy or non-lossy compression schemes.
  • the present system chooses a non-lossy or lossless compression scheme. Lossless compression involves no image information being removed from the file for the sake of compression. Lossy compression removes image information to achieve higher compression rates. Note, however, that lossy compression is an alternative embodiment appropriate if high assurance of image quality is not an issue for the customer or nature of the printed document, and in the case of electronic display of images, is of little consequence by comparison to limits on display resolution.
  • each embedded graphic element might be created via some form of setup software that allows the user to downsample the image.
  • Downsampling takes the file and converts it to a lower resolution. This process can distort images, by reducing the number of pixels in the graphic. Since the present system allows the user of the Product Setup Software to determine the setting, this allows for a maximum of image quality to be retained.
  • Computer display monitors have a significantly lower resolution than imagesetter devices; A standard resolution for monitors is 72dpi, whereas a standard resolution for imagesetter devices is 2400dpi.
  • the image is preferably downsampled on the fly by the PDF reader for display to the user on a monitor. An optimum downsampling will have little affect on the visible quality of the image when viewed on screen.
  • font subsetting Since they contain vector data. PDF files do not rasterize the text when created. Text is rasterized by PDF reader software when displaying the PDF file to a user. Because the rasterization happens when viewing the file, the fonts used by the text need to be included in the file. Fonts are not small, and one aspect of our preview file is its relatively small file size. As a result. Distiller contains options to subset fonts. The basic process of subsetting a font is to remove all characters from the font that are not used in the document. This greatly reduces the size of the font in the file. The present system teaches the use this option for preview files.
  • PDF files There are many other settings for PDF files that can optionally be used. These are not a requirement of the process, but can affect file size and display performance. These options include conversion of CMYK colors to RGB colors, converting Device Independent color spaces to Device Dependent color spaces, and applying transfer functions. Other forms of image management and substitution, such as Kodak Flashpix data structure, could be adopted without changing the basic convention. None of these options, however, detract from the desired features of the Print Ready File. The present system might also use a bitmapped preview implementation. There are many products on the market for creating bitmaps from PostScript files, and most fall into the category of a Software RIP. One such product is Image Alchemy by Handmade Software, Inc.
  • FIG. 12 a flowchart is shown of representative steps associated with the element "generate preview file” 910 from Figure 9.
  • Figure 4 elements when referenced, are shown in parenthesis.
  • the web server (408) requests a preview file from the Farm (414) as shown in step 1202.
  • the Farm retrieves the PRF from the Asset Management File Server (418) in step 1204.
  • the Farm sets the global flag in the PRF to preview mode in step 1206.
  • the Farm converts the PRF to a preview file. This is done via a PostScript interpreter which results in common image formats using the Global Flag Comparison Logic (and the OPI comments). Common image formats include, for instance, bitmap and PDF.
  • the preview file is thereafter sent to the web server (408).
  • the user accesses and views the preview file via a web browser or the like.
  • the global flag within the Print Ready File is changed to one representing Print only. Once the flag is flipped, the file is ready to be imposed into a file with many other such Print Ready Files.
  • Imposition software takes several PostScript files and creates a single file with all "imposed" files embedded, adding crop marks, registration marks, and the like.
  • Figure 7 shows a representative example. Regarding this image, a few things should be noted: the text is still there; there are crop marks on the top left, top right, bottom left, and bottom right; the word Composite is describing the type of image as opposed to a color separated view; the logo has changed. What is shown is comprised of two embedded graphics on top of each other, each one for a different purpose, as shown during Color Separation.
  • the color separation phase takes the imposed, OPI processed file, and generates "separations". Separations are either represented in a single file, or multiple files.
  • One software implementation which might be used includes Preps by ScenicSoft which generates a single file with all "separations" therein. This is the final stage of the PostScript file prior to being processed on a RIP. Accordingly, all necessary settings for the destination RIP are specified in this stage.
  • the destination device is provided to Preps, which uses an Adobe PPD file to generate commands so that the destination device can understand the settings for page sizes, emulsion, polarity, and other such options.
  • the PPD file is a file provided by the Imagesetter vendor that provides all the details necessary to generate a device-specific file. As further described above.
  • Figures 8a-8c show the color separation stages of an example file.
  • the aforementioned color separation software has an option to deal with missing fonts. Since the Print Ready Files according to the present invention should contain all the fonts necessary to produce the file, this option to supply fonts is turned off.
  • a PostScript file format is altered and used to store additional information about a product which allowed the system to use that file in all stages of the production process.
  • Alternate implementations could use a different file format to achieve this goal.
  • the system might use the Portable Document Format (PDF) to store this information.
  • PDF is similar to PostScript in many respects, and could easily be modified to fulfill the objectives of the present invention.
  • the original PostScript solution could also be programmed in other ways to provide slightly different solutions.
  • the primary implementation describes the addition of order data to the Print Ready File in text format. It is possible to add this data to the file in a format such as XML (extended markup language). This is a format that allows a document to contain both data and a description of that data. XML would allow the data to be read and processed by any number of external databases, viewers, web browsers, and other such applications. A file with this information could be seamlessly integrated into the system to provide printing, billing, and shipping services automatically, based solely on the content of the consistent PostScript file, as referred to as the Print Ready File above.
  • XML is a derivative of SGML (Standard Generalized Markup Language).
  • the system could be programmed to detect if and when certain portions of the file were no longer needed. If such a situation were detected, the system could send the Print Ready File through a preprocessor, which would cut out the unneeded portions of the file and send the remainder to its destination. Note that the original Print Ready File would still be maintained on a central server. The server would be responsible for figuring out when and where it would be safe to send smaller files. This would still maintain the consistency provided by the original Print Ready File; the system is merely reducing the amount of data it transmits for optimal efficiency.
  • the Print Ready File can be sent to a digital proofing device and/or a computer screen that has been optimized for color correctness. The same file can then be sent to a high-resolution imaging device for creation of the plates or directly to a digital press.
  • the vendor system might be configured to automate this process based on the content of the Print Ready File. Previously, the possibility was raised of a format whose tagging scheme allowed many different states. As an example of how this might prove to be useful, an advanced online ordering system is considered.
  • This system provides a user with the ability to select one imprint (e.g., a company logo or advertisement) and then choose to have that imprint imaged on a number of different products at once (e.g., posters, coffee cups, T-shirts, embroidered hats, etc.). It is possible that different products might require slightly different versions of the imprint image. For example, an embroidery machine might not be able to display complicated gradients, so it might require a version of the image in which gradients have been converted to blocks of solid color.
  • the Print Ready File could contain all of the image versions required for all of the products.
  • the order might contain a list of all of the products that are to be produced, and as the printing system imaged the order for each product it might get the appropriate image data from a single Print Ready File.
  • a similar workflow might be used in a publishing scenario.
  • a customer might want to produce copies of a document both on paper and on a CD-ROM.
  • the product would use different images and different production information, but might also use a completely different production method or vendor.
  • the system might read the tagged information in the file and send one job to the press to be printed and another job to a CD production house to be pressed onto a CD.
  • the number of products that could be manufactured using this system are numerous. For example, virtually any printed item could be created, including but not limited to: coffee mugs, T-shirts, hats, embroidered clothing, magnets, mirrors, toys, and any form of digital output display, and so forth.
  • FIG. 15A shows one possible physical form of the computer system.
  • the computer system may have many physical forms ranging from an integrated circuit, a printed circuit board and a small handheld device up to a huge super computer.
  • Computer system 1500 includes a monitor 1502. a display 1504, a housing 1506, a disk drive 1508, a keyboard 1510 and a mouse 1512.
  • Disk 1514 is a computer- readable medium used to transfer data to and from computer system 1500.
  • FIG. 15B is an example of a block diagram for computer system 1500. Attached to system bus 1520 are a wide variety of subsystems. Processor(s) 1522 (also referred to as central processing units, or CPUs) are coupled to storage devices including memory 1524. Memory 1524 includes random access memory (RAM) and read-only memory (ROM). As is well known in the art, ROM acts to transfer data and instructions uni-directionally to the CPU and RAM is used typically to transfer data and instructions in a bi-directional manner. Both of these types of memories may include any suitable of the computer-readable media described below. A fixed disk 1526 is also coupled bi-directionally to CPU 1522; it provides additional data storage capacity and may also include any of the computer- readable media described below.
  • RAM random access memory
  • ROM read-only memory
  • Fixed disk 1526 may be used to store programs, data and the like and is typically a secondary storage medium (such as a hard disk) that is slower than primary storage. It will be appreciated that the information retained within fixed disk 1526, may, in appropriate cases, be incorporated in standard fashion as virtual memory in memory 1524.
  • Removable disk 1514 may take the form of any of the computer-readable media described below.
  • CPU 1522 is also coupled to a variety of input/output devices such as display 1504, keyboard 1510, mouse 1512 and speakers 1530.
  • an input/output device may be any of: video displays, track balls, mice, keyboards, microphones, touch-sensitive displays, transducer card readers, magnetic or paper tape readers, tablets, styluses, voice or handwriting recognizers, biometrics readers, or other computers.
  • CPU 1 22 optionally may be coupled to another computer or telecommunications network using network interface 1540. With such a network interface, it is contemplated that the CPU might receive information from the network, or might output information to the network in the course of performing the above-described method steps.
  • method embodiments of the present invention may execute solely upon CPU 1522 or may execute over a network such as the Internet in conjunction with a remote CPU that shares a portion of the processing.
  • embodiments of the present invention further relate to computer storage products with a computer-readable medium that have computer code thereon for performing various computer-implemented operations.
  • the media and computer code may be those specially designed and constructed for the purposes of the present invention, or they may be of the kind well known and available to those having skill in the computer software arts.
  • Examples of computer-readable media include, but are not limited to: magnetic media such as hard disks, floppy disks, and magnetic tape; optical media such as CD-ROMs and holographic devices; magneto-optical media such as floptical disks; and hardware devices that are specially configured to store and execute program code, such as application-specific integrated circuits (ASICs), programmable logic devices (PLDs) and ROM and RAM devices.
  • Examples of computer code include machine code, such as produced by a compiler, and files containing higher level code that are executed by a computer using an interpreter.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Business, Economics & Management (AREA)
  • Human Computer Interaction (AREA)
  • General Engineering & Computer Science (AREA)
  • Accounting & Taxation (AREA)
  • Development Economics (AREA)
  • Finance (AREA)
  • Strategic Management (AREA)
  • Quality & Reliability (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Game Theory and Decision Science (AREA)
  • Economics (AREA)
  • Marketing (AREA)
  • General Business, Economics & Management (AREA)
  • Record Information Processing For Printing (AREA)

Abstract

L'invention concerne un système et une structure de fichier produisant des éléments de support visuel avec rapidité et régularité. Habituellement, le support visuel est un objet imprimé, tel qu'une carte professionnelle, provenant d'un fichier qui contient des éléments textuels, linéaires et graphiques. Un fichier unique est compilé, et toutes les opérations sur le fichier peuvent ainsi être effectuées sur la base des informations qu'il contient. Un drapeau d'état est associé à chaque élément, ledit drapeau comprenant des états tels que la prévisualisation, l'impression, ces deux états ou aucun des deux. Un drapeau global comprenant des paramètres, tels que la prévisualisation et l'impression, est également utilisé. Les éléments individuels contenus dans le fichier peuvent être mis en image ou imprimés selon leurs paramètres de drapeau d'état individuel, par opposition aux paramètres de drapeau global. Les fichiers contenant les éléments graphiques peuvent inclure un élément graphique ou fournir un lien menant à un élément extérieur au fichier selon l'opération souhaitée (impression ou prévisualisation, par exemple). Pour procéder à une prévisualisation, l'élément graphique est inclus dans le fichier. Pour procéder à une impression, le système fournit un lien menant à un élément graphique stocké à l'extérieur. Pour effectuer les deux opérations à la fois, le système fournit un graphique à basse résolution inclus dans le fichier et un lien menant à un graphique à haute résolution. Ces liens sont obtenus à l'aide de commentaires (ou de codes) d'interface de pré-presse ouverte, entre autres, autour de la forme des éléments graphiques dans les fichiers.
PCT/US2000/010456 1999-04-30 2000-04-18 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'impression WO2000067153A1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
AU44690/00A AU4469000A (en) 1999-04-30 2000-04-18 System and file structure for supplying to an internet customer both a preview and a final print from the same print specification file

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
US13171699P 1999-04-30 1999-04-30
US60/131,716 1999-04-30
US46030799A 1999-12-13 1999-12-13
US09/460,307 1999-12-13

Publications (1)

Publication Number Publication Date
WO2000067153A1 true WO2000067153A1 (fr) 2000-11-09

Family

ID=26829729

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2000/010456 WO2000067153A1 (fr) 1999-04-30 2000-04-18 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'impression

Country Status (2)

Country Link
AU (1) AU4469000A (fr)
WO (1) WO2000067153A1 (fr)

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1845700A1 (fr) * 2006-04-10 2007-10-17 Pixyfoto AG Procédé et dispositif destinés à la préparation de la création de reproductions photographiques
US7383864B2 (en) 2002-04-03 2008-06-10 3M Innovative Properties Company Radio-frequency identification tag and tape applicator, radio-frequency identification tag applicator, and methods of applying radio-frequency identification tags
US20140092438A1 (en) * 2012-09-28 2014-04-03 Interactive Memories, Inc. Method for Optimizing Printing Quality for Image-Laden PDF Files at Lower File Sizes
JP2015001946A (ja) * 2013-06-18 2015-01-05 コニカミノルタ株式会社 情報処理装置、プリンタドライバおよびプログラム

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0537391A1 (fr) * 1991-10-04 1993-04-21 Moore Business Forms, Inc. Système de commande de formulaires par ordinateur
EP0782068A1 (fr) * 1995-12-29 1997-07-02 Deluxe Corporation Système d'impression à distance
WO1998008176A1 (fr) * 1996-08-20 1998-02-26 Moore Business Forms, Inc. Systeme d'epreuves recourant a la technologie dynamique pdf comme interface d'impression modelisee
EP0837401A2 (fr) * 1996-10-16 1998-04-22 SCITEX DIGITAL PRINTING, Inc. Méthode de création de mise en page complexe avec des données variables pour des systèmes d'impression à grande vitesse

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0537391A1 (fr) * 1991-10-04 1993-04-21 Moore Business Forms, Inc. Système de commande de formulaires par ordinateur
EP0782068A1 (fr) * 1995-12-29 1997-07-02 Deluxe Corporation Système d'impression à distance
WO1998008176A1 (fr) * 1996-08-20 1998-02-26 Moore Business Forms, Inc. Systeme d'epreuves recourant a la technologie dynamique pdf comme interface d'impression modelisee
EP0837401A2 (fr) * 1996-10-16 1998-04-22 SCITEX DIGITAL PRINTING, Inc. Méthode de création de mise en page complexe avec des données variables pour des systèmes d'impression à grande vitesse

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
"BUILD-A-CHECK", IBM TECHNICAL DISCLOSURE BULLETIN,US,IBM CORP. NEW YORK, vol. 34, no. 6, 1 November 1991 (1991-11-01), pages 32 - 33, XP000228340, ISSN: 0018-8689 *

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7383864B2 (en) 2002-04-03 2008-06-10 3M Innovative Properties Company Radio-frequency identification tag and tape applicator, radio-frequency identification tag applicator, and methods of applying radio-frequency identification tags
EP1845700A1 (fr) * 2006-04-10 2007-10-17 Pixyfoto AG Procédé et dispositif destinés à la préparation de la création de reproductions photographiques
US20140092438A1 (en) * 2012-09-28 2014-04-03 Interactive Memories, Inc. Method for Optimizing Printing Quality for Image-Laden PDF Files at Lower File Sizes
US8879112B2 (en) * 2012-09-28 2014-11-04 Interactive Memories, Inc. Method for optimizing printing quality for image-laden PDF files at lower file sizes
JP2015001946A (ja) * 2013-06-18 2015-01-05 コニカミノルタ株式会社 情報処理装置、プリンタドライバおよびプログラム

Also Published As

Publication number Publication date
AU4469000A (en) 2000-11-17

Similar Documents

Publication Publication Date Title
US6396593B1 (en) Postscript to bitmap conversion of graphic image files
US6429947B1 (en) Automated, hosted prepress application
US6353483B1 (en) Postscript to bitmap conversion of graphic image files
US6381032B1 (en) Postscript to PDF conversion of graphic image files
US6771384B1 (en) Imposition of graphic image files
US6362895B1 (en) PDF to PostScript conversion of graphic image files
US6559966B1 (en) Trapping of graphic image files
US8438476B2 (en) Dynamic variable-content publishing
JP5828497B2 (ja) 印刷ジョブを処理するシステム及び方法
US6633890B1 (en) Method for washing of graphic image files
US20040227960A1 (en) Electronic printing system and method
US20060023238A1 (en) Select reprint of records in variable data printing
US20060259590A1 (en) Online printing service system on the Internet
US20030160819A1 (en) Interactive print system and method
US20060041839A1 (en) System and method for providing formatted print pages
US20020103826A1 (en) System and method for creating documents populated with variable data
WO2001029695A2 (fr) Modele de mise en page pour la publication
US6903839B1 (en) Apparatus for washing of graphic image files
CA2381328A1 (fr) Systeme et procede de conception automatisee de produits
US20030038972A1 (en) Method and system for preparing printed matter
US20040153332A1 (en) Printed materials procurement system
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'impression
JP2000020607A (ja) 商品を掲載した商品掲載印刷物を電子的に利用する電子商取引システムおよびそのサブシステム
US6556308B1 (en) Color separation of graphic image files
WO2001066349A1 (fr) Systeme et procede d'impression par un click

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BY 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 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: A1

Designated state(s): GH GM KE LS MW 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
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