Patent Application
20140033031
Portions of this patent document contains material that is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure, as it appears in the Patent and Trademark Office patent files or records, but otherwise reserves all copyright rights whatsoever. The following notice applies to the software and data as described below and in the drawings that form a part of this document: Copyright 2008, ADOBE SYSTEMS INCORPORATED. All Rights Reserved.
The present application relates generally to the technical field of document processing. For example, an embodiment of the invention relates to processing multiple portions of a document substantially in parallel.
In general, preflight is a process that enables users to check a document for errors. The preflight is applied so that errors can be corrected before the document is sent to a printer. For example, the document may be an electronic version of a magazine, and errors in the document can prove to be expensive when the magazine has to be reprinted to remove the errors. An example of preflight features may be found in ADOBE® ACROBAT of Adobe Systems of San Jose, Calif.
A preflight rule is a small bit of intelligence (and parameters) that looks for a particular kind of problem in a document. For example a rule may look for text that is too small. Such a rule might have two parameters which include whether to check the text and if the text is to be checked, whether the text is too small. The first parameter is the on/off state of the rule. The second parameter is a threshold value to determine whether the text is too small. For example, the threshold may be four (4) points or 0.055 inches in height. A preflight profile may simply be a collection of preflight rules. Each preflight profile may be associated with a preflight name. For example, there may be a preflight profile called “Magazine” which includes preflight rules that may be used to check for errors in a document that will be used as part of a magazine publication. The preflight rules in the “Magazine” preflight profile may restrict the document from having any spot colors and from having any text smaller than 6 points in size, and so on.
Some embodiments are illustrated by way of example and not limitation in the figures of the accompanying drawings in which:
For some example embodiments, methods and systems to apply a preflight profile to a document may enable a user to review preflight errors while the preflight is operating in the background. In the following description, for purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of some example embodiments. It will be evident, however, to one skilled in the art that the present invention may be practiced without these specific details.
A preflight is usually initiated by a user. First, the user selects a target document and a preflight profile. There may be a set of preflight profiles for a user to select from. Once a preflight profile is selected, the preflight may traverse the content of the document, applying the preflight rules (also referred to as rules) and generating a report of errors as they are encountered. For example, the preflight may check the document for errors associated with fonts, colors, and alignment. The user is presented with the results which can be saved as a report. Those results become a starting point of a separate process of correction.
Because the preflight is initiated by the user (i.e., on-demand basis), the user may work for long stretches of time potentially introducing new errors along the way. These new errors can be costly because the user may need to go back and repeat the preflight. For example, the user may create artwork in the document which may be incompatible with the preflight rules that cover printing requirements. Recognizing the incompatibility after the artwork has already been created, adjusted, reviewed, and so on, may be costly in terms of time.
The preflight flow remains the same regardless of how much time the user spends reviewing and corrects the document to remove the errors. The preflight is performed to completion before the user gets the error report. After correction, the preflight is again performed to completion before the user gets another error report, and so on.
For some example embodiments, the preflight may be improved by allowing the user to make a correction substantially in parallel with the preflight. The user does not have to wait until the preflight is completed. The preflight may be applied to any printing and/or publication processes that may enable the user to save time and expenses associated with correcting errors due to conflicts, collisions, and/or errors. The preflight techniques described herein may be implemented in software, hardware, or a combination of both.
In the following discussions, a preflight may also be referred to an inspection process that is performed by a preflight engine. Preflighting a document or a portion of the document may also be referred to as inspecting the document or the portion of the document. An inspected portion may be associated with an inspection result. Depending on the rules of the preflight profile used by the preflight engine, the inspection result may include errors found, or it may not include any errors. The inspection result may be sent to a user to review and to make correction to the document (or the portion of the document) to remove the errors. A subsequent re-inspection or revalidation may be performed by the preflight engine.
For some example embodiments, the preflight engine 150 may operate substantially in parallel with operations of the user 101. For example, the user 101 may be viewing and editing the document 105 while the preflight engine 150 may be operating in the background. The user 101 may be a person or an entity that is capable of reviewing errors related to the results 117 generated by the preflight engine 150. The user 101 may then make correction or changes to the document (or a portion) 105. A results user interface 125 may be used to view the errors. For example, the user 101 may be a server performing services on behalf of a web site.
For some example embodiments, operations associated with preflighting the document 105 (or portions of the document) and operations associated with displaying the errors and/or the document 105 to enable the user 101 to view and to make changes may be implemented substantially in parallel using separate threads or using time slices in a single-threaded application. Multi-threading and time-slicing techniques are techniques that enable parallel processing and/or multi-taskings.
The database 120 may be configured to store information related to portions of the document 105 that have been inspected by the preflight engine 150. The database 120 may also store the results 117 associated with the portions of the document that have been inspected. Size of a portion may vary depending on implementation. For example, a portion may range anywhere from the entire document 105 to extremely fine-grained pieces of the document 105 such as, for example a single character of text on a page. The results 117 stored in the database 120 may be displayed via the results interface 125. It may be noted that the results 117 may be formatted between when it is sent from the preflight engine 150 and when it is displayed in the results interface 125. The results interface 125 (also referred to as a visual feedback interface) may be used by the preflight system 100 to provide visual feedback to the user 101. When there are errors to be corrected, the errors may be highlighted to provide visual recognition. For some example embodiments, visual formatting (e.g., error highlighting, etc.) may be performed by the controller 115 and/or the result interface 125.
The observer 110 is configured to observe changes in the document 105. The observer 110 may examine the change information 107 and determines the portion(s) of the document 105 that is affected by the change. The observer 110 may provide the results of its determination to the controller 115. These results (also referred to as the scope of validation) 108 may identify the portions of the document 105 that the controller may need to revalidate. For some example embodiments, the determination of the portions of the document 105 affected by the change may be performed by the observer 110, the controller 115, or by both the observer 110 and the controller 115.
Responsive to receiving the scope of validation information 108 from the observer 110, the controller 115 may access the database 120 and update status of the stored results 117 that are related to the change information. For example, when the controller 115 determines that a portion “A” of the document 105 has been updated, then the controller 115 may revalidate (or re-preflight) that portion “A”. The controller 115 may then update the results 117 associated with the portion “A” since those results may no longer be valid.
Embodiments of the present invention may enable the preflight engine 150 and the controller 115 to continue to operate on the document 105 and/or revalidation of portions of the document 105 while the user 101 is able to view the errors on the results user interface 125. This is different from the traditional preflight approach where the preflight and the error viewing operations occur in sequence.
If errors are found, information about the errors is generated, as illustrated in block 220. For example, an error report may be generated. At block 225, the error information may be stored in the database 120. When the preflight engine 150 is implemented using time-slicing, a test may be performed to determine if the current time slice has expired, as illustrated in block 230. If the time slice has expired, the process may flow to block 235 where the preflight engine 150 may need to wait for another time slice to be allocated. When that occurs, the process may return to block 205 to repeat the operations.
From block 210, if the task list 116 is empty, the process may flow to block 240. For some example embodiments, the task list 116 may be empty while new tasks are being created by the controller 115 based on information stored in the database 120. At block 240, it is determined whether new tasks are being created. If they are being created, the process may flow to block 245 to wait for the new tasks. The process may then flow to block 230 to determine whether to wait for a next slice if the preflight engine 150 is implemented using time-slicing. If time-slicing is not implemented, the process may continue to wait in block 245 until a signal is received to indicate that the new tasks have been created. In this situation, the process may flow from block 245 to block 205.
From block 240, if no new task is being created, then the preflight engine 150 may have completed the preflight for the document 105. The preflight engine 150 may go into an idle state and wait for signals (or interrupt) to transition out of the idle state, as illustrated in block 245. For example, the signal may indicate that there is a new document to preflight. When the signal is received, the preflight engine 150 may return to block 205 to repeat the operations.
At block 310, the observer 110 may examines the change information 107 and determine the portions of the document 105 that are affected by the change. At block 315, the observer 110 notifies the controller 115 about the affected portions. The controller 115 may then consider its current task and, if the current task is affected by the change, resets the current task to empty and interrupts any inspection currently underway (e.g., in a threaded configuration) by the preflight engine 150. As described above, the controller 115 may perform the determination of the portions of the document 105 that are affected by the change, or it may make the determination along with the observer 110.
Referring to
The information included in the first column 405 and in the second column 410 may be used by the preflight engine 150 to determine the next portion to inspect. The results information in the last column 415 may be used by a user to correct the errors found by the preflight engine 150.
Controller Process—with Non-Overlapping Data Structure
The preflight engine 150 may apply the rules of the preflight profile 107 to the portions on the task list. The preflight engine 150 may generate inspection results (also referred to as errors, conflicts, or collision) and send the inspection results to the controller 115. At block 520, the controller 115 receives the inspection results. At block 525, the controller 115 uses the inspection results to update the database 120. This may include updating the status of each of the affected portions and their corresponding inspection results, as illustrated in columns 410 and 415 of
From block 555, if there are no new portions, it is then determined if existing portions are deleted, as illustrated in block 560. If portions are deleted from the document 105, the controller 115 updates the task list to reflect that change. This may include, for example, removing information about the deleted portions from the task list since there is nothing to inspect. If there are deleted portions, the controller 115 updates the task list accordingly, as illustrated in block 575. The process then flow to block 565.
From block 560, if there are no deleted portions, it is then determined if there are modified portions, as illustrated in block 565. If portions are modified, the controller 115 adds information about the modified portions to the task list for re-inspection. At block 585, the controller 115 sends a message to the user 101 indicating that results have been updated. This may be via the result interface 125. As noted above, the portion may vary depending on the implementation, and performance may be a factor to consider when determining the size of the portion especially when time slicing is used.
For some example embodiments, the information stored in the database 120 may be organized into lists of nodes that are related to one another. At initialization, the database 120 may be populated with a single root node, which is a reference to the document 105. The to-be-expanded and to-be-visited nodes are initialized to contain only the document node. This is illustrated in
The directed graph of
Note that the directed graph 700 (also referred to as a preflight graph) may or may not be a one-to-one correspondence with the structure of the document 105. However, the preflight engine 150 needs to understand how the nodes are used in the database 120. For example, the preflight engine 150 may need to look at logical objects that are not actually present in the document 105 but are useful for preflight purposes. For example, the directed graph 700 includes three nodes that represent paragraphs 740-750 even though the document 105 may only express text in terms of arrays of characters. This is because, for preflight purposes, it may be more useful to describe them as words, sentences, or paragraphs.
For some example embodiments, instead of having the result nodes, the results may be added to the object node as a property of the object node. It may be noted that the examples illustrated in
Controller Process—with Hierarchical Data Structure
At block 810, a node N from the list of nodes to be expanded 605 is examined to determine its children nodes. At block 815, a child node C of the node N is created. This may include adding the child node C to the direct graph linking it to the node N. At block 820, the child node C is added to the list of nodes to be expanded 605. The operations described in blocks 815 and 820 may be repeated until all the children nodes of the node N are processed. At block 830, the node N is removed from the list of nodes to be expanded 605. It may be noted that the list of nodes to be expanded 605 may be empty eventually. The controller 115 may then provide the list of nodes to be examined 610 to the preflight engine 150.
In a time-slice implementation, when a time slice expires, the process of
At block 920, the controller 115 adds the affected node to the to-be-expanded and to-be-visited lists 605, 610 so that on the next task list request from the preflight engine 150, the directed graph may be expanded starting from that affected node. At block 925, the user is notified of the change since the results have changed. It may be noted that this process may assume that the observer 110 considers a node to be affected if any changes occur to its children nodes.
Certain embodiments are described herein as including logic or a number of components, modules, or mechanisms. A component may be a tangible unit capable of performing certain operations and is configured or arranged in a certain manner. In example embodiments, one or more computer systems (e.g., a standalone, client or server computer system) or one or more components of a computer system (e.g., a processor or a group of processors) may be configured by software (e.g., an application or application portion) as a “component” that operates to perform certain operations as described herein.
In various embodiments, a “component” may be implemented mechanically or electronically. For example, a component may comprise dedicated circuitry or logic that is permanently configured (e.g., within a special-purpose processor) to perform certain operations. A component may also comprise programmable logic or circuitry (e.g., as encompassed within a general-purpose processor or other programmable processor) that is temporarily configured by software to perform certain operations. It will be appreciated that the decision to implement a component mechanically, in dedicated and permanently configured circuitry, or in temporarily configured circuitry (e.g., configured by software) may be driven by cost and time considerations.
Accordingly, the term “component” should be understood to encompass a tangible entity, be that an entity that is physically constructed, permanently configured (e.g., hardwired) or temporarily configured (e.g., programmed) to operate in a certain manner and/or to perform certain operations described herein. Considering embodiments in which components are temporarily configured (e.g., programmed), each of the components need not be configured or instantiated at any one instance in time. For example, where the components comprise a general-purpose processor configured using software, the general-purpose processor may be configured as respective different components at different times. Software may accordingly configure a processor, for example, to constitute a particular component at one instance of time and to constitute a different component at a different instance of time.
Components can provide information to, and receive information from, other components. Accordingly, the described components may be regarded as being communicatively coupled. Where multiple of such components exist contemporaneously, communications may be achieved through signal transmission (e.g., over appropriate circuits and buses) that connect the components. In embodiments in which multiple components are configured or instantiated at different times, communications between such components may be achieved, for example, through the storage and retrieval of information in memory structures to which the multiple components have access. For example, a one component may perform an operation, and store the output of that operation in a memory device to which it is communicatively coupled. A further component may then, at a later time, access the memory device to retrieve and process the stored output. Components may also initiate communications with input or output devices, and can operate on a resource (e.g., a collection of information).
The term “module”, as used herein, should be understood to refer more broadly to a tangible component or a software component, or any combination thereof. Accordingly, a module may be implemented in electronic circuitry, hardware, firmware, software or a combination thereof.
Example embodiments may be implemented using a computer program product, e.g., a computer program tangibly embodied in an information carrier, e.g., in a machine-readable medium for execution by, or to control the operation of, data processing apparatus, e.g., a programmable processor, a computer, or multiple computers.
A computer program can be written in any form of programming language, including compiled or interpreted languages, and it can be deployed in any form, including as a stand-alone program or as a module, subroutine, or other unit suitable for use in a computing environment. A computer program can be deployed to be executed on one computer or on multiple computers at one site or distributed across multiple sites and interconnected by a communication network.
In example embodiments, operations may be performed by one or more programmable processors executing a computer program to perform functions by operating on input data and generating output. Method operations can also be performed by, and apparatus of example embodiments may be implemented as, special purpose logic circuitry, e.g., an FPGA (field programmable gate array) or an ASIC (application-specific integrated circuit).
The computing system can include clients and servers. A client and server are generally remote from each other and typically interact through a communication network. The relationship of client and server arises by virtue of computer programs running on the respective computers and having a client-server relationship to each other. In embodiments deploying a programmable computing system, it will be appreciated that that both hardware and software architectures require consideration. Specifically, it will be appreciated that the choice of whether to implement certain functionality in permanently configured hardware (e.g., an ASIC), in temporarily configured hardware (e.g., a combination of software and a programmable processor), or a combination permanently and temporarily configured hardware may be a design choice. Below are set out hardware (e.g., machine) and software architectures that may be deployed, in various example embodiments.
The example computer system 1000 includes a processor 1002 (e.g., a central processing unit (CPU), a graphics processing unit (GPU) or both), a main memory 1004 and a static memory 1006, which communicate with each other via a bus 1008. The computer system 1000 may further include a video display unit 1010 (e.g., liquid crystal display (LCD) or a cathode ray tube (CRT)). The computer system 1000 also includes an alphanumeric input device 1012 (e.g., a keyboard), a user interface (UI) navigation device 1014 (e.g., a mouse), a disk drive unit 1016, a signal generation device 1018 (e.g., a speaker) and a network interface device 1020.
The disk drive unit 1016 includes a machine-readable medium 1022 on which is stored one or more sets of instructions and data structures (e.g., software 1024) embodying or utilized by any one or more of the methodologies or functions described herein. The software 1024 may also reside, completely or at least partially, within the main memory 1004 and/or within the processor 1002 during execution thereof by the computer system 1000, the main memory 1004 and the processor 1002 also constituting machine-readable media.
While the machine-readable medium 1022 is shown in an example embodiment to be a single medium, the term “machine-readable medium” may include a single medium or multiple media (e.g., a centralized or distributed database, and/or associated caches and servers) that store the one or more instructions. The term “machine-readable medium” shall also be taken to include any tangible medium that is capable of storing, encoding or carrying instructions for execution by the machine and that cause the machine to perform any one or more of the methodologies of the present invention, or that is capable of storing, encoding or carrying data structures utilized by or associated with such instructions. The term “machine-readable medium” shall accordingly be taken to include, but not be limited to, solid-state memories, and optical and magnetic media. Specific examples of machine-readable media include non-volatile memory, including by way of example semiconductor memory devices, e.g., EPROM, EEPROM, and flash memory devices; magnetic disks such as internal hard disks and removable disks; magneto-optical disks; and CD-ROM and DVD-ROM disks.
The software 1024 may further be transmitted or received over a communications network 1026 using a transmission medium via the network interface device 1020 utilizing any one of a number of well-known transfer protocols (e.g., HTTP). Examples of communication networks include a local area network (“LAN”), a wide area network (“WAN”), the Internet, mobile telephone networks, Plain Old Telephone (POTS) networks, and wireless data networks (e.g., WiFi and WiMax networks) The term “transmission medium” shall be taken to include any intangible medium that is capable of storing, encoding or carrying instructions for execution by the machine, and includes digital or analog communications signals or other intangible medium to facilitate communication of such software.
Although an embodiment has been described with reference to specific example embodiments, it will be evident that various modifications and changes may be made to these embodiments without departing from the broader spirit and scope of the invention. Accordingly, the specification and drawings are to be regarded in an illustrative rather than a restrictive sense. The accompanying drawings that form a part hereof, show by way of illustration, and not of limitation, specific embodiments in which the subject matter may be practiced. The embodiments illustrated are described in sufficient detail to enable those skilled in the art to practice the teachings disclosed herein. Other embodiments may be utilized and derived therefrom, such that structural and logical substitutions and changes may be made without departing from the scope of this disclosure. This Detailed Description, therefore, is not to be taken in a limiting sense, and the scope of various embodiments is defined only by the appended claims, along with the full range of equivalents to which such claims are entitled.
Such embodiments of the inventive subject matter may be referred to herein, individually and/or collectively, by the term “invention” merely for convenience and without intending to voluntarily limit the scope of this application to any single invention or inventive concept if more than one is in fact disclosed. Thus, although specific embodiments have been illustrated and described herein, it should be appreciated that any arrangement calculated to achieve the same purpose may be substituted for the specific embodiments shown. This disclosure is intended to cover any and all adaptations or variations of various embodiments. Combinations of the above embodiments, and other embodiments not specifically described herein, will be apparent to those of skill in the art upon reviewing the above description.
The Abstract of the Disclosure is provided to comply with 37 C.F.R. §1.72(b), requiring an abstract that will allow the reader to quickly ascertain the nature of the technical disclosure. It is submitted with the understanding that it will not be used to interpret or limit the scope or meaning of the claims. In addition, in the foregoing Detailed Description, it can be seen that various features are grouped together in a single embodiment for the purpose of streamlining the disclosure. This method of disclosure is not to be interpreted as reflecting an intention that the claimed embodiments require more features than are expressly recited in each claim. Rather, as the following claims reflect, inventive subject matter lies in less than all features of a single disclosed embodiment. Thus the following claims are hereby incorporated into the Detailed Description, with each claim standing on its own as a separate embodiment.
