EP1402430A2

EP1402430A2 - Methods for rendering data and data structures

Info

Publication number: EP1402430A2
Application number: EP01939208A
Authority: EP
Inventors: David Tolpin; Nikolai Grigoriev
Original assignee: RenderX Inc
Current assignee: RenderX Inc
Priority date: 2000-05-19
Filing date: 2001-05-18
Publication date: 2004-03-31
Also published as: WO2001090918A2; WO2001090918A3; AU2001264751A1

Abstract

A table is received having one or more cells where each cell may span one or more columns and one or more rows. The table is represented as a grid where the grid houses the cells. Moreover, a generic table is provided and represented by one or more formatting commands, which are operable to provide a rendering of the grid to an output media. Footnote citations and non footnote data are received and inserted into a unit of media at a beginning location within the unit of media. If a footnote citation is detected, insertion into the unit of media is interrupted and the area associated with receiving the non footnote data and the footnote citation is inverted within the unit of media such that the footnote bodies are received and inserted into the unit of media at the beginning location. After insertion of the footnote bodies is complete, the area associated with receiving the non footnote data and the footnotes citation is restored such that the non footnote data and the footnote citation are located at the beginning location within the unit of media..

Description

METHODS FOR RENDERING DATA AND DATA STRUCTURES

FIELD OF THE INVENTION

The present invention relates to methods for rendering data and data structures such as tabular data and footnote data and delivering the data in a variety of media.

BACKGROUND OF THE INVENTION

The standardization of communication protocols and data formats has permitted the World-Wide Web (WWW) and the Internet to revolutionize the manner in which electronic communications occur. Web browsers (equipped with the appropriate external viewer plugins) such as Internet Explorer, Netscape, and the like facilitate the viewing of various data formats on display screens. Further, external viewers such as Adobe Acrobat and the like, may facilitate viewing data formats on display screens independent of web browsers. Moreover, there are a variety of data formats not directed to viewing data directly on a display screen but, rather, directed to formatting electronic data prior to delivering the data to another device (e.g. printer, and the like). Additionally, a variety of translation or software languages permit data formats to be converted from one data format to another, or permit data formats to be enhanced in some way by altering the presentation of the data when displayed. Some of these translation languages and data formats include by way of example only,

Hypertext Markup Language (HTML), PostScript (PS), Portable Document Format (PDF), Standard Generalized Markup Language (SGML), Printer Control Language (PCL), Extended Markup Language (XML), Extended Stylesheets Language (XSL), Wireless Markup Language (WML), and the like. Additionally, the delivery of information has become omnipresent in recent years with the advent of the Internet and the WWW. Moreover, browsers and viewers, which permit the information to be displayed, are now standard with any computing device acquired by a consumer today. By way of example only, some of the WWW browsers include Netscape, Internet Explorer, and others. These browsers are equipped with external viewer plugins, which facilitate viewing data in a variety of formats. Information used within a browser is often referred to as browser media. Other types of media, such as paged media exist as well. Furthermore, a wide variety of data formats permits defining non-text data types, these data type definitions allow viewing graphics, images, video, audio (listening), and the like. Recently, many viewers (made operable with traditional browser via plugins) have been developed to permit the displaying of data formats on any communications device, such as wireless phones, hand-held computing devices, car computing devices, appliances, stand alone printers, digital video, digital cameras, and the like.

Information viewed in a browser is optimally formatted, or rendered to be displayed, and traversed within the browser (e.g. within the browser media environment). Yet, that same data is not optimally viewed when it is transferred to a paged media. For example, a table of data viewed in a WWW browser may be displayed to user on a single screen, with or without the need to scroll the display screen viewer to the right or down to view the entire table. However, if the same table is selected for print and sent to a printer (e.g. paged media) from within the browser, the table may not reside on a single page when printed. In fact, the table may be truncated with information missing altogether from the table, or information will be separated on multiple pages making it extremely difficult to discern the tabular data provided. This problem of transferring data from a browser or a viewer to a printer is not uncommon and is not limited to tabular data.

In fact, anyone who has selected what appeared to be well formatted information for printing in a WWW browser, is often astonished to discover that once the information is outputted to a paged media from the printer, the information is no longer suitable for viewing. Users may be forced to change the page setup within the printer, select landscape modes, and a variety of other choices in an attempt to get a paged media version of what they are currently viewing in a browser media on their computing device's monitor. Yet, modifying printer options will rarely fix the rendering problem associated with tabular data when tabular data is migrated from one media to another media.

Furthermore, footnote data when viewed in a WWW browser may include a hypertext link associated with a footnote citation, and when this link is activated the footnote body associated with the footnote citation becomes viewable, either in a separate popup window, or within the same browser window. Although this is optimal and efficient for browser media, it is not feasible when the footnote data is transferred to print media, since any link would have to be manually traversed within the printed document by the user. In fact, often when footnote bodies are printed from a browser media, all of the footnotes occur at the end of the document, rather than at the end of each page wherein a corresponding footnote citation matching a footnote body occurs. This is cumbersome, especially if a user only desires to view a few pages of a publication in printed form. Furthermore, users typically desire, when reading a printed page, having the start of a footnote body present on the same page in which the corresponding footnote citation occurs. It is more efficient for the user, when referring to the footnote body on a printed page, to have the«footnote citation occur within the text of the same page as its concomitant footnote body.

Reconciling browser media and page media is problematic, particularly when attempting to render tabular data or footnote data from a browser media to a paged media. This is so, because often the cells of a table, housed in a browser media data format, such as Hypertext Markup Language, and others, have dimensions and presentation attributes which will exceed the dimensions of a sheet of paper which is to include the cells of the table in an output paged media.

Further, Footnote bodies may be physically kept separate from the text within which the corresponding footnote citations occur. As a result, even changing the options associated with a printer will do little to resolve the problem of merging footnote bodies with the appropriate footnote citations when printing footnote data. To solve this, and many other problems associated with data presentation, an industry wide consortium developed a series of data format standards designed to assist in the transition of data being displayed in different media. One primary standard is XML, which displays data in terms of its content devoid of any presentation attributes. Raw XML is not particularly useful in the displaying or the presentation of data in a browser or a paged media by itself, rather, the XML is useful in divorcing the proprietary presentation associated with each media from the data markup, thereby requiring each media to render the raw XML into a useful format prior to displaying it to a user. A number of rendering languages and standards have emerged to assist in this effort, such as by way of example only XSL, Extensible Stylesheets Language Transformations (XSLT), Cascading Style Sheets (CSS) and others. These rendering languages provide guidelines and utilities to take raw XML and render it to a useful presentation format for a particular media. Yet, even with the design consistency associated with a standard data format (e.g.

XML), and a variety of additional rendering utilities and guidelines (e.g. XSL, XSLT, CSS), tabular data and footnote data still present a number of difficult problems when attempting to transfer the tabular data or footnote data from a browser media to a paged media, since the table dimensions associated with a browser media will significantly vary in the paged media and since the footnote citations may be stored separately from the footnote bodies within the data being rendered and a single page must have at least the begirming of a footnote body on the same page in which the corresponding footnote citation occurs.

Therefore, a single application used to successfully render tables in both browser and paged media has proven to be elusive. Moreover, it would be cost prohibitive to provide individualized rendering translations for legacy browser media tables in order for them to be successfully transferred to paged media. Accordingly, a more generic approach needs to be developed such that tables may be rendered automatically from one media to another media without the need for individual translating applications.

Furthermore, present techniques to render footnote bodies on the same page wherein a footnote citation occurs, include inefficient techniques which require continuous iterations of computations to adjust the areas on a page associated with non footnote data and footnote bodies. In prior techniques, as footnote bodies are added to the same page previously placed footnote citations drift to the top of the page, requiring complex iterative recalculations of ihe positions of the footnote citations and the footnote bodies within the page. This is necessary to avoid the possibility that a previously placed footnote citation that has a corresponding footnote body already rendered on a page, will not drift to a previous page as the footnote body data increases on the page. Accordingly, more efficient techniques for rendering footnotes are needed.

Additionally, manipulating data formats and customizing document layouts for display devices, printing devices, and other devices are problematic because often a document needs to populate a specific output layout and, therefore, providing this layout for a wide variety of disparate data types such as text, graphics, images, footnotes, audio, video and the like, generates a significant amount of data presentation errors. The result is that although a data format was translated from one format to a format useable by a requesting user, the resulting display of that translated data is of almost of no value to the requesting user because the translator used to provide the layout could not adequately address how disparate data types co-exist on the rendered electronic media. These complex layouts are often somewhat better handled by batch programming utilities that can store and better calculate how a document layout is to appear when being translated from one format to another format. Yet; even these batch-programming utilities still largely perform canned operations that result in the layout or presentation of the translated data being largely corrupted from the original data format.

SUMMARY OF THE INVENTION

Accordingly, an object of the invention is to provide methods for rendering tables, footnotes, and data to output media regardless of the complex data layouts required.

Moreover, the rendering may be performed in stream as opposed to in batch mode resulting in improved performance and efficiency. This permits users to truly realize the benefits of seamlessly transitioning between multiple media environments without a loss in presentation or performance during the transition. To accomplish this and other aspects of the present invention, cells of a table are parsed and stored in a grid, cell dimensions are calculated based on the dimensions of the target media and based on each cellDs relative position to other cells within the grid. Further, formatting commands are provided to render the cells to a target media wherein the commands may be executed in parallel, producing improved performance. Moreover, the formatting commands when executed produce a rendering of the table on the target media. Further, footnote data are recognized and parsed from an initial source media. An output media, whereto the footnotes are to be rendered, is associated with a unit of the media having definable dimensions. Data, which are not footnote bodies, are populated into the unit of media in a resizable area, beginning at the start of the unit of media. When a footnote citation is encountered, the data, which are not footnote bodies, are inverted on the unit of media and the footnote body data associated with the footnote citation are inserted into the unit of media at the start of the unit of media.

Upon completion of the footnote body, the footnote body is inverted, and the data, which are not the footnote body, are restored to their original location within the unit of media. When the unit of media becomes fully populated, the footnote bodies are adjusted so the bodies occur in the proper sequence within the unit of media.

In this way, it will become apparent to those skilled in the art, that should a unit of media become fully populated during insertion of a footnote body, any remaining data associated with the footnote body may be easily migrated to the next unit of media. Moreover, by inverting the unit of media, iterative recalculations become unnecessary. Further, inversion may be achieved, by way of example only, with simple pointers to locations within the unit of media associated with resizable insertion areas, such that performance of rendering footnotes is greatly improved over existing techniques.

Additional objectives, advantages and novel features of the invention will be set forth in the description that follows and, in part, will become apparent to those skilled in the art upon examining or practicing the invention. The objects and advantages of the invention may be realized and obtained by means of the instrumentalities and combinations particularly pointed out in the appended claims. To achieve the foregoing and other objects and in accordance with the purpose of the present invention, methods for rendering data and data structures are provided.

In one aspect of the present invention, a set of executable instructions to generically render a table for output processing is provided, comprising receiving a table having one or more cells wherein each cell spans one or more columns and rows. Further, the table is represented as a geometric grid wherein one or more positions within the grid house one or more of the cells and providing a generic table represented by one or more formatting commands operable to provide a rendering of the grid to one or more output media.

Moreover, a set of executable instructions operable to produce formatting commands to render a table is provided, comprising decoupling one or more cells from a table and storing the cells in a matrix. Furthermore, a dimension associated with each cell is expressed in terms of each cellDs relative position to one another within the matrix. Next, one or more formatting commands operable to produce a rendition of the table on an output media from the matrix are outputted.

Further, a set of executable instructions operable to produce a rendition of a table is provided, comprising representing one or more cells of a table with one or more executable commands wherein each command has one or more parameters defining an outputted cellDs dimensions on an output media. Moreover, the commands are executed in parallel to produce a rendition of the table on the output media.

In another aspect of the present invention, a set of executable instructions for inserting footnotes into a media is provided, comprising receiving non footnote body data and footnote body data, wherein the non footnote body data are inserted into one or more first locations within a media. Moreover, the non footnote body data are inverted to one or more second locations when the footnote body data are inserted into the media. Further, the non footnote body data are restored into the first locations with the footnote body data occupying at least one or more of the second locations.

Also, a set of executable instructions operable to render footnotes is provided, comprising receiving data including non footnote data and footnote data having footnote citations and footnote bodies. The non footnote data and the footnote citations are serially inserted into a media. However, insertion is interrupted when footnote citations are encountered, and a start location and an end location associated with a unit of the media are inverted such that the end location houses the non footnote data and the footnote citations while the footnote bodies are inserted serially at a start location within the unit of media. After the footnote bodies are inserted into the media, the start and end locations are swapped such that the non footnote data and the footnote citations are located at the start location and the footnote bodies are located at the end location.

Furthermore, a set of executable instructions operable to manage the rendering of footnotes is provided wherein an entry path for receiving footnote body data is associated with a unit of media. Moreover, a second path for receiving non footnote body data is associated with the unit of media. Further, a first location associated with the second path is reversed with an ending location associated with the entry path for purposes of inserting the footnote body data into the unit of media.

In yet another aspect of the present invention, a method of electronically rendering data on a computer readable medium is provided, comprising receiving one or more data objects including text objects and floating objects generating floating areas to house the floating objects. The floating areas are outputted at predetermined locations and textual areas are generated to house the text objects, these textual areas comprising an outputted area where the floating areas have been removed, the text objects are then output adjacent to the floating areas.

Moreover, a system for electronically rendering data on a computer readable medium is provided, comprising one or more text objects, one or more floating objects, and a set of executable instructions operable to create and output data by dividing from input data a set of textual areas and a set of floating areas and operable to populate the textual areas with the text objects and the floating areas with the floating objects.

Finally, a method of electronically providing a footnote body on a page in a computer readable medium is provided, comprising identifying one or more page objects including reference objects and body objects, generating a body area located at the bottom of a page to house the body objects and generating a reference area located above the body area to house the reference objects. Next, geometric rectangles are formed to house the reference and body areas such that the body area is expanded to accommodate an additional body object while the reference area is decreased and an overall area associated with the page remains constant. Still other aspects of the present invention will become apparent to those skilled in the art from the following description of a preferred embodiment, which is by way of illustration, one of the best modes contemplated for carrying out the invention. As will be realized, the invention is capable of other different and obvious aspects, all without departing from the invention. Accordingly, the drawings and descriptions are illustrative in nature and not restrictive.

BRIEF DESCRIPTION OF THE DRAWINGS

THE ACCOMPANYING DRAWINGS INCORPORATED IN AND FORMING PART OF THE SPECIFICATION, ILLUSTRATE SEVERAL ASPECTS OF THE PRESENT INVENTION AND, TOGETHER WITH THEIR DESCRIPTIONS, SERVE TO

EXPLAIN THE PRINCIPLES OF THE INVENTION. IN THE DRAWINGS:

Fig. 1 depicts a flow diagram of a method of rendering tables;

Fig. 2 depicts a flow diagram of a method of producing formatting commands to render tables; Fig. 3 depicts a diagram of a table and a grid;

Fig. 4 depicts a block diagram of synchronizing the rendering of a table;

Fig. 5 depicts a flow diagram of a method of rendering tables;

Fig. 6 depicts a flow diagram of a method of rendering tables to an output media;

Fig. 7 depicts a block diagram of a method to output cells associated with a table; Fig. 8 depicts a flow diagram of a method of inserting footnotes to a media;

Fig. 9 depicts a flow diagram of a method of rendering footnote data; Fig. 10 depicts a flow diagram of a method of managing footnotes rendered to a media;

Fig. 11a depicts a block diagram of an initial unit of media with no footnote body data;

Fig. 1 lb depicts a block diagram of a unit of media receiving an initial footnote body data;

Fig. l ie depicts a block diagram of a unit of media receiving non footnote body data;

Fig. l id depicts a block diagram of a unit of media fully populated;

Fig. 12 depicts a schematic state transition table associated with Figs. 4a-4d; Fig. 13 depicts a flow diagram of a method of rendering data;

Fig. 14 depicts a flow diagram of a method of rendering data;

Fig. 15 depicts a diagram of a system of rendering electronic data;

Fig. 16 depicts a block diagram of electronic data;

Fig. 17 depicts a transition diagram of rendered electronic data; Fig. 18 depicts a block diagram of electronic data;

Fig. 19 depicts a transition diagram of rendered electronic data;

Fig. 20 depicts a diagram of wrapping text;

Fig. 21 depicts a flow diagram for rendering footnotes; and

Fig. 22 depicts a transition diagram for rendering footnotes.

DETAILED DESCRIPTION

The present invention provides methods for rendering tables. One embodiment of the present invention is implemented using web browser technologies including well-known software programming languages (e.g., C, C++, Java, Active X, Active Server Pages, XSLT, Xpath) and Internet communication protocols (TCP/IP). Of course other programming languages and communications protocols (now known or hereafter developed) may be also readily employed.

TABLE DATA STRUCTURES

Initially, at table is detected within a stream of data or a file by a set of executable instructions operable to detect a table within the data or the file. By way of example only, consider a file with a data markup utilizing XSL where tables are distinguished with a tag such as "<fo:table>", once detected the context of the table is pushed to a stack structure within the executable instructions wherein the information regarding the table will be trapped and appropriately recorded. After a table is detected, the structural pieces of the table are decomposed and parsed by the executable instructions, to identify table cells, columns, rows, headers, and footers. Internally, the individual cells of the table and the requisite information associated with the table, such as number of cells, size of cells, data associated with the cells, and others are stored in a grid, or matrix (e.g. a single or multiple dimensional array). Although as one skilled in the art will appreciate, any internal data structure would suffice as long as the information associated with the table is readily ascertainable. For example, the cells and information associated with the cells could be stored as a binary tree, a hash table, a linked list, or combinations of these and other data structures.

Within the data structure, housing the parsed cells of the table, each cell will carry information that identifies its positions within the table. For example, consider Fig. 3 where an initial table 160 is identified. Table 160 includes 5 cells, cell 1 180, cell 2 190, cell 3 200, cell 4 220, and cell 5 210. Moreover, by way of example only, consider that table 160 is represented in a data markup compliant with XML and includes XSL that renders table 160 to a WWW browser media. Once the XSL file is provided to executable instructions of the present invention, the cells of table 160 are parsed and housed in an internal data structure similar to grid 170.

The dimensions of grid 170, in terms of its length and height may be dictated by the size of the media to which a rendering is to occur. By way of example only, if grid 170 was being used to render to paged media wherein the size of the page was to be 8 Vi by 11 inches with ^l inch margins on all four sides of the page, then the number of equal sized cells within the grid 170 could be readily determined and configured. Although, as one skilled in the art will appreciate, the number of equally sized grid 170 cells may be determined, by attributes associated with the parsed table 160, such as number of columns encountered and number of rows encountered during parsing. Furthermore, some tabular information contained in the pre-parsed table may identify the exact number of columns and rows associated with the table being parsed.

Once, the number of cells are known, the grid 170 is instantiated and each parsed cell inserted into the grid 170 along with each cell's dimensions with respect to the other cells within the grid. For example, grid 170 includes 9 cell locations of equal size, and cell 1 180 of table 160 has original dimensions which indicate that this particular cell occupies two rows of table 160 and a single column. Therefore, grid 170 depicts a new cell 1 230 within the newly generated grid 170 having the dimension information of "[0,0]" and "[1,0]. " The dimension information "[0,0]" indicates that cell 1 230 in grid 160 occupies the first row "0" of the grid 170 and the first column "0" of the grid 170.

Furthermore, the dimension information "[1,0]" indicates that cell 1 230 in grid 170 occupies the second row "1" of grid 170 and the first column "0" of the grid 170. In a similar way, dimension information is carried with grid 170 for each of the five cells originally depicted in table 160. As one skilled in the art will appreciate, once the cells and their relative positions are recording in a generic data structure, such as by way of example only, the grid 170 of Fig. 3, rendering the table 160 from the grid 170 becomes a much easier task. Moreover, once the table is represented within the grid 170 modifications may be made to the size of the grid, if desired, such that the table may be rendered to a variety of different media, with each media having varying dimensions. For example, if grid 170 was being used to render table 160 to a standard sized paper, as described above, and later a desire existed to render grid 170 to a legal sized paper, the grid 170 could be automatically adjusted to accommodate this desired transition. As one skilled in the art will appreciate, no additional parsing need take place once a single grid houses the cells of a table along with the relative positions of each cell to one another within the grid.

Furthermore, once a grid is constructed housing the cells of a table, formatting commands may be generated such that the cells may be drawn to a paged media in parallel, to improve performance of fully rendering a complete grid to a paged media. For example, commands may be outputted which are operable to draw each cell independently of other cells, and the execution of each of these drawing commands may be run in parallel, since there is no longer any rows or columns to be concerned with once a grid is produced. Synchronization of the cells may be achieved at different points within the outputted pages, such that commands which draw the cells are executed once a particular cell has its individual top edges determined.

Fig. 1 depicts one example of a flow diagram of a method for rendering tables. A table is received in step 10; tables may be received in a variety of ways, such as by way of example only, from an application, from a file, and others. The format of the table may be in any consistent markup language, which permits the parsing of the table to acquire table information, such as by way of example only, number of rows, number of columns, cell dimensions (e.g. number of columns or rows spanned), data associated with each cell (e.g. text, image, video, audio, and others). As previously discussed, and used for purposes of illustration only, a table may be received in XML or XSL compatible formats and will be readily identified. Once a table is detected, the cells of the table are parsed in step 20. Parsing text data is well known in the art and a variety of languages exist to assist in automatic parsing, such as by way of example only, C, C++, Perl, Flex, Lex, Yacc, and others. Once the cells of the table are acquired along with any dimensional information that was parsed with the cells from the table, the size of each cell and the number of cells within a grid may be determined, and the relative positions of each cell in step 30 may be calculated.

As previously discussed, the size of the grid may, and the number of cells within the grid may, be determined by the media to which the grid is to be rendered, such as a printed page, or it may be ascertainable from information parsed from the table, such as total number of rows, columns, number of columns spanned, number of rows spanned, and others. Moreover, if a cell has a fixed width within the parsed table, this may be useful in determining the size of the grid, by subtracting from the known size of the grid all the fixed width cells and then distributing the remaining width of the table to the remaining cells. Furthermore, the size of the grid may be configurable by a user such that a manual indication may be used when calculating the size of the grid and the number of equally sized cells with the grid.

Moreover, a grid is used for purposes of illustration but as one skilled in the art will appreciate any data structure would suffice, or combination of data structures. In the present example, the grid may be represented as a double dimensional array, such that access to any particular location within the grid is acquired by referencing two separate indexes where one may be considered indicative of a row and the other indicative of a column within the grid. The data housed within the grid may be represented as a structure, which includes positional information and the data associated with the grid. Although as one skilled in the art will appreciate, the dual index into the arrays is sufficient to discern a cells relative position within the grid and no further information need be carried within the structure associated with a particular location within the grid.

Once the relative positions are determined, the cells and their corresponding data are inserted into the grid in step 40. At this point in time, if not already obtained, the output dimensions associated with a media to which the grid is to be rendered may be received in step 50 and the grid may be reorganized to reflect the appropriate dimensions of this out media. Next, formatting commands are generated in step 60, these commands are operable to draw the cells associated with the grid to the desired media. A variety of programming languages both standard and ad hoc would readily permit such commands to be outputted. For example, PDF, PCL, and other languages both standard or hereinafter developed permit standard executable commands to be generated which will draw lines, circles, and other shapes by instructing a printer to cause ink to be sprayed or displayed on a page. These commands require only dimensional information to be supplied as parameters, which permit such shapes to be drawn on a page. The dimensional information is readily calculated from the grid based on the size of the output page, and each cell's relative position within the grid, as previously presented. With formatting commands to draw or render each of the cells within the grid, these commands may be executed to render an originally received table to an entirely different media in step 70. These commands, as will be discussed in greater detail below, may be executed in parallel to render the grid optimally to a printed page.

Fig. 2 depicts one flow diagram of a method for producing formatting commands to render tables. A table is parsed in step 80 and each cell within the table is identified in step 90 and pushed to an internal grid in step 100, as previously presented. The grid is adjusted once all cells are received and an output media dimension is known. In step 120, formatting commands to render the grid to an output media are generated for each cell within the grid.

Once the formatting commands are acquired for each cell within the grid, a dispatcher set of executable instructions may drive the execution of each cell to the output media by forking the execution of each cell which has its top border determined in step 130. The dispatcher may associate with each cell a synchronization marker, such that every cell which starts and ends at a same height have the same synchronization markers, and rendering the cells to the output media is synchronized in step 140. Furthermore, once the table is completely represented by independent cells within a grid and associated with independently executable formatting commands, the concepts of rows associated with a table or columns associated with a table are no longer needed, rather, cells may be drawn or rendered to an output media, in parallel with synchronization occurring via a dispatching set of executable instructions. After each cell has been drawn, the original table is completely rendered to an output media in step 150.

As one skilled in the art will appreciate, the ability to independently draw cells of a table to a paged media directly from an original table presented in a browser media, presents a number of advantages for users. In fact, print publishers, and advertisers would save substantially in expenses associated with reformatting browser-based tables for printed publications or reproduction on other media. Moreover, since the execution for drawing the cells to a printed page may occur in parallel, performance associated with the transition is also greatly improved with the present invention.

Fig. 4 depicts one block diagram of synchronizing the rendering of a table. A dispatching set of executable instructions 280 is initially prepared to execute formatting commands associated with drawing the cells of a grid in a paged media. At the outset, only cells 1 330 and 2 340 may be executed simultaneously since each of these cells share the same synchronization marker 290. The examples depicted in Fig. 4 correspond to the table 160 and the grid 170 of Fig. 3.

Initially, the top most border of only cell 1 330 and cell 340 are determined, and correspondingly the dispatcher 280 forks the execution of cell 1 330 and cell 340 to the paged media. Thus, cells 1 330 and 2 340 are simultaneously drawn to a printed page. When the dispatcher detects that cell 2 340 has completed, it initiates cells 3 350 and 4 360 for execution since these cells now have their top most border determined and share the same synchronization marker at the completion of the drawing of cell 2 340. Once cells 1 330 and 3 350 complete, the dispatcher forks cell 5 370 for execution since cell 5 shares a synchronization marker 310, once the drawing of cells 1 330 and 3 350 complete. Finally, when cell 4 360 and cell 5 370 complete execution, a rendition of table 160 of Fig. 3 is reproduced entirely from grid 170 on a printed page, where the drawing of the rendition occurs in parallel, improving rendering performance. Fig. 5 depicts one flow diagram of a method for rendering tables. Data is received, either in batch mode or in stream, in step 380. The received data is parsed in order to detect instances of tables within the data in step 390. If a table is detected in step 400, its context is stored and pushed to a stack in step 420, this triggers state changes within the parser for detection of columns, rows, cells, and other information regarding the table which follows in step 410.

As previously presented, this information is gathered and dimensions of the parsed cells are either acquired from the data, a user, or calculated in step 430. Next, it is determined if an end of a table is found in step 440, and if so the data continues to be received in step 380, and the stored context is popped off the stack in step 460 where a desired output media table width is acquired in step 450. As previously presented, the column widths within the grid where the cells are housed are calculated in step 470, and formatting commands, operable to generate each cell to an alternate media, are generated in step 480. The formatting commands may then be executed by a dispatching set of executable instructions in step 490 causing each cell to be rendered to the output media, wherein some cells sharing the same synchronization markers are executed in parallel during the rendering of the grid to the output media.

Fig. 6 depicts one flow diagram of a method for rendering tables to an output media. Initially, a table is detected within the data received in XSL format in step 500 along with a request to render the detected table to an output paper (step 510) having dimensions of 8 ^lA inches by 11 inches, with ^lA inches margins on all sides of the paper. The XSL data is parsed in step 520, and detected cells are stored to an internal grid, or matrix in step 530 where the relative positions of each parsed cell is recorded in step 540. Or, as previously presented the relative positions may be deduced from the locations the cell occupies within the internal grid or matrix. Based on the dimensions of the output page the widths of the cells are adjusted in step

550, and commands generated in a format that cause a printing device to draw the cells to a page are outputted in step 560. The execution of the outputted commands may then be used to produce a rendition of the originally received table in XSL format to a paged media in step 570. Fig. 7 depicts one block diagram of a method to output cells associated with a table.

Initially, a dispatching set of executable instructions 580 is operable to process formatting commands in step 590. The formatting commands are executable commands operable to draw cells to a media of a second format and originally associated with a table derived from a media of a first format, such as by way of example only a browser media. The commands include positional information operable to draw shapes onto the media of the second format, such as by way of example only, coordinates associated with a page having dimensions of 8 Vi inches by 11 inches. The positional information permits cells that begin and end at the same height to be readily ascertained and associated with vertical synchronization points that are recorded by the dispatcher 580. Cells sharing the same synchronization markers are forked together and in parallel for execution in step 600, with synchronization managed by the dispatcher 580 in step 620 until all cells are completely rendered in step 630. Once a cell has executed, it is rendered to the output media (e.g. a printed page) in step 610.

FOOTNOTE DATA STRUCTURES As previously presented, rendering footnotes to a unit of media such as, by way of example only, a printed page from a different originating media such as, by way of example only, browser media is problematic. This is so because as more footnote body data are added to a unit of media, previously inserted footnote citations are forced upward on the unit of media and continuous calculations are needed to determine if the footnote body data may be properly inserted. As one skilled in the art will appreciate, these computations effect performance of rendering the footnotes to the unit of media and one desiring to produce any substantial number of units having footnotes will readily notice the performance degradation. The present invention resolves problems associated with the continuous recalculation of the input areas used for housing footnote data by inverting the unit of media one or more times as data are serially inserted into the media. For example, consider, by way of example only, a unit of media such as a printed page to which data such as, by way of example only, text data is to be rendered. The text data are initially received in a XML or XSL format, although as one skilled in the art will appreciate any input format could provide the initial text data both standard and ad hoc. The text data is parsed and from the initial provided format, and inserted onto the printed page. Although, as one skilled in the art will readily appreciate, the data need not be directly printed to the printed page, rather, the data may be translated to printer formatting commands

^' such that when the commands are executed the data is physically impregnated on the printed page. A variety of commands to direct the printer to produce a printed page may be used and are well known in the art, such as by way of example only, PDF and PCL.

BY WAY OF EXAMPLE ONLY, CONSIDER FIG. 11 A, WHICH DEPICTS AN

INITIAL CONDITION OF PAGE 3300Q, WHICH IS TO RECEIVE TEXT 37000.

THE PAGE 33000 IS LOGICALLY REPRESENTED WITHIN A SET OF

RENDERING EXECUTABLE INSTRUCTIONS AS A SERIES OF AREAS WITH AN ORDERED SEQUENCE. MOREOVER, THE PAGE 33000 REPRESENTS A UNIT

OF THE OUTPUT MEDIA AND HAS A DIMENSION ASSOCIATED THEREWITH.

IN THE PRESENT EXAMPLE, THE PAGE 33000 IS A STANDARD 8 % X 11-INCH

PAGE, ALTHOUGH ANY DIMENSION AND MEDIA MAY BE USED WITH THE

PRESENT INVENTION. In Fig. 11a, the text 37000 is received in the page 33000 until a footnote citation

37500 is detected while parsing the text 37000 from the initial provided input format and media. The footnote citation 37500 is inserted into the page 33000 and control is briefly interrupted such that the ordered sequence associated with the page 33000 is altered and inverted as depicted in Fig. 1 lb, which depicts a page 34000 receiving footnote body data 38000 having the initial text 39000 inverted within the page 34000.

Upon completion of receiving the footnote body data 38000, a page 35000 in Fig. l ie receives additional text data 40000 that is not footnote body data. Prior to receiving the additional text data 40000, the page 35000 is again inverted such that the ordered sequence is again altered and the footnote body data 41000 are inverted within the page 35000. This process continues until a page 36000 of Fig. l id becomes completely full (e.g. all space associated with the dimension of the page is occupied). Once page 36000 is fully occupied, the footnote body data 43000 may be reordered, so that it may be read in the proper sequence within the page 36000.

As one skilled in the art will appreciate, the above described example may be achieved by using a set of executable instructions in a variety of ways, such as by way of example, using pointers to locations within a data structure that logically represents the output unit of media (e.g. page). In fact, input areas within the page may be represented as a series of geometric rectangles that are continually resizing themselves at any particular moment as data is inserted into the page. The text data not associated with footnote body data and the footnote citation data may occupy one such rectangle and the footnote body data may occupy another rectangle.

Moreover, multiple rectangles may be linked together within the unit of media to form a path of insertion, such that data are inserted into the path, which is nothing more than a linked list of the rectangular areas, the head of the list defining the initial insertion point of the data into the media. Furthermore, different types of media may have their own paths such that a single unit of media may have multiple paths with each path housing disparate media, such as audio, video, table, image data and others.

By way of example only, consider Fig. 12, which depicts a state transition of Figs. 11 a-l Id, in this example a single page may be represented as a series of ordered locations beginning with a start location of 0 and continuing with an ending location of 94. Although not depicted in Figs. 1 la-1 Id or Fig. 12, as one skilled in the art will appreciate, the locations may be further represented to define a height and width associated with each location 0-94, and these locations may be logically linked together to represent geometric rectangles and paths as discussed above. Fig. 12 depicts columns and rows, which assist in explaining the transitions of Figs.

1 la-1 Id. The US 49000 column depicts the starting location for a unit of media (e.g. page in the present example) that is a constant throughout the transitions, namely 0. The UE 50000 column depicts the ending location for the unit of media. The TS 51000 column depicts the starting location for the non footnote body data within the unit of media, and the TE 52000 column depicts the ending location for the non footnote body data within the unit of media. The TA 53000 column depicts the available space for non footnote body data to occupy, this is provided for purposes of illustration only, as one skilled in the art will readily appreciate this is not necessary. The FS 54000 column depicts the location where footnote body data begins within the unit of media, and the FE 55000 column depicts the ending location of the footnote body data within the unit of media.

The initial state 44000 corresponds to Fig. 1 la, where 29 characters of text data 37000 are being inserted into page 37000, serially beginning at the initial location associated with the page (e.g. location 0). The insertion continues until the text occupies page locations 0-28 for a total of 29 locations, available text locations are 66, and since no footnote body data yet exists these locations are represented by "1" in Fig. 12 under the columns FS 54000 and FE 55000.

After a footnote citation 37500 is detected in Fig. 11a, the representation of the page 33000 transitions to state 45000 of Fig. 12, where the text 39000 of Fig. l ib is now inverted logically within the page 34000, such that the start location of the text 39000 TS 51000 is in the 94^th location of the page 34000. In Fig. 1 lb 26 characters of text 3800 are being added to the area on the page 34000 associated with the footnote body 38000. Prior to this insertion the page 34000 is inverted so that the start location for the footnote body data FS 54000 is identified as the initial location within the page 34000 or 0 and continues to location 25 (e.g. 26 characters in length). Moreover, the space available for data insertion on the page TA 53000 is reduced from 66 to 40 after the insertion of 26 characters of footnote body data

38000. Further, the inversion of the non footnote body data 39000 creates a reverse order of that data such that the ending location TE 52000 within the page for the non footnote body data is location 66 while the start location TS 51000 is location 94.

Once all the footnote body data 38000 is received within the page 34000 in Fig. 1 lb and additional text data, the logical representation of the page 34000 is altered as depicted in state transition 46000 of Fig. 12 to generate the page 35000 depicted in Fig. l ie. In state transition 46000, 40 additional characters of non footnote body data 40000 are inserted into the page 35000. The page 35000 is again inverted prior to this insertion, such that the start location of the non footnote body data 40000 TS 51000 becomes the start location of the page 35000 again or the 0 location. The ending position of the non footnote body data 40000 TE 52000 becomes 67 (e.g. length is 68 characters of non footnote body data 40000). Further, the area available TA 53000 on page 35000 is now 0, since 68 characters of non footnote body data 40000 plus 26 characters of footnote body data 41000 equals 95 characters which is the entire area of the page 35000. Moreover, the footnote body data 41000 is inverted and reversed on the page 35000, such that the footnote body's 41000 start location FS 54000 is 94 and the footnote body 41000 end location is 68.

Once it is determined that page 35000 is fully populated Fig. l ie transitions to Fig. 1 Id as depicted in state transition 47000 of Fig. 5. During this transition all that is needed is to reverse the order of the footnote body 41000 of Fig. 1 lc to the footnote body 43000 order of Fig. 1 Id, indicating that the footnote body 43000 has a start location FS 54000 within page 36000 of 68 and an ending location FE 55000 of 94. After transitioning to Fig. l id, the entire page may be rendered and formatted as desired and delivered to the desired unit of media.

As one skilled in the art will appreciate, the above transitions, presented for purposes of illustration only, may be implemented in a variety of ways and a state table is not required. In fact, pointers to locations within a representation of a unit of media along with the appropriate state transition flags are all that is needed to implement the present invention. In a given circumstance a pointer implementation may greatly improve the performance associated with rendering footnotes in this manner by avoiding accesses to tables during execution. Although, it is readily apparent to one skilled in the art, without departing from the present invention, that any number of implementation mechanisms may be deployed.

Fig. 8 depicts a flow diagram of a method for inserting footnotes to a media. Data is initially received in step 2000 and associated with a unit of media dimension in step 3000 to which the data is to be rendered. Further, the data received in step 2000 may be received in XSL format in step 1000. The received data is then parsed a variety of parsing tools exist, such as by way of example only Flex, Lex, Yacc, Perl, and others. For purposes of illustration only, three types of data are recognized during the parsing of the received data, these types include non footnote body data, footnote citations, and footnote body data. A logical representation of the unit of media is created and in step 4000 the non footnote body data is inserted into that logical representation.

When a footnote citation is parsed and recognized in step 5000, it is inserted into the logical representation of the unit of media and this detection further triggers a logical reordering of the media representation creating an inverted view of the representation and the footnote body data is then inserted into this revised representation in step 6000. An example of how this may occur was previously presented. If the footnote body data exceeds the dimensions associated with a single unit of the media, the data is transferred to a new subsequent unit of media in step 7000.

After, the footnote body data is inserted and space available on the unit of media exhausted, the logical representation of the unit of media is restored in step 8000 to its original condition, and it is formatted as desired and rendered in step 9000 to the desired media.

As one skilled in the art will readily appreciate, the method depicted by Fig. 8 may occur iteratively with the logical representation of the unit of media being adjusted and inverted one or more times until a unit of media becomes fully populated or the data received completely exhausted. Moreover, as previously discussed, the output of the method may be formatting commands which are operable to be executed to complete the delivering of the unit of media to its appropriate media (e.g. PCL command which when executed produce a printed page). Fig. 9 depicts a flow diagram of a method of rendering footnote data. Initially data are received in step 10000 and separated in to at least three types of data including footnote body data in step 11000, non footnote body data in step 120 and footnote citation data in step 13000. Next, the non footnote body data are inserted into a unit of media in step 15000. By way of example only, this unit of media may be a logical representation of a single page or logical representation of a sub part of a single page, such as a column within the page.

Different areas within the unit of media may be defined by rectangular units linked together to form paths within the unit of media in step 14000.

When a footnote citation data are detected in step 13000, the footnote citation data are inserted into the unit of media (not shown) and an interruption in the insertion process occurs in step 16000. The footnote body data detected in step 11000 is retrieved and the unit of media locations inverted in step 17000. The footnote body data are then inserted into the unit of media in step 19000 with any carry over footnote body data pushed to a new unit of media in step 20000 if the existing unit of media becomes fully populated.

Logical representations of the unit of media may be managed by pointers in step 18000, and as described above. In this way, data is continuously inserted into the logical representation of the unit of media with minimal interruption and little need for expense calculations to ensure proper insertion. Moreover, complex insertions may be performed such that single columns of text within a unit of media may be treated as sub units and footnotes rendered as described herein. After the data.received are exhausted, the unit of media is restored to its ordered logical representation with the unit of media data in their proper locations in step 21000. In this way, data is populated to the unit of media more efficiently, and with increased rendering performance. Fig. 10 depicts a flow diagram of a method of managing footnotes rendered to a media. Non footnote data is acquired in step 22000 and its entry is associated with a second path in step 23000, the path defining an area within a unit of media to accept the non footnote data in step 26000. As previously presented, the unit of media is logical represented within a set of executable instructions as an area, such as by way of example only a page, or a portion of a page, such as areas within a page associated with columns or tables and having footnote data.

Moreover, footnote body data is acquired in step 25000 and associated with an entry path in step 24000 which is used to insert the footnote body data into the unit of media in step 26000. In step 27000, ordered locations within the representation of the unit of media are reversed for purposes of inserting the footnote body data in step 28000. In step 29000, if the footnote body data exceeds the capacity of the dimensions associated with the unit of media, the footnote body data are extended to a second unit of media.

When non footnote body data are inserted into the unit of media in step 31000, the original locations are restored within the unit of media in step 30000. After the unit of media is fully populated or the non footnote body data and footnote body data exhausted, the data is formatted in step 32000 for final preparations and rendering to the appropriate physical media.

DATA RENDERING

Electronic data may be logically represented as one of more electronic pages for purposes of presenting these data in specific layouts. In this sense, the page defines a logical area in these electronic data. Moreover, since a page is a logical area associated with these electronic data, the area is adjustable such that the entire electronic data could be viewed as a single electronic page, or conversely the entire electronic data could be viewed as multiple electronic pages. As one skilled in the art will readily appreciate, electronic data may be conceptually viewed in a variety of ways such as documents, pages, lines, paragraphs, and other ways. Correspondingly, as used herein the term "page" and "electronic data" are used interchangeably and intended to include the broadest possible meaning.

Accordingly, data that are to be rendered have an output layout that defines their presentations after having been rendered. These data are decomposed into their constituent types, where floating objects (non-text datatypes such as graphics, images, video, footnote bodies, and the like) and text objects (text data types such as tables, character text, and the like) are separated.

Initially, the rendered data represent a single rectangle occupying all the text objects contained within the original electronic data (non rendered format). Next, areas within the rendered data, where the floating objects are to reside are defined by geometric rectangles which enclose the floating objects, these areas are linked together to form a linked list, the traversal of the list is defined as the floating object path. These rectangular areas are subtracted from the initial single rectangle, and the remaining area is constructed as a series of rectangles adjacent to the floating object rectangles. These remaining rectangles are linked together to form a list, the traversal of this list is defined as the text object path. Finally, the text objects are sequentially inserted into the rectangular areas designed to house the text objects beginning at the head of the text object list, while the floating objects are sequentially inserted into the rectangular areas designed to house the floating objects beginning at the head of the floating object list. The result yields an efficient method and system for rendering data into a specific output layout, without requiring batch processing, since as one skilled in the art will appreciate this permits in stream processing with minimal processor utilization.

Fig. 13 illustrates a flow diagram of one embodiment of a method for rendering data. Initially, data are received in step 100000; the data are then decomposed into their constituent data types in step 200000. As previously discussed, there are two primary data types, namely text objects and floating objects (non-text objects). Some of these data types are depicted in Fig. 13, such as text/tables 300000, graphics/images 400000, and multimedia 500000. Next, an output format for rendered data is used in step 600000 to render these data into an output format desired in step 700000. Fig. 14 illustrates another flow diagram of one embodiment of a method for rendering electronic data. Initially, electronic data are received in step 800000; these data are defined by an input data format in step 900000. An exemplary input data format of the present invention is XML. Next, a parser is used to isolate the data types (step 1000000) contained within the electronic data received. Step 1100000 isolates all text objects while step 1200000 isolates all floating objects. Further, a desired rendering of these received data is defined by an output data format of step 1400000. An exemplary output data format of the present invention is PDF.

In step 1300000 a formatting operation is performed such that areas are identified in the output format as locations to receive the floating objects. These locations in the output format are defined and reserved in the electronic data to be rendered in step 1600000. These areas are defined as geometric rectangles in step 1500000, and each such area is linked together to form a linked list in step 1700000. The traversal of the linked list defines the floating object path.

Next, the area, in the electronic data to be rendered, which is not reserved by the floating objects are assigned to house the text objects in step 1900000. Again, the area is segmented into a series of geometric rectangles (step 1800000) adjacent to the floating object areas, and the text object areas are linked together in a linked list (step 2000000), the traversal of the linked list defining the text object path.

Finally, the floating objects are inserted sequentially into the floating object list beginning at the head of the floating object list, and the text objects are inserted sequentially into the text object list beginning at the head of the text object list in step 2100000. In step 2200000, the original data received are delivered in the desired output format with the desired layout and displayed if necessary in step 2300000.

By way of example, data initially received in XML format and whose presentation is defined with XSL syntax, are parsed to identify text objects and floating objects, then a desired output format and layout defined by PDF is used to populate the text and floating objects into that desired rendered format. This is done by initially assuming that the output data to render are a single rectangle, and then subtracting from that rectangle a series of linked rectangles which define a linked list, the elements of the list are the rectangles housing the floating objects. The remaining areas in the output data not occupied by the floating objects define a series of rectangles adjacent to the floating objects which are linked together, the elements of this list are the rectangular areas which house the text objects. Finally, the floating objects and the text objects are streamed sequentially into the head of their respective lists to populate the output data that are rendered in PDF. Fig. 15 illustrates a diagram of a system for rendering electronic data. The system of

Fig. 15 comprises a processor 2400000, a formatting software 2500000, electronic data 2600000, text objects 2700000, floating objects 2800000, a layout data format definition 2900000, and a rendered electronic data 3000000. Initially formatting software 2500000 is resident on a processor 2400000; this processor 2400000 need not be a computer but, rather, any device capable of utilizing a processor. The formatting software 2500000 receives electronic data 2600000, these data are in a defined data format recognized by the formatting software 2500000, or structured in consistent way such that the formatting software 2500000 can readily decompose these electronic data 2600000 into their constituent text objects 2700000 and floating objects 2800000. Next, the formatting software 2500000 generates a series of rectangular areas 2900000 for the floating objects 2800000 and for the text objects 2700000 to produce rendered data 3000000. Rectangular areas for like objects are linked together to form a linked list and the objects are streamed sequentially into the list beginning at the head of the list. Fig. 16 illustrates a block diagram of one embodiment for electronic data. Fig. 16 further illustrates the discussion of the prior Figs., namely, rendered electronic data Pl 3100000 are comprised of floating objects (II 4100000, 12 4200000, and 13 4300000) and text objects (TI 3200000, T2 3300000, T3 3400000, T4 3500000, and T5 3550000). Initially Pl 3100000 is a single rectangle, where floating objects are desired to be placed, these floating objects are enclosed in a geometric rectangle shape, which is readily calculated by the floating objects dimensions and placed in the desired locations of data Pl 3100000. These floating object rectangles are linked together to form a linked list identified by the path II ' 4400000 - 12' 4500000 - 13 ' 4600000. II ' 4400000 is the head of the floating object list while 13' 4600000 is the tail. After the placement of the floating objects are determined, the text object areas are defined by geometric rectangles which remain in these data and lie adjacent to the floating object rectangles. The series of these rectangles are likewise linked together to form a linked list defined by the path TI' 3600000 - T2' 3700000 - T3' 3800000 - T4' 3900000 - T5' 4000000. TI' 3600000 is the head of the text object list while T5' 4000000 is the tail. As one skilled in the art will appreciate, these geometric areas are readily ascertainable and calculated by the dimensions of the floating objects and the dimensions of the rendered data. This, therefore, provides a unique and efficient mechanism within which electronic data may be efficiently rendered. Fig. 17 illustrates a transition diagram of one embodiment for rendered electronic data. These data A 4700000 initially are a single rectangle Al, the area of which is calculated by multiplying the length and the width of the rectangle. If a floating object II 5200000, such as an image, is desired in these data, then these data would transition initially to A' 4800000 including a rectangle II 5200000 housing the floating object, and the area Al' 5100000 representing the remaining area of the initial rectangle Al 5000000. Once the rectangle II 5200000 is subtracted from the initial rectangle Al 5000000, the rendered data transition to A" 4900000 where three additional rectangles Al " 5300000, A2" 5400000, and A3" 5500000 are constructed adjacent to rectangle II 5200000. These additional rectangles define the area within which the text objects will be placed, and they are linked together so as to form a linked list.

Fig. 18 illustrates a block diagram of one embodiment for electronic data presentation. In Fig. 18, it is demonstrated how more complex data layouts may be rendered using rectangles to form columns Cl 5700000 and C2 5800000 in rendered data P 5600000. As previously discussed, text objects are formed by rectangular areas TI 5900000, T2 6000000, T3 6100000, and T4 6200000. However, in Fig. 18 higher-level objects may be defined by rectangles in the rendered data as well such as columns Cl 5700000 and C2 5800000. Cl 5700000 includes text objects TI 5900000, T2 6000000, T3 6100000, floating object II 6300000, but not text object T4 6200000 and not floating object FI 6400000 (indicative of a footnote body), these latter two objects reside in the rectangle defining column C2 5800000. In this way, rectangles may be used to represent highly complex tables in rendered data or other constructs.

Fig. 19 illustrates a transition diagram of one embodiment for rendered electronic data. Electronic data A 6500000 is initially comprised of text objects TI 6700000 and T2 6800000 and it is desired that a floating object II 690 be placed roughly in the center of data A 6500000. In accordance with the present invention data A 6500000 transitions to data A' 6600000 comprised of 6 text object rectangles TI' 7000000, T2' 7100000, T3 7200000, T4 7300000, T5 7400000, T6 7500000, and the newly inserted floating object II 6900000.

Fig. 20 illustrates a diagram of one embodiment for wrapping text. As previously indicated, text objects and floating objects are inserted into their respective areas by traversing a linked list which defines the path the objects are to take in the rendered data. In Fig. 20 text rectangle TI 7600000 contains text object 7800000 (word "inserting") which is at the very end of the rectangle TI 7600000, the very next text object 7900000 (word "text") is placed in the next rectangle T2 7700000 in the linked list of rectangles which define the text object path. In this way, text objects and floating objects can be sequentially streamed into the rendered data at the appropriate locations.

Fig. 21 illustrates a flow diagram of one embodiment for rendering footnotes. Fig. 21 further illustrates how a specific subtype of a floating object, namely a footnote body may be processed in accordance with one embodiment of the present invention. Initially, an electronic page is received in step 8100000, the page, or data, includes a reference to a footnote in step 8200000. An automatic footnote reference counter is incremented in step 8300000. The electronic page is segmented in step 8400000 to generate a body area on the page 8500000 and a reference area 8600000. At some later point in time an additional reference to a footnote is received in step 8700000 requiring a modification to the rendered page. Correspondingly, the counter for the footnote references is incremented in step 8800000 and the rectangular area defining the body area is incremented to accommodate a new footnote body in step 8900000 while at the same time, the rectangular area representing the footnote reference area is decremented in step 9000000. Finally, in step 910 the page is delivered and displayed as necessary in step 9200000. Fig. 22 illustrates a transition diagram of one embodiment for rendering footnotes.

Fig. 22 graphically illustrates the discussion of Fig. 21 above. Initially the rendered page, or data, A 9300000 has a defined rectangular area 9500000 for receiving footnote references and a defined rectangular area 9600000 for receiving footnote bodies. Once an additional footnote reference is received the rendered page A 9300000 transitions automatically to state A' 9400000 where the size of the rectangular area 9700000 used to house the footnote references is decreased in size as a result of the necessary expansion of the rectangular area 9800000 used to house the footnote bodies since an additional footnote reference has been inserted into the rendered page Al' 9400000.

The foregoing description of an exemplary embodiment of the invention has been presented for purposes of illustration and description. It is not intended to be exhaustive nor to limit the invention to the precise form disclosed. Many alternatives, modifications, and variations will be apparent to those skilled in the art in light of the above teaching. For example, although XML was used as the primary initial data format before data are rendered, any data format that is definable could be used. Moreover, although the primary examples discuss displaying rendered data, data may be rendered for purposes of printing data on a tangible media (e.g. paper, and the like) or delivering data to another application (e.g. fax, additional software modules, intelligent appliances, and the like). Finally, although a web browser (equipped with the appropriate viewing plugins) was used as the primary display mechanism, any display would suffice on any communications device. Accordingly, this invention is intended to embrace all alternatives, modifications, and variations that fall within the spirit and broad scope of the attached claims.

Claims

WHAT IS CLAIMED IS:

1. A set of executable instructions operable to generically render a table for output processing, comprising the steps of: receiving a table having one or more cells wherein each cell spans one or more columns and one or more rows;

representing the table as a geometric grid wherein one or more positions within the grid house one or more of the cells; and

providing a generic table represented by one or more formatting commands operable to provide a rendering of the grid to one or more output media.

2. The instructions of claim 1, further comprising the steps of:

parsing a dimension associated with each cell from the table and associating the dimension with each cell in the grid.

3. The instructions of claim 1 , further comprising the steps of:

processing the formatting commands to output a rendition of the table on a paged medium.

4. The instructions on claim 1, wherein the table is received in extensible style sheets language.

5. The instructions of claim 1, wherein the grid is a rectangle.

6. The instructions of claim 5, wherein the rectangle is represented as a two dimensional array.

7. The instructions of claim 1, wherein the formatting commands include one or more relative positions of each cell to one another.

8. A set of executable instructions operable to produce formatting commands to render a table, comprising the steps of:

decoupling one or more cells from a table;

storing the cells in a matrix;

expressing a dimension associated with each cell in terms of each cell's relative position to each other within the matrix; and

outputting one or more formatting commands operable to produce a rendition of the table on a output media from the matrix.

9. The instructions of claim 8, further comprising the steps of:

executing the formatting commands wherein every cell occupying a single row is rendered to the output media independent of each other.

10. The instructions of claim 9, further comprising the steps of: processing the formatting commands vertically on the output media beginning with a first row and continuing to a last row.

11. The instructions of claim 8, wherein the cells are decoupled from the table by parsing the table represented by a first format.

12. The instructions of claim 8, further comprising the steps of:

. adjusting the dimensions of each cell based on an output media dimension.

13. The instructions of claim 8, wherein the output media dimension is configurable.

14. The instructions of claim 8, further comprising:

executing the formatting commands in parallel to produce the rendition of the table on the output media.

15. A set of executable instructions operable to produce a rendition of a table, comprising the steps of:

representing one or more cells of a table with one or more executable commands wherein each command has one or more parameters defining an outputted cell's dimensions on an output media; and executing the commands in parallel to produce a rendition of the table on the output media.

16. The instructions of claim 15, further comprising the steps of:

reformatting the cells of the table to define a dimension of each cell by a relative position of each cell to one another.

17. The instructions of claim 15, further comprising the steps of:

parsing the cells from the table wherein the table is represented by a first format.

18. The instructions of claim 17, wherein the first format is extensible style sheets language.

19. The instructions of claim 15, wherein the output media is a printed page.

20. The instructions of claim 15, the table and the rendition of the table have different dimensions.

21. A method of inserting footnotes into a media, having executable instructions, comprising:

receiving non footnote data body and footnote body data;

inserting the non footnote body data into one or more first locations within a media; inverting the non footnote body data to one or more second locations when the footnote body data are inserted into the media; and

restoring the non footnote body data into the first locations with the footnote body data occupying one or more of the second locations.

22. The method of claim 21 , further comprising:

associating a dimension with a logical unit of the media.

23. The method of claim 22, wherein the first locations occur sequentially before the second locations within the media.

24. The method of claim 22, wherein the logical unit is an output page.

25. The method of claim 24, further comprising:

continuing to insert the footnote body data to a second output page when the output page is populated and the footnote body data are not completely inserted into the media.

26. The method of claim 22, further comprising:

receiving a citation data associated with the non footnote body data prior to inserting the footnote body data.

27. The method of claim 21 , wherein the non footnote body data and the footnote body data are received in an extensible stylesheets language format.

28 The method of claim 27, further comprising rendering the non footnote body data and the footnote body data to an alternative format prior to insertion within the media.

29. A method of rendering footnote data having executable instructions, comprising:

receiving data including non footnote data and footnote data having one or more footnote citations and one or more footnote bodies;

inserting the non footnote data and at least one footnote citation serially into a media;

interrupting the insertion when at least one footnote citation is detected and inverting a start location and an end location associated with a unit

of the media such that the end location houses the non footnote data and at least one of the footnote citations while at least one of the footnote bodies are inserted serially at a start location within the media; and

swapping the start location and the end location after inserting at least one of the footnote bodies such that the non footnote data and at least one of the footnote citations are located at the start location and at least one of the footnote bodies are located at the end location.

30. The method of claim 29, wherein the unit of the media is associated with a dimension.

31. The method of claim 30, wherein the unit of the media is a page.

32. The method of claim 29, wherein the non footnote data includes at least one of text data, image data, audio data, and video data.

33. The method of claim 29, further comprising:

managing the start and end locations within the unit of media using one or more pointers.

34. The method of claim 29, further comprising:

inserting a remaining portion of at least one of the footnote bodies to a subsequent unit of the media when a space associated with the unit of media becomes fully occupied during the insertion of at least one of the footnote bodies.

35. The method of claim 29, further comprising:

associating dynamically resizable geometric areas within the unit of the media to house the footnote data and the non footnote data.

36. The method of claim 35, wherein the geometric areas are rectangles and the non footnote data and at least one of the footnote citations occupy a same geometric area.

37. A method of managing footnote data rendered to a unit of media, having executable instructions, comprising: associating an entry path for receiving footnote data with a unit of media;

associating a second path for receiving non footnote body data with the unit of media; and

reversing a first location on the unit of media associated with the second path with an ending location associated with the entry path for purposes of inserting the footnote data into the unit of media.

38. The method of claim 37, further comprising:

restoring the first location associated with the second path and the ending location associated with the entry path for purposes of inserting the non footnote data body into the unit of medium.

39. The method of claim 38, further comprising:

extending the entry path to a subsequent unit of media when the unit of media is full and insertion of all of the footnote data is not complete.

40. The method of claim 38, further comprising:

formatting the footnote data and the non footnote body data within the unit of media after insertion.

41. A method of electronically rendering data on a computer readable medium, comprising: receiving one or more text objects and floating objects;

generating floating areas to house the floating objects;

outputting the floating areas at predetermined locations;

generating one or more textual areas to house the text objects, the textual areas comprising an outputted area where the floating areas have been removed; and

outputting the textual areas adjacent to the floating areas.

42. The method of claim 41 , further comprising:

linking the textual areas creating a linked list of textual areas; and

sequentially inserting the text objects into the linked list starting at a head of the list.

43. The method of claim 41 , further comprising:

linking the floating areas creating a linked list of floating areas; and

sequentially inserting the floating objects into the linked list starting at a head of the list.

44. The method of claim 41 , wherein the floating areas and the textual areas are generated by forming geometric rectangles.

45. The method of claim 44, wherein two adjacent rectangles representing textual areas are merged into a single rectangle.

46. The method of claim 41 , further comprising:

displaying the outputted floating areas and textual areas within a viewer.

47. A system for electronically rendering data on a computer readable medium comprising:

one or more text objects;

one or more floating objects; and

a set of executable instructions operable to create and output data by dividing from input data a set of textual areas and a set of floating areas and operable to populate the textual areas with the text objects and the floating areas with the floating objects.

48. The system of claim 47, further comprising:

a linking set of executable instructions operable to form a text linked list from the textual areas and a floating linked list from the floating areas.

49. The system of claim 48, further comprising:

an inserting set of executable instructions operable to insert the text objects sequentially into the text linked list beginning at a text head of the text linked list and operable to insert the floating objects sequentially into the floating linked list beginning at a floating head of the floating linked list.

50. The system of claim 47, wherein the set of executable instructions segments the output data by forming textual geometric rectangles around a space on the output data not occupied by the floating objects and forming floating geometric rectangles around the floating objects, the textual geometric rectangles representing the textual areas and the floating geometric rectangles representing the floating areas.

51. The system of claim 47, further comprising:

a rendering set of executable instructions operable to define how the output data may be displayed using at least one of a browser, a viewer, a mobile communications device, and a printer.

52. The system of claim 51 , wherein the defining is done by tagging the text objects and the floating objects with a markup language.

53. The system of claim 52 wherein the markup language is at least one of extended markup language, extended style sheets language, and portable document format.

54. A method of electronically providing for a footnote body on a page, comprising:

receiving one or more page objects including reference objects and body objects generating a body area located at the bottom of a page to house the body objects;

generating a reference area located above the body area to house the reference objects;

forming a reference geometric rectangle representing the reference area and a body geometric rectangle representing the body area; and

expanding an area of the body geometric rectangle to accommodate an additional body object while deceasing a second area of the reference area maintaining an overall area associated with the page.

55. The method of claim 54, further comprising:

displaying the reference geometric rectangle area and the body geometric rectangle area in a browser.

56. The method of claim 54, further comprising:

delivering the page including the reference geometric rectangle area and the body geometric rectangle area to at least one of a browser and a printer in a markup language defining the page.

57. The method of claim 56, wherein the markup language is at least one of extended markup language, extended style sheets language, and portable document format.

58. The method of claim 56, wherein the delivering the page occurs as reference objects and body objects are piped to a set of executable instructions operable to insert the markup language representing a displayed page.

59. The method of claim 54, further comprising:

associating automatically a reference tag of the reference object with a text description of the body object.

60. The method of claim 59, wherein the reference tag is an numeric character which is automatically incremented with each new reference tag.