File conversion system and method

A flexible and scalable file format conversion system is capable of supporting a number of contemporaneous conversion requests. For each file, a conversion request entry and one or more related conversion task entries are maintained in FIFO queues under the control of a distribution manager program. Conversion operations are handled by application programs under the control of associated graphical processor programs. Conversion tasks are assigned to graphical processors by the distribution manager based on the conversion capabilities of the associated application program. The uploaded files received from clients for conversion are stored in a shared folder pending access by the assigned graphical processor. The graphical processors have a uniform interface with the queues and the memory. The results of the processing are stored in the shared folder where they are subsequently accessed by the web server and transmitted back to the client.

FIELD OF THE INVENTION

The invention relates to a system and method for the automated conversion of electronic files.

BACKGROUND OF THE INVENTION

The widespread availability of the World Wide Web and related data processing and communication technologies have created new ways for businesses to market their products and services to their customers. Among the many new businesses that have taken advantage of the capabilities of the Web are printing service providers. These companies typically allow customers to access a web site, download editing tools to the customer's computer, and design custom content to be printed subsequently on products such as documents, clothing, and promotional goods.

One network-based product design system is disclosed in U.S. Pat. No. 6,247,011 entitled “Computerized Prepress”. The patent discloses a downloadable document authoring tool that runs in the client browser. The product created by the client is uploaded to the server where it is processed by a translation program into a prepress file format. Another system is disclosed in co-pending and co-owned U.S. application No. 09/557,571 entitled “Managing Print Jobs”, which is hereby incorporated by reference. The system discloses a downloadable editing tool that allows a customer to create and edit custom materials in the customer's browser.

A company desiring to provide flexible and powerful client/server design services that allow a customer to create custom WYSIWYG products in the client's browser would desirably want to provide the user with both the ability to enter, modify and arrange text in the product being created and the ability to incorporate an existing client file, for example, a design, company logo, photograph, or previously prepared text. Providing these features poses several challenges.

For example, the system should desirably be able to accept files from the customer in various file formats in common use today, such as Microsoft Word, Microsoft PowerPoint, Adobe Acrobat, and Adobe Photoshop, as well as Bitmap, GIF, JPEG, PCX, PICT, PNG and TIF, and automatically perform any necessary file conversions to create one or more preview versions, typically in GIF or JPEG format, for review by the customer and a prepress version, typically in PDF format, for later use in printing the customer's product. A prior art system for receiving files and automatically performing conversions under the control of a master program is disclosed in U.S. Pat. No. 6,429,947 entitled “Automated, Hosted Prepress Application”.

In addition, it is highly desirable during the design process to display to the client an image of the product that is as close to the appearance of the final printed product as possible. This poses the problem of dealing with the inherent incompatibility between the color rendering abilities of a computer monitor and the abilities of the product printing system. As is well known, computer displays are pixel-based systems that render colors using red, green and blue light (RGB). Most printing systems, by contrast, render colors using inks. Offset printing systems, which are frequently used for high quality, high resolution printing of documents, render colors using cyan, magenta, yellow and black (CMYK). While there is substantial overlap between the RGB color gamut and the CMYK color gamut, the two are not identical. There are certain colors that can be rendered on an RGB computer monitor that cannot be produced on a CMYK system and vice versa. In designing a product on the user's computer, it is possible that a file uploaded for the product by the user will contain colors that cannot be accurately produced on an RGB system. When this happens, computer monitor systems will typically select a substitute RGB color in an attempt to approximate the original CMYK color. In some cases, the substitute RGB color is noticeably different from the color of the original image. Similarly, it is possible that the user will upload a file for the product that contains colors that can be rendered accurately in RGB, but cannot be duplicated with a CYMK system. Both of these situations are undesirable because the result would be a final printed product that differs from the colors of the product image that was viewed and approved by the user during the design process.

Furthermore, a computerized product design system that is available to many customers worldwide faces the problems of dealing with many simultaneous product design sessions and with customers who may be using web browsers that lack the dynamic features and capabilities of current state-of-the-art browsers. It is highly desirable that the system be able to accommodate simultaneous users, including users using older or less capable browsers, while retaining the ability to quickly generate and display an image of the product to users in a manner that represents the appearance of the final printed product as accurately as possible.

Finally, a web-based system, if it meets with success in the marketplace, may need to deal with a rapid increase in the demand for its services. If the system becomes overwhelmed to the point that users experience excessive delays or are unable to access the service at all, customer satisfaction will decline and some may seek alternate sources for their product.

SUMMARY OF THE INVENTION

The present invention addresses these and other problems in the prior art by providing a flexible and scalable system that is capable of supporting a number of contemporaneous file conversion requests. For each uploaded file, a conversion request entry and one or more related conversion task entries are maintained in FIFO queues under the control of a distribution manager program. Tasks associated with the conversion are handled by application programs under the control of associated graphical processor programs, which are assigned conversion tasks by the distribution manager. The uploaded files received from clients for conversion are stored in a shared folder pending access by the assigned graphical processor. The graphical processors have a uniform interface with the queues and the memory. Support is provided for older and less capable browsers. The results of the processing are stored in the shared folder where they are subsequently accessed by the web server and transmitted back to the client.

DESCRIPTION OF THE PREFERRED EMBODIMENT

Referring toFIG. 1, a preferred embodiment of a Web-based product design system embodying the invention is shown. Client100accesses web server120via network110. In a preferred embodiment, client100is a typically equipped PC or similar computer, but it will be understood that the invention can be employed with other client devices capable of running browser software, such as palmtop computers, tablet computers and web-enabled telephones. A single representative client100is shown and discussed for illustration, but it will be understood that a number of geographically dispersed clients of different types can be simultaneously in various stages of interaction with web server120via network110. Network110is preferably the Web, but could alternatively be any intranet, extranet, or other network.

Web server120is a computer system having a universal resource locator and adapted to be accessed by clients over network110. While shown inFIG. 1as a single unit, it will be understood that web server120may in fact be comprised of a plurality of individual processors or computers, data storage units, and other equipment, which may be either in the same or in different geographical locations, operating cooperatively so as to provide computational, informational and electronic commerce support to Web users.

When web server120is initially accessed client100, the client is provided with the web site's home page and subsequently may browse though the product offerings. In a preferred embodiment of a custom product creation system, web server120provides client100with images of a variety of product templates from which the client may choose. In a system for designing documents, these would typically include templates for business cards, postcards, letterhead, labels, brochures, or other printed materials. When client100selects a specific template to initiate product creation, Web server120downloads the selected template and design tool102, which in a preferred embodiment will execute in browser101. Design tool102allows the user to enter, arrange and modify text and otherwise create a custom printed product.

To provide the user with the ability to incorporate one or more of the user's pre-existing files into the product being designed, tool102provides a file upload feature. In a preferred embodiment, the user initiates the file upload option by clicking a button having a descriptive legend, such as “Upload an image”. A drop down menu or other well-known selection technique could be alternatively employed. When a user has indicated a desire to upload an image, tool102displays an upload screen to the user. Referring toFIG. 4, the file upload screen displays list401informing the user of the file formats that web site120will accept for uploading. As discussed below, web server120will modify list401from time to time as necessary to reflect the current operational status of the system.

The screen provides name field402for the user to enter the name of the desired file. Alternatively, the user may initiate a search in the client100file system for the desired file by clicking Browse button403. When the desired file has been located, the user initiates the upload to web server120by clicking “Upload your file” button404. For the purpose of this discussion, file103is depicted as residing on client100, but it will be understood that the file could reside on and be retrieved from another computer system or storage device that is accessible by client100. The operation and features of the file upload screen are implemented using well-known capabilities of a modern browser101.

Web server120is in communication with distribution manager program140and with an area of data storage identified as shared folder130. As discussed in more detail below, distribution manager140acts as the central receiving and distribution point for all file conversion tasks and all browser capture tasks. Distribution manager140receives file conversion requests and browser capture requests from web server120and manages the distribution of the requests among a plurality of graphical processor programs (GPs). In the embodiment shown inFIG. 1, three types of GPs are employed, identified as GP150-152. GPs150and151are adapted to retrieve a conversion task from queue142and the associated file from shared storage140, handle the interaction with an associated application program153and154, and store the converted file back in shared folder130. Applications153and154are commercially available programs capable of performing the types of file conversions necessary to support the operation of the system. For example, in a preferred embodiment, application153is an image-editing product, such as Photoshop from Adobe Systems Incorporated. Application154is a word processing and presentation graphics product, such as Office XP from Microsoft.

Preferably, browser101is a recent version of a popular web browser, such as Microsoft Internet Explorer or Netscape, that supports DHTML operations and features. In such a browser, tool102allows the user to dynamically create, edit and view, in the user's browser, the content and components of the product being designed. However, not all Web users have these browsers. Some users are using older browser versions or browsers from vendors that do not provide this support. With browsers that do not support DHTML features, the customer's product creation and editing cannot be rendered on the customer's display by the browser and must, therefore, be processed by the server. Application155is a browser program compatible with browser101and capable of rendering the document being viewed by the user of client100. GP152and application155provide server-side product rendering for customers using browsers that cannot support the rendering capability of tool102in the browser.

The system is designed to be modular, flexible, and scalable. As customer demand for services increases, additional GPs of one or more types can be activated. Similarly, during periods of lesser demand underused or surplus GPs can be deactivated. Each newly activated GP would control another instance of its associated application program. While three types of GPs150-152are shown inFIG. 1, it will be understood that, since all GPs interface with DM140in a standard fashion, additional types of GPs could be readily added to handle the conversion of new or different file formats or to support new or different file conversion applications. For redundancy and improved performance, there preferably are multiple instances of each type of GP and application. In summary, the system can be expanded, both in terms of the types of GPs and the number of GPs within a type, to flexibly accommodate customer demands and the availability of new suitable application programs.

No specific hardware system or structure is required to implement the invention. For example, each GP program could be running on a different computer or multiple GPs could be running on a single computer. The number of computer systems employed in a specific embodiment of the system would typically be a function of factors such as system workload, processing power of the hardware employed, operating system constraints, and the level of hardware redundancy desired. In a preferred embodiment, the distribution manager program140, which is not a heavy consumer of computing resources, is running on a computer system with one of the GPs. Alternatively, DM140could be running on web server120or on a completely different computer system (not shown). Each GP150and151has read and write access to shared folder130. As discussed below, in a preferred embodiment where the XHTML product description is obtained by GP152from DM140and not from shared folder130, GP152has write access to shared folder130, but does not require read access. While shared folder130is depicted as a single block, it will be understood that shared memory130represents a virtual area of addressable memory that may exist on one or more physical data storage devices. It is not required that client file103, thumbnail131, web132and print133be stored in contiguous memory locations or on the same hardware device.

Each GP is checked by a monitor program156to verify that the GP is still actively executing tasks. In a preferred embodiment, monitor156periodically checks for updating of a timestamp by the GP. Other known techniques of activity monitoring could alternatively be employed. If monitor156does not detect the appropriate updating of the timestamp, monitor156assumes that the associated GP is no longer operational. When a failed GP is detected, monitor156instructs the operating system of the computer system on which the GP is running to terminate the failed GP program and start another instance of the GP. WhileFIG. 1shows a monitor156for each GP, this need not be the case in all embodiments. In a preferred embodiment, there would be one monitor156per computer system. If multiple GPs are running on a single computer system, they would all be monitored by a single monitor program156.

DM140is also monitoring the operational status of the GPs. For each GP, DM140monitors the time that has passed since the GP last requested a new task. If the elapsed time for a GP exceeds a maximum time-out value, DM140will treat the GP as having failed and will remove that GP from capabilities143, thereby preventing other tasks in queue142from being assigned to it. DM140will also change the status of any task currently assigned to that GP to make that task available for selection by another GP having the appropriate capabilities. In this manner, a system having multiple GPs of each GP type can sustain a GP failure while still providing support to customers and without loss of or significant delay in completing any task assigned to the failed GP at the time of failure.

If it happens that at the time of failure the failed GP was the only GP performing a particular type of conversion, DM140will notify web server120that the system is unable to process the associated file formats. In response to the notification from DM140, web server120will generate a new file upload screen with the formats that can no longer be converted removed from list401. When the ability to convert those formats is recovered, DM140will notify web server120and web server120will again generate a new screen to restore those file formats to list401.

When the user has selected the desired file and indicated that the user wants the file to be uploaded by clicking button404, browser101will locate and forward the requested file to web server120. Web server120will then initiate the creation of an appropriate Active Server Page (ASP) for transmission back to client100. The processes and procedures for generating ASPs and the transferring of files over the Web are well known in the art.

Before web server120can assemble the page information to display an image of the uploaded file at client100, client file103must be appropriately converted. The file conversion includes both removing any inappropriate colors and generating preview and prepress versions of the file in the appropriate format and resolution. As discussed above, to provide a truly WYSIWYG service to customers, it is important that the product colors displayed to the user on the client100display be as close as possible to the colors rendered on the finished product. The system will, therefore, perform the conversions necessary to replace any color that cannot be rendered on both the client100display and the printing system with the closest suitable approximation of that color. In the disclosed embodiment, regardless of the original colors of client file103, only colors that can be both viewed on the RGB monitor of client100and printed on a CMYK printing system are displayed to the user of client100.

The system will accept uploaded files that may be in RGB, CMYK or possibly another color system and will generate a version in CMYK for subsequent use in printing one and one or more versions of the file in RGB for viewing by the user. In a preferred embodiment, this is accomplished by GP150using application153to first open the file in CMYK, then convert the CMYK version to an RGB version, and then convert the RGB version back to CMYK. Other sequences could also be employed, such as opening uploaded files initially in RGB, then converting to CMYK and then back to RGB. In this way, all colors not reproducible in both color systems are removed before the converted files are stored in shared folder130. This means that in some circumstances the image as ultimately printed will not have precisely the same colors as the original image file that was uploaded the client100, but it has the advantage of insuring that the user is presented during the design process with an accurate image of the finished product and avoids the possibility of user dissatisfaction that could result from showing the user an image of one color and subsequently printing a different color on the final product. If the user is not satisfied with the displayed colors resulting from the file conversion, the user is free to terminate the design process prior to ordering the product.

In a preferred embodiment, three versions of uploaded client file103are created, identified inFIG. 1as thumbnail131, web132and print133. These can be thought of as relatively low resolution, medium resolution and high resolution versions of the client file. Thumbnail131and web132are RGB images designed for viewing on the client100display at a typical resolution of 72 pixels per inch. Thumbnail131is a relatively small image intended for quick file identification and selection. In a preferred embodiment, thumbnail131is sized to be 100 pixels in the longest dimension. Web132is a larger version showing the file image in greater detail. Thumbnail131and web132will typically be stored in JPEG format or, if transparency support is required, in GIF format.

Print133is the CMYK version of the file intended for use in the subsequent printing process, not for viewing by the user of client100. Print133is stored in PDF format at a resolution of 300 dpi. In some cases, the print133file will never be required. For example, a user may decide to modify the image after viewing it or may decide not to complete the product purchase process. To avoid processing that in some cases will turn out to have been unnecessary, instead of performing the complete PDF generation process at this time, print133could contain a preliminary version of the file that is ready for final PDF processing. The generation of the final PDF print version print133could be postponed until a later time, for example until after the user has actually placed an order for the product or until just prior to printing.

Referring toFIG. 2andFIG. 3, the operation of a preferred embodiment of the invention will be discussed. While the following operational discussion addresses the operation of file uploading and conversion involving GPs150and151, it will be understood that substantially similar activities occur when GP152is engaged in a “browser capture” operation. A summary of the operational differences involved in the browser capture operation is given at the conclusion of the following discussion.

As mentioned above, the invention is designed to handle a number of clients contemporaneously accessing server120and submitting file conversion requests. The process for format conversion of a file is depicted inFIG. 3. At step301, the user initiates the uploading of a selected file, in the disclosed embodiment by clicking button404as discussed above. The file is transferred to web server120at step302and stored by web server120in shared folder130at step303. Based on the format of the uploaded file, at step304Web server120then creates, and forwards to DM140, a request entry and one or more tasks entries associated with the uploaded file. Each request entry is stored in first in, first out (FIFO) queue141and contains the information needed to locate the stored file in shared folder130and a unique request ID associated with client100. Each task entry is stored in FIFO queue142and contains an identification of the specific conversion to be performed and a unique task ID associated with the request ID. Some uploaded files may require only a single conversion task and others may require multiple tasks. Tasks are typically independent processes that can be performed without coordination with the other tasks from the same request. For example, if client file103is a multi-page word processing document, each page of the document would typically be treated as a separate individual task. It is not required that every task within a request be handled by the same GP or be performed in a specific sequence. In a system having multiple GPs capable of performing the same types of conversions, it is likely that multiple GPs will be involved in completing a single multi-task request, thus reducing the amount of time necessary to complete the request. While a single request queue141and a single task queue142are employed in a preferred embodiment, DM140could be implemented with multiple request or task queues, for example a separate task queue for each type of GP.

Each operational GP has a unique GP ID. As a part of the initiation process for a newly activated GP, the GP will register its capabilities with DM140. DM140maintains a Capabilities143data structure indicating the file conversion capabilities of each operational GP. The capabilities of a GP reflect the types of file conversions that the GP's associated application is capable of performing. As each GP completes a task and is ready to begin work on another, the GP will request that DM140assign a task to it. DM140will check the capabilities of the requesting GP in Capabilities143and at step305will assign to the GP the next available task in queue142that corresponds to the capability of that GP. For each task that has been assigned, DM140will store an indication of which GP is handling that task. Because DM140does not assign a task to a GP until the GP asks for it when the GP is available, the system inherently will balance the processing load among all GPs capable of handling each type of task.

At step306, the GP assigned the task will retrieve the associated client file103from shared folder130and control the associated application to accomplish the required conversion at step307. As mentioned above, in a preferred embodiment, applications153and154are commercially available software products with documented input and output formats and procedures. Each GP uses a standard interface and procedure in interacting with DM140, shared folder130and monitor156. In each GP's interactions with its associated application, the GP is adapted to provide inputs and commands to, and receive the outputs from, the application in the manner required by that particular application.

When the conversion is complete, the GP will store the converted file in shared folder130at step308and appropriately update the task status in DM140at step309. In some cases, the output of one GP will require further conversion by another GP. For example, a file in Microsoft Word format would first go to a GP associated with appropriate Microsoft word processing program, such as a GP associated with the Microsoft Office XP application, where the Word file would be converted to PDF format. The first GP would then store the PDF file in shared folder130as print file133and create a new task entry in task queue142. At step311, the new task would be associated with the same request entry in request queue141, thereby placing the task at or near the top of queue142. The next available GP running an image processing application, such as Adobe Photoshop, would then receive the task of converting the PDF file into the thumbnail and web file versions, which would be stored in shared folder130as thumbnail131and web132. When all tasks associated with a request have been completed, the request status is appropriately updated at step312.

Because the process may take a few seconds to complete, in a preferred embodiment web server120will periodically check the status of the pending request in queue141and display a visual indication of task progress to the user. As an alternate embodiment, rather than web server120repetitively checking request status, the interaction between web server120and DM140could be implemented such that web server120waits for DM140to generate a notification message to web server120that the request has been completed. In this case, since incremental status information is not available to web server120, the user could be shown a generic visual moving design to assure the user that the system is working on a response. When a request is identified as being completed, web server will read the queue141entry, which gives web server120the information necessary to retrieve the converted files from shared folder130. In a preferred embodiment, web server120is also provided the size of the converted files.

At step314, web server120retrieves the appropriate file from shared folder120and transmits it to client100at step315. In a preferred embodiment, web server initially retrieves only thumbnail131for transfer to client100. If the user views thumbnail131and subsequently indicates a desire to use the image in the document, web server120will retrieve and transfer web version132.

The operation of GP152and application155regarding browsers101that do not support DHTML features involves similar, but not identical steps. When a customer is using a browser that does not support XHTML, tool102will perform a “browser capture” operation. Tool102will receive the product edit requests from the user, create an XHTML description of the user's product incorporating the user's edits, and forward the description to web server120for processing. Web server120receives the product description and creates a request entry for queue141and a task entry for queue142. The received XHTML document description is generally relatively small compared with the typical client file103and, in a preferred embodiment, the XHTML document description is embedded into the queue142task entry and not stored as a separate file in shared folder130. When GP152is assigned a task by DM140, GP152retrieves the task entry including the product description, provides the product description to application155for rendering, captures a bitmap of the rendered image, stores the image as a JPEG image in shared folder130, and updates the task status to indicate that it has been completed. No thumbnail version is required or produced in the browser capture case.

Completed request and task entries will remain in queues141and142until DM140receives an indication from web server120that the requested file has been successfully transmitted to client100. Converted files will remain available in shared folder130for a period determined by the printing services supplier, generally based on available storage capacity and business considerations. For example, a potential customer who uploaded a file, but did not complete a product purchase, may have been interrupted or delayed for various reasons. The printing service may choose to retain the file for a period of days or weeks before deleting it, in case the customer returns. If an uploaded file has been incorporated into a product that was purchased, the printing service provider may choose to retain the file for a much longer period in anticipation of the customer reordering the same product again in the future.

One preferred embodiment of the invention has been shown and described and various alternative methods and structures for other embodiments have been mentioned, but the foregoing description is to be considered in all aspects as illustrative rather than restrictive. The scope of the invention is as indicated in the following claims and all equivalent methods and apparatus.