Classifications

• • G—PHYSICS
  • G06—COMPUTING OR CALCULATING; COUNTING
  • G06F—ELECTRIC DIGITAL DATA PROCESSING
  • G06F40/00—Handling natural language data
  • G06F40/10—Text processing
  • G06F40/166—Editing, e.g. inserting or deleting
  • G06F40/177—Editing, e.g. inserting or deleting of tables; using ruled lines

Definitions

• 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.
• WWW World-Wide Web
• Internet Explorer equipped with the appropriate external viewer plugins
• external viewers such as Adobe Acrobat and the like
• 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).
• 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.
• Hypertext Markup Language HTML
• PostScript PS
• Portable Document Format PDF
• Standard Generalized Markup Language SGML
• PCL Printer Control Language
• XML Extended Markup Language
• XSL Extended Stylesheets Language
• WML Wireless Markup Language
• 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.
• 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.
• 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.
• 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.
• 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.
• 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.
• 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.
• a browser media data format such as Hypertext Markup Language, and others
• 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.
• 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.
• 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.
• 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.
• 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.
• 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.
• 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.
• 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.
• 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.
• formatting commands are provided to render the cells to a target media wherein the commands may be executed in parallel, producing improved performance.
• the formatting commands when executed produce a rendering of the table on the target media.
• 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.
• 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.
• the footnote body 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.
• the footnote bodies are adjusted so the bodies occur in the proper sequence within the unit of media.
• a set of executable instructions to generically render a table for output processing 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.
• a set of executable instructions operable to produce formatting commands to render a table 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.
• a set of executable instructions operable to produce a rendition of a table 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.
• a set of executable instructions for inserting footnotes into a media 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.
• a set of executable instructions operable to render footnotes 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.
• 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.
• 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.
• 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.
• a method of electronically rendering data on a computer readable medium 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.
• 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.
• a method of electronically providing a footnote body on a page in a computer readable medium 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.
• 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.
• 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
• Fig. 22 depicts a transition diagram for rendering footnotes.
• 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).
• software programming languages e.g., C, C++, Java, Active X, Active Server Pages, XSLT, Xpath
• TCP/IP Internet communication protocols
• other programming languages and communications protocols may be also readily employed.
• 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.
• a set of executable instructions operable to detect a table within the data or the file.
• the individual cells of the table and the requisite information associated with the table are stored in a grid, or matrix (e.g. a single or multiple dimensional array).
• a grid e.g. a single or multiple dimensional array.
• any internal data structure would suffice as long as the information associated with the table is readily ascertainable.
• 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.
• 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.
• 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.
• the number of equal sized cells within the grid 170 could be readily determined and configured.
• 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.
• some tabular information contained in the pre-parsed table may identify the exact number of columns and rows associated with the table being parsed.
• 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.
• 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.
• 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.
• dimension information is carried with grid 170 for each of the five cells originally depicted in table 160.
• the grid 170 of Fig. 3 rendering the table 160 from the grid 170 becomes a much easier task.
• 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.
• grid 170 could be automatically adjusted to accommodate this desired transition.
• 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.
• 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).
• a table may be received in XML or XSL compatible formats and will be readily identified.
• 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.
• 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.
• 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.
• 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.
• 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.
• the cells and their corresponding data are inserted into the grid in step 40.
• 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.
• 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.
• 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.
• these commands may be executed to render an originally received table to an entirely different media in step 70.
• These commands 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.
• formatting commands to render the grid to an output media are generated 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.
• 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.
• 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.
• print publishers, and advertisers would save substantially in expenses associated with reformatting browser-based tables for printed publications or reproduction on other media.
• 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.
• 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.
• the dispatcher 280 forks the execution of cell 1 330 and cell 340 to the paged media.
• cells 1 330 and 2 340 are simultaneously drawn to a printed page.
• 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.
• 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.
• 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.
• this information is gathered and dimensions of the parsed cells are either acquired from the data, a user, or calculated in step 430.
• 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.
• 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 l A inches by 11 inches, with l A 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
• Fig. 7 depicts one block diagram of a method to output cells associated with a table.
• 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.
• the output media e.g. a printed page
• 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.
• 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.
• the data need not be directly printed to the printed page, rather, the data may be translated to printer formatting commands
• 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.
• FIG. 11 A WHICH DEPICTS AN
• Fig. 1 lb depicts a page 34000 receiving footnote body data 38000 having the initial text 39000 inverted within the page 34000.
• a page 35000 in Fig. l ie receives additional text data 40000 that is not footnote body data.
• the page 35000 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).
• the footnote body data 43000 may be reordered, so that it may be read in the proper sequence within the page 36000.
• 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).
• 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.
• 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.
• 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.
• Fig. 12 depicts a state transition of Figs. 11 a-l Id
• 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.
• 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.
• 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
• 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
• 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.
• 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.
• 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.
• 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).
• 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.
• Fig. l ie transitions to Fig. 1 Id as depicted in state transition 47000 of Fig. 5.
• 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.
• the entire page may be rendered and formatted as desired and delivered to the desired unit of media.
• 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.
• a footnote citation 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.
• 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.
• 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.
• 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.
• 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.
• step 13000 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.
• 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.
• 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.
• 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.
• 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.
• step 31000 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.
• Electronic data may be logically represented as one of more electronic pages for purposes of presenting these data in specific layouts.
• the page defines a logical area in 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.
• electronic data may be conceptually viewed in a variety of ways such as documents, pages, lines, paragraphs, and other ways.
• page and “electronic data” are used interchangeably and intended to include the broadest possible meaning.
• 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.
• the rendered data represent a single rectangle occupying all the text objects contained within the original electronic data (non rendered format).
• 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.
• 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.
• 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.
• 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.
• 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.
• 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.
• 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.
• 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.
• step 2200000 the original data received are delivered in the desired output format with the desired layout and displayed if necessary in step 2300000.
• Fig. 15 illustrates a diagram of a system for rendering electronic data.
• 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.
• 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).
• 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.
• the text object areas are defined by geometric rectangles which remain in these data and lie adjacent to the floating object rectangles.
• TI' 3600000 is the head of the text object list while T5' 4000000 is the tail.
• 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.
• a floating object II 5200000 such as an image
• 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.
• 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.
• 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.
• text objects are formed by rectangular areas TI 5900000, T2 6000000, T3 6100000, and T4 6200000.
• 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.
• 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.
• 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.
• 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.
• 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.
• 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.
• an additional reference to a footnote is received in step 8700000 requiring a modification to the rendered page.
• step 8800000 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.
• 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.
• 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.
• 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.

Landscapes

• Engineering & Computer Science (AREA)
• Theoretical Computer Science (AREA)
• Health & Medical Sciences (AREA)
• Artificial Intelligence (AREA)
• Audiology, Speech & Language Pathology (AREA)
• Computational Linguistics (AREA)
• General Health & Medical Sciences (AREA)
• Physics & Mathematics (AREA)
• General Engineering & Computer Science (AREA)
• General Physics & Mathematics (AREA)
• Document Processing Apparatus (AREA)
• Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Applications Claiming Priority (9)

Publications (1)

Family

ID=27498512

Family Applications (1)

Country Status (3)

Families Citing this family (1)

Family Cites Families (7)

• 2001
  • 2001-05-18 EP EP01939208A patent/EP1402430A2/de not_active Withdrawn
  • 2001-05-18 AU AU2001264751A patent/AU2001264751A1/en not_active Abandoned
  • 2001-05-18 WO PCT/US2001/016376 patent/WO2001090918A2/en not_active Ceased

Non-Patent Citations (1)

Also Published As

Similar Documents

Legal Events