Facsimile and static presentation processing – Static presentation processing – Emulation or plural modes
Reexamination Certificate
1996-06-06
2001-07-31
Mancus, Joseph (Department: 2624)
Facsimile and static presentation processing
Static presentation processing
Emulation or plural modes
C358S001150
Reexamination Certificate
active
06268924
ABSTRACT:
FIELD OF THE INVENTION
This invention relates to methods and systems for programmatically controlling printing of documents by associated application programs on a computer.
BACKGROUND AND SUMMARY OF THE INVENTION
Computer documents generally have formats which are specific to a particular application program (e.g., Microsoft® Word, Microsoft® Excel, etc.) with which they are created. By convention, the documents' file names have a three letter extension which identifies their file format and associated application program. For example, Microsoft® Excel spreadsheet documents have an “.xls” file name extension. Drawing documents created in Shapeware Corporation's VISIO® drawing application program have a “.vsd” file name extension.
These often proprietary format documents typically can only be printed correctly by their associated application program. Users therefore usually print documents by interacting directly with the documents associated application. This requires the user to perform several steps, including: identifying, finding and launching the associated application; opening the document in the application; setting print options; and activating the application's print feature. For the user to avoid this tedious sequence of steps, it often is desirable to allow another computer program (e.g., the operating system or a printing utility) to control printing by the documents associated application. Programmatic printing refers to capability of a computer program (typically the operating system shell, but also other computer programs) to cause a document's associated application program to print the document on a printer.
Various forms of programmatic printing have been available in computer operating systems which provide a graphical user interface (GUI), e.g., Microsoft Windows® 3.x/95/NT, Apple Macintosh, IBM OS/2, and NewWave. In one or more of these operating systems, the user has been able to drag (e.g., using a mouse) an icon representing a document's file from folders of a file system onto an icon representing a printer to cause the associated application to print the document on the printer. The user thus reduces the multiplicity of steps otherwise required to print a document to a single drag and drop of a document icon with the mouse.
The designs of the programmatic printing features in these prior operating systems, however, have had certain deficiencies. In the Microsoft Windows® operating system for example, the operating system shell (i.e., the program which provides the operating system's graphical user interface) implements programmatic printing using a shell execute command. Shell execute commands are text string commands (e.g., MS-DOS commands) issued to the operating system command interpreter (i.e., the “command.com” program in Microsoft Windows®). The operating system includes a registry database which maps a document's file name extension to a particular application, and also maps the application to a particular shell execute command for printing the document. For example, the following sample registry entries in Microsoft Windows® 95 map the file name extension of Microsoft® Word documents (i.e., “.doc”) to a shell execute command:
HKEY_CLASSES_ROOT\.doc wordfile
. . .
HKEY_CLASSES_ROOT\wordfile\Shell\print\Command
c:\winword\winword6.exe -p %1
Thus, in response to the user dragging a Word document icon onto a printer icon in the Windows graphical user interface, the Windows shell maps the document's “.doc” file name extension to the text string “c:\winword\winword6.exe -p %1” from the above sample registry entries. The shell then substitutes the document's file name for the “%1” argument of the text string, and issues the string as a shell execute command to the Windows command interpreter. This command directs the command interpreter to load the Microsoft® Word executable program, and to pass the print flag (“-p”) and the document's file name to the program as command line arguments. These command line arguments direct the Word program to print the document when the program begins executing.
A drawback to programmatic printing with the shell execute command is that it is essentially a one-way, “throw over the fence” mechanism. That is to say, once the Windows® shell or other controlling program initiates printing with a shell execute command, it has no further control of the application program which performs the print operation and it receives no information back from the application on the progress, success or failure of the print operation. Thus, the controlling program cannot report the status of the print operation to the user, and cannot suspend, cancel, or otherwise affect or control the print operation once initiated. When launched from a shell execute command, the associated application generally does not provide a user interface for controlling the print job. (Applications launched with a print flag as a command line argument generally are expected to print the specified document without user interaction.) Thus, the print job typically can only be canceled by the printer's driver program (e.g., through a separate print manager utility program which interacts with the printer's driver), or by physically turning the printer off.
Since there is a lack of sufficient feedback from the application when the print operation completes, the controlling program also cannot terminate the application after the print operation is complete, but instead must rely on the application program to terminate at print operation completion. The programmatic printing feature of the Windows® operating system assumes that application programs which are launched with a print flag as a command line argument will terminate after the print operation completes. However, only about half of the application programs which accept a print flag as a command line argument actually are designed to terminate when the print operation completes. Those applications which are not designed to terminate at print operation completion continue consuming computer resources (i.e., memory, processing cycles, etc.), although no longer in use, until terminated manually by the user.
The prior programmatic printing feature using the shell execute command also has the flaw that the shell has no control over the associated application displaying its user interface. Once the shell execute command is issued, the associated application takes over and can display graphic elements, such as a starting graphic while loading, the application's print options dialog, or a complete application window. The Windows® shell assumes that applications which are loaded with the print flag as a command line argument do not display graphic elements. Many applications, however, violate this assumption. The graphic elements they display can obscure other work the user is performing with the shell, and are generally unexpected by the user. When the user drags a document icon onto a printer icon, the user often understands only that they are working in the Windows® shell program and may not realize that the actual print operation activated by the drag and drop action is being carried out behind the scenes by the document's associated application. The display of graphic elements by the associated application destroys this illusion, and typically is not the expected result of the user's drag and drop action. The graphic elements also may obstruct the user from performing other work in the shell.
Another drawback to the shell execute programmatic printing feature is that the Windows® shell has extremely limited control over the actual print operation. In fact, the only direct control that the shell has over the print operation is which document is printed by its associated application. The mapping from file name extension to shell execute command allows the shell to specify only the file name of the target document to the application. The mapping to a shell execute command does not allow the shell to
Atkinson Robert G.
Brown Nathaniel
Koppolu Srinivasa R.
Pearson Matthew William
Wolf Richard J.
Klarquist Sparkman Campbell & Leigh & Whinston, LLP
Mancus Joseph
Microsoft Corporation
Tran Douglas
LandOfFree
Document object having a print interface for programmatic... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Document object having a print interface for programmatic..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Document object having a print interface for programmatic... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-2536299