U.S. patent application number 10/653158 was filed with the patent office on 2005-04-07 for reusable job editing and delivery system.
This patent application is currently assigned to Hewlett Packard. Invention is credited to Foster, Ward S., Simpson, Shell S..
Application Number | 20050076299 10/653158 |
Document ID | / |
Family ID | 23610305 |
Filed Date | 2005-04-07 |
United States Patent
Application |
20050076299 |
Kind Code |
A1 |
Simpson, Shell S. ; et
al. |
April 7, 2005 |
Reusable job editing and delivery system
Abstract
A computer implemented method by which a user edits and delivers
a print job in a computer system, the method including providing a
printing software object as a COM component for editing and
delivering a print job and providing job data of the print job to
the printing software object, by a print job creator, in the form
of references to pages. The references to pages are used by the
software printing object, to call and display the pages on a need
basis. The user edits the job data of the print job based on the
displayed pages and the print job is delivered for processing in
accordance with the edited job data.
Inventors: |
Simpson, Shell S.; (Boise,
ID) ; Foster, Ward S.; (Boise, ID) |
Correspondence
Address: |
HEWLETT PACKARD COMPANY
P O BOX 272400, 3404 E. HARMONY ROAD
INTELLECTUAL PROPERTY ADMINISTRATION
FORT COLLINS
CO
80527-2400
US
|
Assignee: |
Hewlett Packard
|
Family ID: |
23610305 |
Appl. No.: |
10/653158 |
Filed: |
September 3, 2003 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
10653158 |
Sep 3, 2003 |
|
|
|
09407024 |
Sep 28, 1999 |
|
|
|
6738156 |
|
|
|
|
Current U.S.
Class: |
715/274 |
Current CPC
Class: |
G06F 3/1206 20130101;
G06F 3/1204 20130101; G06F 3/1209 20130101; G06F 3/1225 20130101;
G06F 3/1244 20130101; G06F 3/1285 20130101 |
Class at
Publication: |
715/527 |
International
Class: |
G06F 017/00 |
Claims
1. A computer implemented method by which a user edits and delivers
a print job in a computer system, the method comprising the steps
of: providing a printing software object as a COM component for
editing and delivering a print job; providing job data of the print
job to the printing software object, by a print job creator, in the
form of references to pages; using the reference to pages, by the
software printing object, to call and display the pages on a need
basis; editing the job data of the print job by user based on the
displayed pages; and delivering the print job for processing in
accordance with the edited job data.
2. The computer implemented method according to claim 1 wherein the
software printing object is provided as an in-process COM
component.
3. The computer implemented method according to claim 2, wherein
the software printing object is used directly by an application
that is the print job creator.
4-5. (canceled)
6. A computer readable data storage medium having program code
recorded thereon for a user editable print job editing and delivery
system, the program code comprising: a first program code that
provides a printing software object as a COM component for editing
and delivering the print job; a second program code that provides
job data of the print job to the printing software object, in the
form of references to pages; the printing software object uses the
reference to pages to call and display the pages on a need basis
and edits the job data of the print job based on the user's
response to the displayed pages; and a third program code that
delivers the print job for processing in accordance with the edited
job data.
7. The computer readable data storage medium according to claim 6,
wherein the software printing object is provided as an in-process
COM component.
8. The computer readable data storage medium according to claim 7,
wherein the software printing object is usable directly by an
application that is the print job creator.
9-13. (canceled)
Description
FIELD OF THE INVENTION
[0001] This invention relates generally to the field of software
for editing and delivering printer jobs and more particularly to a
method and system by which a user can edit and deliver a print job
in a computer system where the print job can originate from
different applications and platforms.
BACKGROUND OF THE INVENTION
[0002] A new class of printing software has coming into use
recently. This class of printing software allows jobs to be edited
outside of a printer driver. This class of software is of
particular interest because it makes printing features provided by
a printer visible to a user. On the Microsoft Windows platforms
("Windows"), the predominant platform for home and office printing,
the only user interface related to printing that most users
interact with comes from the application. This user interface (i.e.
print dialog box) often does not expose capabilities that
differentiate the different printer products. Consequently,
investment in new hardware, firmware, and software technologies for
printer products goes largely unnoticed and unused by the majority
of the users.
[0003] For the purposes of this application this new class of
printing software is referred to as job editing and delivery
systems. These systems capture a job from an application and
provide the user with the opportunity to interactively modify the
job settings. Users can choose options like n-up ("n" images on one
sheet), watermarks, and booklet printing--among others. After the
user has finished choosing the desired settings, the job is then
sent to a printer of the user's choice. Some job editing and
delivery systems track the job's status with varying degrees of
success.
[0004] There are several commercial examples of job editing and
delivery systems in existence today. A non-exhaustive list of these
types of systems include:
[0005] (i) FinePrint by Single Track Software
(www.singletrack.com);
[0006] (ii) printChef by MindGate (www.mindgate.com);
[0007] (iii) HandyPrint; or
[0008] (iv) Power PrintCache by LaserTools.
[0009] All of these job editing and delivery systems are
implemented as a monolithic, non-reusable system. Although they are
reusable in the sense that they can capture and process print jobs
from most Windows applications, they are non-reusable in the sense
that they cannot be used to capture and process jobs from
non-Windows applications that are used by Windows end-users. For
example, it would require a significant design change for any of
the current products, such as those mentioned above, to support a
Windows client printing from a UNIX host. Accordingly, a problem
with the current systems is that a Windows end-user does not have
the same rich printing experience regardless of which system the
print job originates from.
[0010] These job editing and delivery systems are also non-reusable
because they cannot be more tightly integrated into applications.
In order to capture job information, they require the application
to pass job information to the Windows or other operating systems'
printing system. Before they can offer a print preview, this
information must pass through the printing system, which causes a
significant delay.
[0011] Furthermore, the prior art systems are not well integrated
into the applications and, therefore, can not be easily modified by
the applications. That is, prior art job editing and delivery
systems are not easily configurable by applications.
[0012] FIG. 1 shows the operation of a typical prior art job
editing and delivery system 10 similar to the ones mentioned above.
It is important to note that the figure is based entirely on a
functional examination of the behavior of the existing systems and
an examination of a Windows system after installing a prior art job
editing and delivery system, without performing a disassembly of
program instructions. In FIG. 1, the prior art system 10 captures
the job using a custom printer driver 11. This printer driver 11
passes the job information to a 32-bit processing module 12, which
in turn displays the job information so that a user may edit this
job information. In the obvious implementation, job information
(including imaging information) is passed into the prior art 32 bit
processing module 12 and processed directly by the prior art system
10. This makes the prior art 32 bit processing module 12 (or any
similarly implemented job editing and delivery system) impractical
to reuse.
[0013] Reusing a job editing and delivery system is desirable
because job information may come from many sources. For instance,
job information may be supplied from an Enterprise Resource
Planning (ERP) application from vendor such as SAP (which is the
market leader in providing ERP applications). Although SAP jobs
typically originate on a server machine, the end-user often issues
the print command from client software running under Windows.
Therefore, the user is unable to interact with their familiar
Windows-based job editing and delivery system when they print from
SAP (or other similar client/server applications).
[0014] To enable the prior art job editing and delivery system to
be used when printing from SAP, it would be necessary to transmit
the job from SAP to the end-user's PC, then funnel this information
into the job editing and delivery system. Funneling the job
information into a job editing and delivery system would be likely
to involve the following steps:
[0015] (i) converting the job data into the intermediate
representation used by the job editing and delivery system and
thereby severely impact performance; and/or
[0016] (ii) sending job data across process boundaries (requiring a
copy), which also severely impacts performance.
[0017] Therefore, none of the known job editing and delivery
systems appear to support re-use and there is no evidence that it
is practical to re-use their printing software objects or
modules.
SUMMARY OF THE INVENTION
[0018] Therefore, it is a general objective of the invention to
alleviate the problems and shortcomings identified above.
[0019] One of the objectives of one aspect of the invention is to
provide a reusable job editing and delivery system that permits a
Windows user to edit and transmit a print job irrespective of the
origin of the print job.
[0020] An objective of another aspect of the invention is to
provide a reusable job editing and delivery system that makes use
of standard component technologies so that the job editing and
delivery system can be used by a different applications on
different platforms.
[0021] An objective of another aspect the invention is to provide a
printing software object that can be directly used by an
application that originates a print job.
[0022] An objective of another aspect of the invention is to
provide a printing software object that can be used by a printer
driver conduit host that captures the print job data from the
printing subsystem of an operating system.
[0023] An objective of another aspect of the invention is to
provide a printing software object that can be used by a server
conduit host that captures print job data from a server system
which originates the print job.
[0024] These and other objectives are achieved by providing a
computer implemented method by which a user edits and delivers a
print job in a computer system, the method including the steps of:
providing a printing software object as a Component Object Model
("COM") component for editing and delivering a print job; providing
the job data of the print job to the printing software object, by a
print job creator, in the form of references to pages; using the
reference to pages, by the software printing object, to call and
display the pages on a need basis; editing the job data of the
print job by a user based on the displayed pages; and delivering
the print job for processing in accordance with the edited job
data.
[0025] Also provided is a printing software object as an in-process
COM component.
[0026] Also provided is a method in which the printing software
object is used directly by an application that is the print job
creator.
[0027] Further provided is a computer implemented method in which
the printing software object is used by a printer driver conduit
host that captures print job data from the printing subsystem of
the OS.
[0028] Also provided is a computer implemented method in which the
software printing object is used by a server conduit host that
captures print job data from a server system in which the print job
data is created.
[0029] Further provided is a computer readable data storage medium
having program code recorded thereon for a user editable print job
editing and delivery system, the program code including: a first
program code that provides a printing software object as a COM
component for editing and delivering the print job; a second
program code that provides job data of the print job to the
printing software object, in the form of references to pages; the
printing software object uses the reference to pages to call and
display the pages on a need basis and edits the job data of the
print job based on the user's response to the displayed pages; and
a third program code that delivers the print job for processing in
accordance with the edited job data.
DESCRIPTION OF THE DRAWINGS
[0030] The accompanying drawings, which are incorporated in and
constitute a part of the specification, illustrate a presently
preferred embodiment of the invention, and, together with the
general description given above and the detailed description of the
preferred embodiment given below, serve to explain the principles
of the invention.
[0031] FIG. 1 is a block diagram showing the components of a
typical prior art job editing and delivery system.
[0032] FIGS. 2a-2d illustrate the use of a printing software object
as an in-process COM object.
[0033] FIG. 3 is a Unified Modeling Language (UML) diagram
depicting the passing of job data between an application and the
job editing and delivery system according to the present
invention.
[0034] FIG. 4 illustrates sample program code that implements an
exemplary list of functions that might be found in the Page Image
Set and Page Image interfaces according to the present
invention.
[0035] FIG. 5 illustrates pseudocode for an exemplary interface to
the job editing and delivery system according to the present
invention.
[0036] FIG. 6 is an illustration of a sample job interface
according to the present invention.
[0037] FIG. 7 illustrates the structure of a print job as a
modified UML class diagram.
[0038] FIG. 8 is a flow diagram showing the operation of the job
editing and delivery system according to the present invention.
DETAILED DESCRIPTION OF THE INVENTION
[0039] In a general aspect, the present invention offers the
following advantages over known technologies in the prior art:
[0040] (i) avoids the computational intensive conversion of imaging
information into an unnecessary intermediate representation;
[0041] (ii) avoids copying job information across process
boundaries;
[0042] (iii) facilitates the reuse of a job editing and delivery
system by client/server printing software (such as SAP, UNIX
systems, and mainframe systems); and
[0043] (iv) simplifies reuse of a job editing and delivery system
within application software.
[0044] To emphasize the advantages of the present invention it is
worth noting that all known prior art job editing and delivery
systems suffer from significant performance problems for the
reasons mentioned earlier. The job must be transmitted from the
application to the Operating Systems (OS's) printing system before
the job is available (in its entirety) to the prior art job editing
and delivery system. For example, if an application has two hundred
pages in a job, all two hundred pages must be transmitted to the
job editing and delivery system. If the job editing and delivery
system were integrated into the application, it would be possible
for the job editing and delivery system to request desired pages on
a demand basis--thereby avoiding the need to process all the pages
of the job.
[0045] To encourage application developers to go through the effort
of integrating such a system, the system must be easy to integrate
and integration must provide a marketable improvement for the
application developer. Once integrated, the job editing and
delivery system provided according to the present invention, can
essentially becomes the application's print dialog box (or print
preview).
[0046] As mentioned earlier, the present invention allows the
printer hardware and software to expose its printing capabilities
to a user. The best possible place to do this is in a manner
seamlessly integrated into the application (i.e. using the print
dialog box of the application) as provided in the present
invention.
[0047] In a broad aspect, the present invention uses two new
approaches to facilitate the goal of achieving a reusable job
editing and delivery system.
[0048] In the first approach, the job editing and delivery system
of the present invention is implemented as an in-process COM
component that accepts job data from a variety of sources. Since
COM is a well-known Windows standard, the system can be integrated
into other software programs with relative ease. Since the COM
component is in-process, no unnecessary copying of data from one
process to another is required.
[0049] In the second approach, job data is provided to the job
editing and delivery system in the form of references to pages. The
system calls back to the provider of these pages to draw the pages
on a demand or need basis. Thus, the present invention avoids the
need for converting image data into an intermediate representation.
Instead, the provider sends image data directly to Windows Graphics
Device Interface ("GDI") as directed by the job editing and
delivery system.
[0050] To facilitate the understanding of the preferred embodiment
of the present invention a brief description of the Windows
Graphics Device Interface (GDI) printing system and the Component
Object Model (COM) is provided herewith. It is hereby acknowledged
that any trademarks and trade names referenced herein are the
property of their respective owners.
[0051] The COM is a component software architecture that allows
applications and systems to be built from components that can be
provided by different software vendors on different computer
platforms. An important feature of COM is that it provides a
mechanism by which binary software components supplied by different
software vendors are able to connect and communicate with each
other using a well defined interface. This interface mechanism is
provided by COM which is a component software architecture
developed by Microsoft that:
[0052] (i) defines a binary standard for component
interoperability;
[0053] (ii) is programming language independent;
[0054] (iii) is provided on multiple platforms; and
[0055] (iv) is extensible.
[0056] COM also provides mechanisms for the following
functionalities:
[0057] (i) communication between components across process and
network boundaries;
[0058] (ii) shared memory management among components;
[0059] (iii) error and status reporting;
[0060] (iv) dynamic loading of components;
[0061] (v) basic interoperability;
[0062] (vi) versioning; and
[0063] (vii) transparent cross process interoperability.
[0064] Some of the fundamentals that underlie COM include:
[0065] (i) a binary standard for calling functions between
components;
[0066] (ii) a provision for grouping strongly typed functions into
interfaces;
[0067] (iii) a base interface that allows components to determine
the interfaces implemented by other components and a reference
counting mechanism that allows components to track their own
lifetime;
[0068] (iv) a component loader that sets up component interactions
and manage the component interactions in cross-process and
cross-network situations.
[0069] Appendix A provides further description of the COM model,
the contents of which are incorporated herein in their entirety.
Appendix B provides a description of the GDI printing system, the
contents of which are incorporated herein in their entirety. These
appendices incorporate public information provided on the Microsoft
internet website and all rights therein belong to Microsoft.
[0070] With reference to the figures, FIGS. 2a-2d illustrates the
use of a printing software object as an in-process COM object. FIG.
2a illustrates that a job editing and delivery system provided
printing software object 21 is depicted being used directly by a
client Windows application 22. It should be understood that the
client application is not limited to the Windows environment but
includes any other client operating environment that supports a
component object model such as COM.
[0071] FIG. 2b shows the printing software object 21 being used by
a driver conduit host 30 that operates with print job information
captured from the Windows printing system. That is, an application
31 transmits a print job to a printer driver 32 which is programmed
to interact with a spooler 33 and a port monitor 34 to route the
print job to an appropriate printer (not shown in the figure). The
specially programmed printer driver 32 that captures the print job
information is one embodiment of a subsystem referred to hereafter
as the job capture subsystem ("JCSS") of the job editing and
delivery system of the present invention.
[0072] It should be noted that developing the program code to
capture the print job information from the printer driver 32 is
within the abilities of one skilled in the art. For example, in one
such implementation in the Windows environment, since the printer
driver is in the 16 bit subsystem, use is made of the Windows
operating system provided "thunk" functions. These thunk functions
provide a way of calling 16 bit functions to make method calls to
code running in the 32 bit subsystem, such as the driver conduit
host 30. These thunk functions are a software mechanism allowing a
16 bit program to call a 32-bit dynamically linked library (DLL)
under a 32 bit Windows OS. The 16 bit program that seeks to call an
entry in a 32-bit DLL instead calls a corresponding entry in a
16-bit DLL. The programmer must also include code to detect whether
the 32-bit DLL is loaded. A 32-bit EXE module loads the 32-bit DLL.
Therefore, the thunking mechanism can be used by a skilled
programmer to communicate between the printer driver 32 operating
in the 16 bit subsystem and the driver conduit host 30 running in
the 32 bit subsystem of the Windows environment.
[0073] FIG. 2c illustrates the printing software object 21 being
used by a server conduit host 40 that operates with print job
information captured from a server based system 41 (for e.g., SAP,
UNIX, mainframe) by another embodiment of the job capture
subsystem. Therefore, a client Graphical User Interface ("GUI")
application on a Windows client machine 42 connects to a session 44
on the server machine 41 to create a print job 45. Server hooks 46
provided in the server machine 41 by the present invention capture
any required print job information and transmit the same to the
server conduit host 40 so that the printing software object 21 may
provide a window for a user to edit or modify the transmitted print
job information.
[0074] FIG. 2d illustrates another use of the printing software
object 21 in a shared us environment in which the printing software
object 21 is provided in a centralized PC conduit host 47. The
centralized PC conduit host 47 then coordinates all the printing
from the different sources of print job data. Therefore, as shown
in the figure, the PC Conduit host 47 coordinates printing from a
Windows applications 22, each containing a printing software object
21 which is modified as described further herein. The PC conduit
host 47 also interacts with the specialized printer driver 32 and
the spooler hooks 33 to coordinate the editing and delivery of
print job data captured by the printer driver 32 and the spooler
hooks 33. The PC conduit host 47 also interacts with the print job
information captured from a server system 41 through the server
hooks 46. Therefore, the PC host conduit 47 is capable of receiving
print job information from several different sources, such as other
applications, printer drivers, and other servers, and serves as a
central printing center for a final job editing and delivery for a
combined set of page images.
[0075] In the shared use scenario shown in FIG. 2d, applications 22
have integrated printing software objects 21 that are specially
configurable. The specially configurable software printing objects
are configurable to "defer" their page image sets to the
centralized host conduit 47. Some of the configurable options of
the defer feature could include: (i) defer only upon request (i.e.,
user selects whether a job should be deferred); (ii)
automatic/smart deferral (i.e., the printing software object 21
defers if it detects that a centralized PC host conduit 47 is
already running; or (iii) always defer (i.e., output is always sent
to the centralized PC host conduit 47). If the defer option is
selected, the applications' in-process software printing COM object
21 would defer to the PC host conduit 47 by sending the print job
information to the PC host conduit using an intermediate format,
such as, EMF or a custom defined format. While this defer feature
imparts some performance penalties, it provides the benefit that
the print job output from these applications can be combined from
the print job outputs from other sources, such as other
applications, printer drivers or other servers. It should be noted
that while the in-process COM objects are used in the preferred
embodiment, it is also possible to use COM's out of process
activation features.
[0076] In ach of these uses of the printing software object 21, the
implementation of the COM component could be identical, i.e., the
COM object 21 could be instantiated using the same COM component.
Microsoft specifies a standard method for discovering the presence
of COM components in the definition of the COM component
architecture. Therefore, in each of these situations, this standard
method is used to locate the COM component and the COM component
can be easily shared amongst them.
[0077] Furthermore, the COM component can be upgraded independently
of the software that uses the COM component. This allows all the
software that uses the COM component to benefit when it is
upgraded. Finally, by sharing a common COM component, software
using the COM component could be designed consistently with other
software that uses the COM component, that is, have the same user
interface and behavior related to printing.
[0078] In the implementation illustrated in FIG. 2b, the Windows
printing case, printer drivers are involved twice. First, the
specially programmed printer driver 32 is involved to capture the
print job from the Windows printing system. The printer driver 32
is responsible for translating job information into a form that
allows it to be passed out of printer driver mode (for example,
kernel mode on Windows NT, 16 bit mode on Windows 9.times.) and
into application mode (i.e., for example, the 32 bit WIN32).
Thereafter, a second printer driver (i.e., a standard printer
driver) is potentially involved in translating the job information
into a format recognized by a selected target printer after the
user has selected a target printer using the job editing and
delivery system of the present invention. Alternatively, the job
editing and delivery system of the present invention can itself
translate the print job information to an appropriate printer
language and forward for printing. The details of this involvement
of the printer driver 32 are not provided here because they are
within the abilities of one skilled in the art and are not
essential to understanding the features of the present invention.
This invention is focused on providing information about the
interface between the interchangeable job capture subsystem
(corresponding to the different operating platforms and
applications) and the constant job editing and delivery subsystem
provided in accordance with the job editing and delivery system of
the present invention.
[0079] In the direct use implementation illustrated in FIG. 2(a),
the interface provided by the COM printing software object 21
serves to broaden the capabilities provided by the standard Windows
printing system. For example, Windows does not provide a mechanism
to obtain a real print preview that reflects printer settings.
However, the printing software object 21, according to the present
invention, provides a real print preview reflecting printer
settings that can now be provided by the application 22 to the
user. This is just one example of how the printing software object
21 in accordance with the present invention provides extended
capabilities (over the standard Windows printing system) that are
made available to a user of an application 22 that generates the
print job.
[0080] Therefore, the present invention provides for the
implementation of a job editing and delivery system as a COM
object, as described above. This implementation has at least the
following advantages:
[0081] (i) Unneeded copying of job data between processes is
avoided by passing references to pages, rather than detailed
imaging information, between components as discussed further
herein;
[0082] (ii) COM is a widely recognized component standard for the
Windows environment, therefore, implementing Windows software as a
COM component facilitates its reuse; and
[0083] (iii) COM provides a repository for components that can be
searched by client software using predefined standard interfaces.
This repository enables client software to share the same COM
component, thus facilitating consistency amongst applications and
ensuring that all applications benefit when the COM component is
upgraded.
[0084] Another feature of the present invention provides that job
data is provided to the printing software object in the form of
references to pages (where the provider of the job data is
responsible for drawing the pages). This method of providing job
data has several advantages. FIG. 3 is a UML diagram that depicts
the passing of job data between an application 50 and the job
editing and delivery system (i.e. printing software object 21).
[0085] In FIG. 3, the application 50 represents any of the possible
sources of image data including applications such as the windows
application 22 in FIG. 2a, drivers that capture job information
such as the printer driver 32 in FIG. 2b, and special software that
provide job information from server systems (e.g. SAP), such as the
server hooks 46 in FIG. 2c.
[0086] FIG. 3 shows a UML class diagram. The UML class diagram
illustrates that the Page Image Set objects 51 possessing Page
Image objects 52 are passed from the job information source (i.e.
application 50) to the job editing and delivery subsystem (i.e.
printing software object 21). The Page Image Set objects 51 and the
Page Image objects 52 are abstract objects. The actual concrete
types (or instances) of these objects possess a specific kind of
imaging information. Therefore, the actual relationships between
the concrete objects is derived from the "has" relationship between
the abstract objects Page Image Set and Page Image. For example,
one implementation of the abstract Page Image Set object 51 and
Page Image objects 52 might use Enhanced Meta File (EMF) format. As
shown in the FIG. 3, the concrete EMF Page Image Set object 53 is
composed of concrete EMF Page Image objects 54 ("has"
relationship). Likewise, another implementation might use
Postscript format. Therefore, the concrete Postscript Page Image
Set 55 is composed of concrete Postscript Page Image objects
56.
[0087] An exemplary list of functions that might be found in the
Page Image Set 51 and Page Image 52 interfaces is shown in FIG. 4
in C++ programming language for illustrative purposes.
[0088] As shown in FIG. 4, the class IPageImage interface supplies
two functions. A DrawGDI function is responsible for drawing on the
supplied Device Context (DC) using the transform, rotation, and
scaling implied by the provided upperLeft and lowerRight points. A
drawMode parameter is also supplied so that the interaction with
GDI can be altered as appropriate. This enables the page image
provider to adapt the GDI calls based on the type of device context
(display, printer, or metafile). For example, it is not uncommon
for applications to interact differently with the GDI d pending on
whether the application is displaying or printing.
[0089] The function GetSettingsBundle, shown in FIG. 4, retrieves a
settings bundle data structure, which is not described in detail
here because it is not necessary for understanding the claimed
invention. Individual pages can have settings associated with them,
for example, a setting which determines what media type to print
on. The job editing and delivery system, such as the software
printing object 21 uses these settings to determine what settings
to apply to logical and physical pages, which are distinct from
page images, as discussed further herein.
[0090] Similarly, the IPageImageSet interface provides a
GetSettingsBundle method (or function), which retrieves an
ISettingsBundle data structure (or a bundle of data). This bundle
contains settings that are relevant to the entire set of pages
possessed within a page image set. For example, this bundle might
contain settings such as whether or not to collate the pages and
the number of copies desired. Settings that apply to images may
also be stored within the page image set settings bundle. Doing so
applies the page image setting to all the pages within the page
image set as if the setting were stored in each individual page
image. Individual page image settings do however override page
image set settings.
[0091] Returning to FIG. 3, the application 50 is responsible for
implementing both the IPageImage and IPageImageSet interfaces and
using these interfaces to pass the print job description to the job
editing and delivery system as implemented by the printing software
object 21. To accomplish this, the application 50 must interact
with an interface provided by the job editing and delivery
system.
[0092] FIG. 5 illustrates pseudocode for an exemplary interface to
the Job Editing and Delivery System provided by the present
invention. The pseudocode illustrated in FIG. 5 for
IJobEditingAndDeliverySystem interface defines two methods. The
first method, AcceptPageImages, is used to introduce page images
into the job editing and delivery system. This method accepts a
page image set and a collection of page images. The job editing and
delivery system makes the association between the page image set
and the page images based on the page images and page image set
passed as parameters to a same method invocation. The same page
image set may be used to add additional page images to the page
image set. The page images in a page image set are ordered.
Additional pages added to a page image set are appended to the page
image set.
[0093] Once within the job editing and delivery system, the page
images are processed according to the current setting associated
with a job. Some examples of job settings include the number of
copies, duplex printing, stapling and other paper handling options.
Modifying the job object and its constituents can alter the
settings associated with the job. The GetJob function enables the
application 50 to gain access to the job for modification
purposes.
[0094] FIG. 6 is an illustration of a sample job interface
pseudocode implementation. This sample interface illustrated in
FIG. 6 provides method prototypes for gaining access to the jobs
constituents, such as the documents that make up the print job by
the GetDefaultDocument( ) method. It also provides access to the
jobs settings through the ISettingsBundle( ) method and methods to
modify these settings by replacement or by merging by providing,
for example, a MergeSettingsBundle( ) method and a
ReplaceSettingsBundle( ) method, respectively. Implementing the
program code that implements these and other methods discussed
herein is within the abilities of one skilled in the art and
further implementation details of these methods are not provided
because they are not necessary for an understanding of the claimed
invention.
[0095] FIG. 7 depicts the structure of a print job as a modified
UML class diagram. Each class depicted in FIG. 7 provides similar
interfaces for access and modification of the class settings and
constituents. For brevity, the details of each of these classes are
omitted as they are not essential for an understanding of the
invention. Using the interfaces provided by each of these classes,
an application can navigate the structure of the job and make
alterations to the settings associated with the job. It is
important to note, that these modifications will not typically be
required since most settings of concern may be provided by
associating them directly with a page image set or a page image
(i.e. settings will be applied to the logical page or
document).
[0096] FIG. 7 displays that at a physical level one or more
physical pages 60 (to be printed) form one or more sheets 61. At
the logical level, one or more logical pages 62 make up one or more
documents 63. One or more documents 63, in turn, make one or more
print jobs 64. One physical page 60 maps to zero or more logical
pages 62. At the imaging level, one or more Page Images 52 makes
one or more Page Image Sets 51. One or more Page Image Sets 51 make
up the print job 64. Zero or more logical pages 62 in turn maps to
zero or more Page Images 52. Therefore, the present invention
provides that print job information is provided in the form of
references to pages as discussed above with reference to FIG.
3.
[0097] Accepting job data in the form of page objects, as provided
in the present invention, provides significant advantages. Some of
these advantages are:
[0098] (i) because the job data provider does not need to convert
job data into an extra intermediate format, performance is
drastically improved;
[0099] (ii) because the job data provider (i.e. application)
already has written program code to draw to the GDI, the amount of
effort required to adapt printing to support the job editing and
delivery sub system is minimal;
[0100] (iii) because the imaging interface used is the GDI, there
is no need to document or create a proprietary intermediate imaging
representation;
[0101] (iv) the work of creating a conduit (special job data
provider or jab capture subsystem that captures a job from an
existing printing system) is neatly split between the conduit and
the job editing and delivery subsystem. The conduit is responsible
for capturing the job information, transmitting it to a host
application, and providing the job information in page increments
as objects. The job editing and delivery system can, therefore, be
developed independently of the conduit. This enables a great deal
of parallelism in software development and scheduling.
[0102] (v) converting the page is avoided until absolutely needed.
The job editing and delivery subsystem, according to the present
invention, only requests the job data provider to draw the page
when the page absolutely needs to be drawn on the screen, printed,
or converted to a metafile format
[0103] (vi) GDI and COM are Microsoft originated (and endorsed)
technologies and are widely used for the commercial software
development and implementation.
[0104] (vii) The job editing and delivery system is independent of
the imaging model. Therefore, the present invention is equally
adaptable to all the imaging systems that are in use (DDI,
PostScript, etc.) to the extent that they map back to GDI.
[0105] FIG. 8 is a flow diagram that shows the operation of a
preferred embodiment of the job editing and delivery system in
accordance with the present invention. In the preferred embodiment,
the job editing and delivery system has a job capture subsystem and
a job editing and delivery subsystem. In step 800, the job capture
subsystem ("JCSS") is invoked. A JCSS can be invoked on multiple
machines and in multiple address spaces and serves to capture print
job information from the different sources of the print job
information, such as applications, specialized printer drivers or
other server applications. In step 805, the job editing and
delivery subsystem ("JEDSS"), a COM object, is instantiated in one
of the JCSS address spaces.
[0106] In step 810, the JCSS provides the print job information, in
the form of page image references, to the JEDSS. In step 815 the
JEDSS displays previews of selected pages by calling the JCSS and
JCSS draws the page images in step 820 in response to the call from
the JEDSS. Thereafter, the JEDSS provides the user an opportunity
to modify the job settings in step 825.
[0107] IN step 830, the JEDSS checks if any job settings have been
modified, and if so, the JEDSS displays a preview of the relevant
pages with modified job settings by proceding to steps 815 and 820.
If there are no job setting changes in step 830, the JEDSS prints
the page images by calling back to the JCSS in step 840 with the
appropriate device context for printing or writing to metafile.
[0108] In step 840, the JEDSS prepares to print the page images by
calling back to JCSS with an appropriate device context and thereby
providing it instructions on printing or outputting the page
images. The JEDSS provides the JCSS the device context for printing
or storing the pages in a metafile.
[0109] In step 845, the JCSS draws the page images in accordance
with the instructions provided by the JEDSS. For example, if the
JEDSS provides a metafile device context in step 840, the JCSS then
draws to the provided device context. Thereafter, if the JEDSS
obtains a metafile from the JCSS, the JEDSS is then responsible for
translating the metafile to a suitable printer language and sending
to the printer for further processing in step 850. If the JEDSS
provides a printer device context in step 840, the JCSS uses an
existing printer driver which converts the GDI calls made by the
JCSS to the appropriate printer language and sends the job for
processing by a printing system in step 850. In an alternative
embodiment, the job editing and delivery system of the present
invention can itself translate the print job information to an
appropriate printer language and forward for printing. After
processing by the printing system in step 850, the processing cycle
for the job editing and delivery system is completed in step
855.
[0110] In step 850, the printing system either prints the job in
accordance with the device context and job data provided by the
JCSS in step 845 or stores the job in a storage medium for future
processing. The stored job includes the storage of the job
translated to a suitable printer language such as PCL or
postscript.
[0111] It should be noted that, in the preferred embodiments the
print job data edited or modified by a user does not include
directly modifying the imaging data. The print job data modifiable
by user typically includes rotation, translation, and scaling of
images, paper handling and collating features, overlays, underlays,
filters, and the like. A filter can be used to convert a page image
to a metafile and thereafter the metafile can be edited to
indirectly modify the imaging information.
[0112] Other embodiments of the invention will be apparent to those
skilled in the art from a consideration of the specification and
the practice of the invention disclosed herein. It is intended that
the specification be considered as exemplary only, with the true
scope and spirit of the invention being indicated by the following
claims.
* * * * *