Information Management System With Improved Methods and Interface for Printing Data

A portion of the disclosure of this patent document contains material which 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 file or records, but otherwise reserves all copyright rights whatsoever.

The present invention relates generally to information processing environments and, more particularly, to the task of generating a hard copy or "printout" in such environments.

With the advent of the personal computer, the use of computer systems is becoming increasingly prevalent in everyday life. Today, computers can be seen on the desktops of most business professionals. Running software applications such as word processors and spreadsheets, for example, even the average business professional can realize substantial productivity gains. Besides the business environment, computers can also be found in wide use both at home and at school.

In practically all computer applications, the user eventually needs a "printout" of some type. Such printouts or hard copies may take the form of paper printouts, slides, photos, and the like. Desktop users, in particular, prefer to print out information into one of a number of commercially-available formats, including address book formats (e.g., Daytimer), label formats (e.g., Avery), envelopes, and the like. Expectedly, one finds that present-day application software, particularly word processors and PIMs (Personal Information Managers), include the capability to output user data to pre-defined formats, such as those described above.

The present-day approach to the task of printing or outputting information within the constraints of a pre-defined format has distinct disadvantages, however. The problem may be viewed as follows. For any printing task or job, a system must contend with three issues: (1) the actual contents (i.e., the actual user data), (2) how the contents are to be laid out in the final printout, and (3) how individual items within the data contents are repeated. The third item concerns the repeating groups of items to be printed to a sheet of labels--how the individual groups are laid out.

In present day products the user is constrained in how he or she can lay out information in, for example, a label printout. Both WordPerfect.TM. for Windows and Ecco.TM. Pro are typical in this regard. Although each product provides the flexibility to include certain fields (i.e., define a repeating group) for a label printout, the user really has no free hand at specifying how the contents are laid out. In the instance of Ecco Pro, for example, pre-defined templates are provided which basically mandate the layout of the contents. The user is constrained to work within these format pre-defined by the vendor. Quite simply, the user does not have the flexibility to place information content in the layout anywhere he or she really wants.

Additionally, present day systems compromise the actual layout of the labels. For instance, certain commercial formats require data to be printed in a mirror fashion. Here, the page must be, in effect, "flipped over" to print the mirror image. Present-day systems, namely word processors and label-printing programs, do not support this functionality. Part of the problem of these programs is that they do not store (i.e., as their own native data) information about the content which is to be rendered on a label, address book, or the like. Instead, the user data is imported at final print time, for example, via a mail merge operation. This greatly restricts the ability of the user to adjust the layout of the contents since, beforehand, it is not known exactly what kind of data will be received upon import. Using a special envelope-printing function, for instance, the user might set out a very nice layout for an envelope, but at import/print time the actual data received might be too much or too little for the user's design.

What is needed is a system with interface and methods which give users the flexibility to choose how contents are laid out, despite the fact that the actual contents might not be known beforehand. More particularly, such a system should provide the user with the ability to position content in a free-form manner, yet have that data printed out in the appropriate manner for the target commercial form.

The present invention recognizes that users need flexibility in choosing how their data (i.e., contents) are laid out in a formatted printout (e.g., label), despite the fact that the actual contents might not be known beforehand. The system provides a Print Manager having a Form Designer which assists the user with mapping the user data (e.g., "cardfile" or database data) onto a formatted output, such as a commercial form. The Form Designer is a free-hand tool--allowing the user to place fields and other information anywhere on a form (e.g., label) in a WYSIWYG ("what you see is what you get") fashion, using drag-and-drop methodology.

In operation, the user selects a "Print Labels" option, for invoking a Print Dialog. The Print Dialog provides a preferred interface for the user. The Dialog includes ordered steps, separated into separate regions, which the user follows to complete the task. One region allows the user to specify the data to be printed, such as the current card, selected cards, all cards, cards of a particular index range, or the like. Another region allows the user to select a particular style template (e.g., Avery 5267 return address label); feedback is provided by a preview window. A third region allows the user to specify a layout. Here, the user can choose in a free-hand manner how and where contents are to be printed.

Actual content layout is specified by invoking a Setup Contents Dialog. The Dialog includes a work surface having an active region. The active region indicates the current printable region for the currently selected output format (e.g., Avery 5267). Starting with an empty form (i.e., empty active region), the user adds objects to the form, using Button Tools for adding card fields, text objects, graphics, and a stamp. For instance, the user can select fields from the underlying data (e.g., "cardfile" or database), for including them in the form or label to be printed. In this manner, the user can easily select fields to be included in the final printout. In a similar fashion, the user places text objects, graphics, and stamps on the form. All objects can be positioned and modified in a free-form manner: the user can treat each object graphically, including using drag and drop technique and object resizing/repositioning technique. Once the user is satisfied with the arrangement of contents on the label, the user can save the content setup as a "content description." In effect, the user is given complete freedom to "paint" the label with objects, which may then be saved as a content description.

The system maintains, independent of the content descriptions, a set of templates which define print styles or layouts for particular forms, such as envelopes, address labels, and the like. The content description, once created (e.g., by the user or automatically), can be applied against various templates in a generic fashion. The user can cycle through various templates, with the content description being automatically applied against each template. Moreover, the user can modify any particular template, whose definition is maintained independent of the content description.

The present invention therefore provides a Printing Manager with a WYSIWYG Form Designer which allows users to create in a free-form manner a content description, which describes how contents (i.e., user data) are to be laid out in a form. The context description can be generically applied against various templates. Since the content description is maintained independently from the template definitions, each can be independently modified.

FIG. 1A is a block diagram of a computer system in which the present invention may be embodied.

FIG. 1B is a block diagram of a software system of the present invention for controlling the operation of the system of FIG. 1A.

FIG. 2 is a bitmap screenshot illustrating a user interface of a Personal Information Manager in which the present invention is embodied.

FIGS. 3A-K are bitmap screenshots illustrating user operation of the user interface of the present invention.

FIG. 4 is a bitmap screenshot illustrating the user interface of the present invention after user operation.

FIG. 5 is a bitmap screenshot illustrating a "preview" of formatted output, which is generated based on user input.

FIGS. 6A-C are bitmap screenshots illustrating user operation of the user interface of the present invention for selecting different form templates.

FIG. 7 is a block diagram of a Printing System ("Print Manager") of the present invention.

FIG. 8 is a diagram illustrating use of "inner" and "outer" sets of margins.

FIG. 9 is a diagram illustrating a two way split printout with opposite corners.

FIG. 10 is a flowchart illustrating general steps for an overall printing method of the present invention, for directing operation of the Print Manager (of FIG. 7).

The following description will focus on the presently preferred embodiment of the present invention, which is operative in an end-user application running under the Microsoft.RTM. Windows environment. The present invention, however, is not limited to any particular one application or any particular environment. Instead, those skilled in the art will find that the system and methods of the present invention may be advantageously applied to a variety of system and application software, including database management systems, wordprocessors, spreadsheets, and the like. Moreover, the present invention may be embodied on a variety of different platforms, including Macintosh, UNIX, NextStep, and the like. Therefore, the description of the exemplary embodiments which follows is for purposes of illustration and not limitation.

System Hardware

The invention may be embodied on a computer system such as the system 100 of FIG. 1A, which comprises a central processor 101, a main memory 102, an input/output controller 103, a keyboard 104, a pointing device 105 (e.g., mouse, track ball, pen device, or the like), a display or screen device 106, and a mass storage 107 (e.g., hard or fixed disk, removable floppy disk, optical disk, magneto-optical disk, or flash memory). Processor 101 includes or is coupled to a cache memory 109 for storing frequently accessed information; memory 109 may be an on-chip cache or external cache (as shown). One or more input/output device(s) 108, such as a printing device or slide output device, are included in the system 100, as desired. As shown, the various components of the system 100 communicate through a system bus 110 or similar architecture. In a preferred embodiment, the system 100 includes an IBM PC-compatible personal computer, available from a variety of vendors (including IBM of Armonk, N.Y.). I/O device 108 may include a laser printer, such as an HP laserjet printer, which is available from Hewlett-Packard of Palo Alto, Calif.

System Software

A. Overview

Illustrated in FIG. 1B, a computer software system 120 is provided for directing the operation of the computer system 100. Software system 120, which is stored in system memory 102 and on storage (e.g., disk memory) 107, includes a kernel or operating system (OS) 140 and a windows shell 150. One or more application programs, such as client application software or "programs" 145 may be "loaded" (i.e., transferred from storage 107 into memory 102) for execution by the system 100.

System 120 includes a user interface (UI) 160, preferably a Graphic User Interface (GUI), for receiving user commands and data. These inputs, in turn, may be acted upon by the system 100 in accordance with instructions from operating module 140, windows 150, and/or client application module(s) 145. The UI 160 also serves to display the results of operation from the OS 140, windows 150, and application(s) 145, whereupon the user may supply additional inputs or terminate the session. In a preferred embodiment, OS 140 is MS-DOS and windows 145 is Microsoft.RTM. Windows; both are available from Microsoft Corporation of Redmond, Wash. Although shown conceptually as a separate module, the UI is typically provided by interaction of the application modules with the windows shell, both operating under OS 140.

One application software comprises a Personal Information Management (PIM) System 125 which includes a Print Manager and interface of the present invention. In an exemplary embodiment, PIM System 125 includes Sidekick.RTM. 95, which is available from Starfish Software of Scotts Valley, Calif. A general description of the operation of Sidekicks.RTM. 95 can be found in its accompanying user manual. The Print Manager and interface of the present invention, in the exemplary embodiment of Sidekick.RTM. 95, will now be described in further detail.

Free-form Content and Layout Design for Printout to Commercial Formats

A. Basic storage of user data

In an embodiment of the invention in a Personal Information Manager (PIM), a database of information, such as an electronic "Cardfile," already exists. The Cardfile comprises a plurality of "cards." Each card, in turn, comprises a set of data concerning a certain person or thing. These data sets are inherently suitable for use in generating formatted printout, such as labels. In other words, at the outset, the data is separated into distinct data sets. From the Cardfile, the user can define a Cardfile format. Here, the format comprises selected fields from the Cardfile, with the particular fields employed may be user defined. Additionally, the user can apply a filter to select records according to particular data values stored by records. Combining filters with Cardfile formats, the user can select particular fields to be displayed from particular records.

B. Templates

Apart from the underlying storage of user data format are "templates." The templates define print layouts for particular forms, such as envelopes, address labels, and the like. In particular, the templates store layout information about how the contents are to be represented at output, including, for instance, symmetrical, "opposite corner," asymmetrical, and the like. The templates also store header and footer information, including page number and date information. The templates are described in further detail hereinbelow.

C. Free-hand Form Designer

The system provides a Form Designer which assists the user with mapping the user data (e.g., Cardfile or database data) onto a formatted output, such as a commercial form. The Form Designer is a free-hand tool--allowing the user to place fields and other information anywhere on a form (e.g., label) in a WYSIWYG ("what you see is what you get") fashion, using drag-and-drop methodology. This is perhaps best explained by demonstrating use of the Form Designer to create a simple label printout.

FIG. 2 illustrates a user interface 200 of the Personal Information Manager of the present invention; the interface includes vertically arranged cards 210. Detail information for a currently-selected card is displayed upon selection of that card, as shown at 215. For the present example, the information shown includes common 800 numbers. Each card, being an entry or data record by itself, is the type of data which users typically desire to have a hard copy. The process of generating such a hard copy, in accordance with the present invention, will now be described.

FIG. 3A illustrates the initial process of generating a hard copy for information from the Cardfile of FIG. 2. The user begins by selecting File 310 from the program menubar. This invokes a submenu, from which the user can select a Print option 315. This invokes an additional submenu, where the user can simply select to "Print Cards" at 317. Alternatively, the user can print the cards in a formatted fashion, by selecting "Print Labels," "Print Address Book," or "Print Envelope" at 320. For the present example, the user selects "Print Labels."

Upon the user selecting the "Print Labels" option, the system displays a Print Manager Dialog 330, shown in FIG. 3B. The Dialog 330 provides the preferred interface for the user. As shown, the Dialog includes ordered steps, separated into distinct regions, which the user follows to complete the task. The first region 331 allows the user to specify the data to be printed, such as the "Current Card," "Selected Cards," "All Cards," cards of a particular "Index Range," or the like. The second region 333 allows the user to select a particular style template (e.g., Avery 5267 Return Address Label); feedback is provided by a preview window 333. The third region 335 allows the user to specify a layout. Here, the user can choose in a free-hand manner how and where contents are to be printed.

The user specifies content layout by selecting a Setup Contents Button 336. The system, in response, displays a Setup Contents Dialog 340, which is illustrated in FIG. 3C. As shown, the Dialog 340 includes a work surface 341 having an active region 342. The active region 342 indicates the current printable region for the currently selected output format (e.g., Avery 5267). The user can "zoom in" or "zoom out" of the work surface by selecting Zoom Button 343.

Starting with an empty form (as shown by the empty active region 342), the user can now proceed to add objects to the form, using Button Tools 345. As shown, the Tools 345 includes selections for adding card fields, text objects, graphics, and a stamp. If desired, the user can select Hint Button 346, for receiving instructions on how to populate the empty form with appropriate objects.

As shown in FIGS. 3D-E, upon the user selecting the Card Fields Button (of the Dialog 340 in FIG. 3C), the system displays an Edit Label Text Dialog 350, as shown in FIG. 3D. Here, the user can select fields from the database, for including them in the label to be printed. Specifically, the user selects from list 351 and clicks the Fields Button 352, to add particular fields into list 353. As shown in FIG. 3E, for instance, the user has added fields of Category, Company, Tollfree number, and Note. In this manner, the user can easily select fields to be included in the final printout. In a manner similar to that just illustrated for card field objects, the user can place the other object types (e.g., text objects, graphics, and stamps) on the form. After the user is satisfied with his or her selection, the user closes the dialog by selecting the OK Button 357.

The user is now returned to the Setup Contents Dialog, shown at 360 in FIG. 3F. The dialog now includes card fields 361, which correspond to the fields selected in the dialog of FIG. 3E. Since the fields were selected together, they are treated as a single card field element 361.

The user can treat each object graphically, including using drag and drop technique and object resizing/repositioning technique. In FIG. 3G, the user has repositioned and resized the card fields, as shown at 363. Here, the user has complete freedom to move the fields, either as a group (e.g., field group 361) or each one individually (if placed individually), to any desired position on the label. In FIG. 3H, the user has positioned an individual field (i.e., Company) on the label. Instead of grouping card fields together, for instance as done with group 361, the user has placed the Company card field as a separate object on the label.

FIG. 3I illustrates placement of text and graphic objects. By selecting the Text Button 372, the user can easily place text objects on the label, such as text object 371. Similarly, by selecting Graphics Button 374, the user can place graphic objects on the label, such as graphics 373 (e.g., bitmap). The Graphics Button 374 invokes a Graphics Dialog (not shown) for specifying a particular graphics file (e.g., Windows bitmap file). In a manner similar to that shown for the Cardfiles, the user can position these new objects using drag and drop technique; similarly, the user can resize the objects as desired.

As shown in FIG. 3J, the user can select the Stamp Button 380 for placing a stamp object. In response to selecting this button, the system displays a Pop-up List 381, as shown. The list includes default stamps, such as "First Class," "Third Class," "Confidential" and the like. Stamps are typically employed when printing envelopes and, thus, will not be included in the present example (which demonstrates printing labels).

As shown in FIG. 3K, the user can employ property inspection technique for changing the properties of a selected object. For instance, the user can select a card field object by "right clicking" on it, whereupon the system displays an Inspector Menu 385, as shown in FIG. 3K. Here, the user can modify properties relevant to the object, such as font, color, alignment, and the like. Also shown, the user can activate a Grid 383 for assisting with alignment of objects on the label.

Once the user is satisfied with the arrangement of contents on the label, the user can save the content setup by selecting the "Save as" Button (e.g., Button 367 in FIG. 3H). In effect, the user is given complete freedom to "paint" the label with objects, which may then be saved as a particular description. In response to the user saving a content setup or description, the system returns the user to the Print Manager Dialog, shown not at 400 in FIG. 4. The Dialog, now changed, includes a representation 410 of the design which the user has just created. The design is shown in the context of the currently-selected template, here Avery 5663 Clear Labels.

The user can proceed to complete the dialog by completing the fourth region, shown at 420. Here, the user simply specifies printing options, such as the number of times each individual card is repeated, or the number of times each set of cards is repeated. After completing this information, the user has supplied all information necessary for the print job. The user may now proceed to instruct the system to print the labels, by selecting the Print Button 430. Alternatively, the user can choose to first "preview" the printout, by selecting Preview Button 435. A preview view 500 is shown in FIG. 5. The preview view shows the actual card contents applied to the layout. In the card fields, for instance, the field name placeholder is replaced with the actual contents from the underlying data file.

As illustrated in FIG. 6A, the content description just created by the user can be applied against various templates in a generic fashion. In FIG. 6A, the user has selected a different style template at 610, the Dayrunner.TM. Running Mate template. Preview 620 is updated, accordingly. The user can cycle through various templates, with the content description being automatically applied against each template.

As shown in FIG. 6B, the user can modify the template definition itself, which is maintained independent of the context description. Upon the user selecting the Setup Template Button 615 (shown in FIG. 6A), the system displays Setup Template Dialog 630. Here, the user can adjust the template definition, such as setting page margins, label margins, page layout, and the like. Also, the user can modify whether the definition specifies that the label prints on both sides and/or opposite corners. The dialog is closed by selecting the Save as Button 631, for saving the template definition under a particular name. Alternatively, the user can simply cancel the dialog by selecting Cancel Button 633.

FIG. 6C illustrates, in preview mode, printout of the contents with the newly selected template, here Day Runner Running Mate. Thus as just illustrated, the system of the present invention provides a WYSIWYG Form Designer which allows users to create in a free-form manner a content description, which describes how contents (i.e., user data) are to be laid out in a form. The context description is maintained independently from the template definitions and, thus, can be generically applied against various templates.

Internal Operation

A. Modules

As shown in FIG. 7, a Printing system ("Print Manager") 700 of the present invention includes a Cardfile Module (database) 710, a Filter Module (Content Descriptors) 720, Templates 725, and Designer Module 760. Each module will be described in further detail.

The Cardfile module 710 includes a read/write API (Application Programming Interface) 718 for storing and maintaining data files (e.g., electronic Cardfile). API 718 surfaces particular function calls to the Designer 760, thereby allowing the Designer to read from and write to the Cardfile. For generating the printout, the information from the Cardfile module 710 is "filtered" through the Filter Module 720. The Filter Module 720 stores "content descriptors" about the information in the Cardfile fields. For example, the Filter Module 720 stores particular field names from the Cardfile, together with the arrangement of the field which is specified by the user during content setup. The content descriptors in the Filter Module 720 do not store actual content (i.e., user data) from the Cardfile. Nevertheless, information from the Cardfile will ultimately be realized as a hard copy, after appropriate filtering by the Filter Module 720. Arrangement on the hard copy is specified by the Templates 725, which, in a preferred embodiment, include Label Templates 730, Address Book Templates 740, and Envelope Templates 750.

B. General operation

In operation, the Cardfile Module 710 provides raw data to the Designer Module 760. Through the read/write API 718, various fields which comprise the Cardfile can be discerned. The Designer 760 can, therefore, provide an interface 765 to the user which includes fields (i.e., card field objects) which the user selects from the Cardfile. Based on the user's selections, appropriate content descriptors are stored by the Filter Module 720. As previously illustrated, these selections are received by the Designer 760 through print dialogs which comprise the interface 765. The interface allows the user to select a Cardfile (file) and then print that file either as a label, address book, or envelope. Each of these choices in the interface correspond to respective templates 730, 740, 750.

C. Data structures

Before describing methods of the present invention, it is first helpful to examine the data structures employed by those methods. A first data structure, LBPRINT, is employed for storing selections specified by the user. In an exemplary embodiment, the data structure may be created as follows (using the C programming language).

As shown, the data structure stores general printing options the user is able to choose. Each functions as follows.

The LBPRINT data structure, in effect, serves as a session descriptor, for a particular printing session.

Next, a "template" data structure is employed to define various templates. In an exemplary embodiment, both address and label templates are formed from an identical template data structure, LBTEMPLATE. The template data structure can be constructed as follows (in the C programming language).

The data structure stores information defining a template. The particular data members of the data structure function as follows.

The data structure, which defines a single template record, essentially stores two sets of margins. A first set of margins, the label margins, include: top, bottom, left, right, vert, and horz. These form a set of inner margins. A second set of margins, the page margins, are defined in a corresponding manner for the form: fmtop, fmbot, fmleft, fmright, fmvert, and fmhorz. Use of these two sets of margins is perhaps best illustrated diagrammatically.

FIG. 8 illustrates the "inner" and "outer" sets of margins. As shown in FIG. 8, "paper" 800 can be divided into frames or "pages," such as page 810 for a paper divided into four equal sections. Here, paper 800 represents the actual physical paper. The paper can be divided into other frames, such as three horizontal or vertical sections, or two horizontal or vertical sections.

Within each page (e.g., page 810), there exists a plurality of label areas, such as area 820. Between the label areas are the inner set of margins. As shown, for instance, page 810 includes the following margins: horz 831, vert 832, top 833, and bot 834. The paper includes the following outer set of margins: fmleft 841, fmright 842, fmvert 843, fmhorz 844, fmtop 845, and fmbot 846. Here, the outer set of margins define the margins for the particular page or frame, which the paper has been divided into. The use of separate sets of margins is particularly advantageous in a "page flip" layout, such as previously illustrated. In particular, such an approach simplifies determination of layout for the flip or reverse side.

The row and column data members of LBTEAPLATE indicate the number of rows and columns of labels. In FIG. 8, for instance, page 810 includes three rows and two columns of labels. The remaining data members of the data structure serve as flags or booleans. The ifOpposite member is a flag indicating "opposite corners" for a two way split. An example of a two way split with opposite corners is illustrated in FIG. 9. Note, here, that the top frame margin must match the bottom frame margin. The ifBothSides member is a flag indicating that both sides of the paper are employed for printout. In other words, this specifies that the printout is "double sided," and thus affects how pages are sent to the printer. This is supported in different ways by various printing devices, including automatically (i.e., duplex printing) and manually (i.e., the user must manually re-feed the pages). The ifLRMirror and ifTBToggle data members function similarly to the "opposite corners" data member. Here, however, the data members specify that the entire set of margins (not just top and bottom) are employed when flipping over a page. The last two data members are ifRevOrder and ifBindHole. The former serves as a flag which indicates that the page numbering should be reversed (i.e., printed in reverse order). The latter indicates what type of binding holes, if any, is employed for the form. The enumerated types include "same side" and "opposite side." The binding hole type also affects the page order on final printout.

Each object which exists on a form is a "form cell." Each cell, in turn, is described by a FORMCELL record--a descriptor for the object. During system operation, the descriptor is employed as a "filter object," for filtering the Cardfile data into a final printout. In an exemplary embodiment, the FORMCELL data structure may be constructed as follows.

The data structure stores information defining a template. The particular data members of the data structure function as follows.

As shown, type is the first data member. It stores the type of cell, such as graph, label, text, stamp, and the like. The next data member, FieldIndex serves as an index of card fields in memory (in a buffer); this is employed for cells of type "label" (i.e., those with text from card fields). For label fields, the field name for the field will be replaced with the actual contents for that field (from the underlying Cardfile).

The buf data member is a buffer which stores either: (1) the file name of type "graph," or (2) the text of type "label" (text, stamp, or OLE object). The scale data member stores the scale factor for the field, (e.g., such as a scale factor for a bitmap of type "graph"). For cells of type "label," the scale data member stores the total indices of fields. Otherwise, for cell type of "frame," "vertical line," or "horizontal line," the scale data member stores the line size. Size and position of the cell is characterized by a rectangle defined by the left, top, right, and bottom data members. Collectively, these define a particular rectangle. Finally, the font data member stores a value indicating a particular font employed for the cell object.

D. Methods

1. General

As displayed in FIG. 10, an overall printing method 1000 of the present invention, for directing operation of the Print Manager, can be divided into the following general steps. At step 1001, the system displays the Print Manager Dialog, for getting information from the user about what is to be printed and how it is to be laid out. The method then initiates a print session (e.g., initialize globals) at step 1002. The method proceeds to step 1003 to open the database (e.g., Cardfile). Then, at step 1004, the data is retrieved from the database and sorted, as required by the user. At step 1005, the system matches the data through the filters, using the previously-described content descriptors.

After the data matching step, the method still has to figure out how the data are to be laid out on page. Thus, at this point, the method sets up a page sequence, at step 1006. Each page includes one or more cards. For instance, the first page might include cards 1-5, while the second page includes cards 6-10. At step 1007, the method calculates page numbers, as required by the user input. In the template, how a page is split (e.g., two vertical split, three vertical split, opposite corner, and the like) is specified. This information, in turn, dictates how the page number is finally laid out and is employed for mapping a final print sequence.

Finally, at step 1008, the method can initiate the print sequence for the environment. In Microsoft Windows, for instance, this would include appropriate calls to Windows' GDI (Graphic Device Independent) interface for invoking Windows print routines/drivers.

2. Specific methods

The high-level method just described will be examined in further detail by describing particular subroutines or methods of the present invention which are invoked. The high-level method invokes a SortPrintCards method. Although the method sorts a selected printing card range, as needed, the method also serves as a jumping off point to other subroutines. In an exemplary embodiment, the method can be constructed as follows.

As shown, the method is passed a handle to the current Cardfile. For purposes of error recovery, a temporary (temp) version is also maintained as a backup. As its first step, the method determines whether it needs to sort the data at all, by a subroutine call to a GetLbFormatSortInfo method. This call checks the content filter for determining what information there is to sort. If no field name exists in the format at all (e.g., there only exists bitmaps), then the method need not be concerned with sorting data. The result of the subroutine call is stored to SortFlag, a sort flag, at line 19. If, at line 23, there is no information to sort (i.e., SortFlag set to NULL), the method is done and may simply return 0, at line 27. A dialog box can be (optionally) displayed before the return (as shown at line 25). At lines 30-37, the method performs memory allocation (based on number of card field cells), for setting up for the sort.

Continuing on to line 43, the method proceeds to get all cards to be printed. Between lines 44-72, the method checks various flags, for determining whether the selected cards are a "current card," "all cards," particular "selected cards," or cards according to an "index range." In other words, the method determines at this point what subset of the cards are to be printed. At lines 74-81, the method checks whether separate pages are to be selected by index tab (e.g., "800 Numbers" tab). Upon reaching line 85, the method has determined the range of cards to be printed.

At line 86, a "for" loop is established to loop through all cards which are selected for print. At lines 88-94, the method gets the cards which the user selected. At lines 96-99, the method gets the cards which the user marked (i.e., tagged). At line 101, the passed-in file handle is stored to a local variable, fh. Then, at line 104, the method undertakes to read the actual card data from the Cardfile specified by the fh data member. At line 106, a second (nested) "for" loop is established, for adding each card to the index sequence. An "out" label is established at line 119 to "go to" in the event of an error occurring while adding cards (e.g., exceeding the number of cards permissible). At line 121, if the method did not find any cards to print (i.e., TotalLBCards equals 0), the method displays an error message at line 122. Otherwise, at least some cards have been found to print and therefore no error message will be displayed.

At lines 125-131, local cleanup is performed, such as freeing memory resources and resetting the screen cursor (e.g., from the "wait" or hourglass cursor). At lines 132-140, the method tests whether the user aborted the print job. In the instance where the user has aborted the job, the method returns 0, after reinitializing/resetting global data members. Otherwise, the method has reached line 141 without error and, as a result, has appropriately setup global data structures and may return the total number of cards to print.

The call to the AddLBCard subroutine (which occurred at line 108 above) will now be described in further detail. In an exemplary embodiment, the method may be constructed as follows.

As shown, the method is invoked with five parameters. The first two parameters are the previously-described file handles. The third parameter is a sort flag, for indicating "with" or "without" sorting. The fourth parameter is a pointer to a location in memory which stores the cards. The fifth parameter is a handle to a memory buffer, which is employed as a temporary storage area.

The steps of the method are as follows. At line 16, if the particular card is blank, then it is ignored; the method at this point simply returns "true." The card will not be added to the temporary Cardfile, which is employed for printing. After some memory allocation operations (lines 18-25), the method will get the content setup in the filter, from matching cells with appropriate Cardfile data. At line 34, the method gets the start (offset) of each field in the card (in memory). Then, at line 37, a "for" loop is established for looping through all card field cells. At line 39, the method gets the index for the cell, then at line 42, it fills one cell (buffer). At line 45, the method reads how many fields exists for the cell, then at line 47 it grabs the actual data for the cell.

At line 49, the method tests whether the number of fields present in the cell is greater than 1. If so, then, at line 54, a "for" loop is established for determining how many lines (e.g., lines of text) exists for the cell. This is done by grabbing the data from the card and matching it to the cell (lines 61-98). Blank lines may be (optionally) skipped (line 113), depending on the user's preference. At lines 122-143, the method saves the cells content out to a temporary file. If an error occurs (e.g., disk full), the method returns "false." Thus up to this point, the method has grabbed the field and its corresponding filter in order to get the corresponding data into the field; this is saved out to the temporary file.

At lines 147-150, the method will skip the current card if it is blank and the user has selected to "delete" or "skip" blank cards. At lines 153-158, the cards can be sorted into a different sequence than is specified by the default sort. The method establishes at this point, therefore, the sequence for the card field. Finally, the method inserts the card into its proper location, according to its key field content (line 189). The total number of cards is incremented at line 193, and the method returns "true" as line 197.

While the invention is described in some detail with specific reference to a single preferred embodiment and certain alternatives, there is no intent to limit the invention to that particular embodiment or those specific alternatives. Thus, the true scope of the present invention is not limited to any one of the foregoing exemplary embodiments but is instead defined by the appended claims.