WO2001044983A1

WO2001044983A1 - System and method for efficient layout of a display table

Info

Publication number: WO2001044983A1
Application number: PCT/US2000/033968
Authority: WO
Inventors: Kevin Leduc
Original assignee: Sun Microsystems, Inc.
Priority date: 1999-12-15
Filing date: 2000-12-15
Publication date: 2001-06-21
Also published as: AU2264701A; US6639611B1; JP2003517685A; EP1238346A1

Abstract

A system and method for efficient layout of a display table. Given a description of a table, such as a markup language description, the table description may be parsed and data structures representing the table description may be created. The table description data structures may then be 'inspected', in order to determine the possible size of the table. Once the table has been inspected, the table may then be 'apportioned', based on the results of the inspection step. That is, final dimensions may be assigned to the table. The table coordinates may then be 'normalized', which may involve converting relative table coordinates into absolute coordinates. Table layout optimizations are described, e.g., in order to efficiently handle various aspects of table layout, such as table cells that span multiple columns or rows, table cells that include nested tables, etc. Thus, the table layout method described herein may be well-suited for use in an environment in which software optimizations are necessary or desirable, such as within a resource-constrained small footprint device.

Description

TITLE: SYSTEM AND METHOD FOR EFFICIENT LAYOUT OF A DISPLAY TABLE

BACKGROUND OF THE INVENTION

1. Field of the Invention

The present invention relates to the field of display tables, such as HTML tables More particularly, the invention relates to a system and method for efficient layout of a display table

2. Description of the Related Art

Display tables are commonly used m many types of software applications A display table may comprise rows and columns that define cells Each of the cells may comprise some type of cell content For example, many current web page documents include hypertext markup language (HTML) tables with cells that may mclude content such as text or images As another example, word processor applications often enable authors to create tables for display in a document.

Display tables are typically described in some format that a software application must process in order to display the table correctly. For example, a markup language table may be described m a text format by various markup language tags that are processed and used to create data structures representmg the table. When processing a table description, many factors may be involved in correctly determining the dimensions for the rows and columns of the table, such as the desired dimensions indicated by the table author, the available display device area for displaying the table, the minimum cell size necessary to display the content of each cell, the number of columns or rows spanned by particular cells, the determination of row and column dimensions for any nested tables included m the table, etc. The process of determining the row and column dimensions for a table, assigning coordmates to the table, and positioning the cell content within each cell of the table is referred to herem as "laying out" the table.

In many cases, it is of course not only desuable to correctly lay out display tables, but to do so efficiently Designmg an efficient table layout method may be difficult. One source of difficulty lies m dealing with nested tables, i.e., a table with one or more cells comprising another table. If the table layout method is not designed carefully, the method may scale exponentially with increasing table nesting complexity.

Although some current table layout methods do succeed in avoidmg exponential scaling with increased nesting complexity, it appears, based on the results of benchmark tests, that they do not perform other possible optimizations. Although thorough optimization of a table layout method may not be very important m some contexts or environments, m others it can be important. Small footprint devices offer one example of an environment in which it is often necessary or desirable to pay particular attention to software efficiency The field of "smart" small footprint devices is growing and changing rapidly. Small footprint devices include handheld computers, personal data assistants (PDAs'!, cellular phones, global positioning system (GPS) receivers, game consoles, set-top boxes, and many more such devices Small footprint devices are becoming increasingly powerful and enabled to run software applications or services historically associated with general computing devices, such as desktop computers Small footprmt devices may have very strong resource constraints, such as the amount of memory and the processmg power available Thus, it is often necessary or desirable to design optimized software that performs well in the environment of a small footprmt device Providmg an efficient layout method for a display table is one example of a software optimization that may significantly benefit small footprmt device users For example, many small footprmt devices are now able to run web browser applications, which often process web pages comprising markup language tables, such as HTML tables, as described above

SUMMARY OF THE INVENTION

The problems outlined above may m large part be solved by a system and method for efficient layout of a display table, as descπbed herem Given a descπption of a table, such as a markup language descπption, the table descπption may be parsed and data structures representmg the table descπption may be created

The table descnption data structures may then be "inspected", m order to determine the possible size of the table The process of table inspection may mvolve determining the minimum and maximum possible widths for each table cell, and then determining the minimum and maximum possible widths for each table column, based on the mdividual cell values The minimum and maximum possible table widths may then be calculated from the possible table column widths

Once the table has been inspected, the table may then be "apportioned", based on the results of the inspection step That is, final dimensions may be assigned to the table The process of table apportioning may mvolve assigning a width to each table column and a height to each table row The table coordmates may then be "normalized", which may mvolve converting relative table coordmates mto absolute coordmates

Table layout optimizations are descnbed, e g , m order to efficiently handle vaπous aspects of table layout, such as table cells that span multiple columns or rows, table cells that mclude nested tables, etc Thus, the table layout method descπbed herem may be well-suited for use m an envuonment m which software optimizations are necessary or desuable, such as within a resource-constrained small footprmt device

BRIEF DESCRIPTION OF THE DRAWINGS

Other objects and advantages of the mvention will become apparent upon readmg the following detailed descπption and upon reference to the accompanying drawings m which Figure 1 is a block diagram illustrating one embodiment of a system supporting a method for efficiently laying out a display table,

Figure 2 is a flowchart diagram illustrating an overview of one embodiment of a layout method for a display table,

Figure 3 is a flowchart diagram illustrating an overview of one embodiment of a process of performing display table inspection,

Figures 4 - 6 are flowchart diagrams illustrating one embodiment of a process of calculating the minimum and maximum possible column widths for a table,

Figure 7 is an example of an HTML table compπsmg a column-spanning cell, Figure 8 is a flowchart diagram illustrating an overview of one embodiment of a process of performing display table apportioning,

Figure 9 is a flowchart diagram illustrating one embodiment of a process of assignmg a width to each column of a display table, Figures 10 and 11 are flowchart diagrams illustrating one embodiment of a process of a height to each row of a display table,

Figure 12 is an example of a nested HTML table,

Figure 13 illustrates an example of resulting method mvocations when an HTML table with one cell is layed out, and Figure 14 illustrates an example of resulting method mvocations when an HTML table with one cell that mcludes a nested table with one cell is layed out

While the mvention is susceptible to vaπous modifications and alternative forms, specific embodiments thereof are shown by way of example m the drawings and are herem descnbed in detail It should be understood, however, that the drawmgs and detailed descπption thereto are not mtended to limit the mvention to the particular form disclosed, but on the contrary, the intention is to cover all modifications, equivalents and alternatives falling within the spint and scope of the present mvention as defined by the appended claims

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

Figure 1 - Exemplary System

Figure 1 is a block diagram illustrating one embodiment of a system 720 supporting a method for efficiently laying out a display table The system 720 may be employed in any of vaπous types of computing devices, such as desktop computers or workstations, small footprmt devices, etc

As shown in Figure 1, the system 720 may include a processor 710 The processor 710 may be any of vaπous types, including an x86 processor, e g , a Pentium class, a PowerPC processor, a CPU from the SPARC family of RISC processors, as well as others In vaπous embodiments, such as an embodiment m which the system 720 illustrates a small footprmt device, the processor 710 may be a less powerful processor than those listed above or may be a processor developed specifically for a small footprmt device, such as a digital signal processor (DSP) The processor 710 may have vanous clock speeds, including clock speeds similar to those found in desktop computer-class processors, as well as lower speeds such as 16 MHz

The system 720 also includes a memory 712 coupled to the processor 710 The memory 712 may compnse any of vaπous types of memory, including DRAM, SRAM, EDO RAM, Rambus RAM, etc , or a nonvolatile memory such as a magnetic media, e g , a hard drive, or optical storage The memory 712 may compnse other types of memory as well, or combmations thereof For an embodiment in which the system 720 illustrates a small footprmt device, the memory 712 may have a very small storage capacity compared to a typical desktop computer system

As shown m Figure 1, the memory 712 may store an application program 718 The application program 718 may be any of vaπous types of application programs that utilize display tables For example, the application program 718 may be a web browser application that displays markup language tables, such as HTML or XML- denved tables, the application program 718 may be a word processor program that displays tables descnbed in word processor documents, etc The application program may be configured to efficiently lay out display tables, as described below

As shown in Figure 1, the system 720 may also comprise a display 716 The display 716 may be any of vaπous types, such as a LCD (liquid crystal display), a CRT (cathode ray tube) display, etc It is noted that the display for a typical small footprmt device, such as a smart cellular phone, may be small compared to the display of a desktop computer system Figure 1 illustrates a graphical representation of a table 722 displayed on the display 716 The processor 710 executing code and data from the memory 712 provides a means for laying out and displaying the table As shown in Figure 1, the system 720 may also comprise an input mechanism 714 The input mechanism

714 may be any of various types, as appropriate for a particular system For example, the input mechanism may be a keyboard, a mouse, a trackball, a touch pen, microphone, modem, infrared receiver, etc

As noted above, in various embodiments, the system 720 may be illustrative of a small footprint device As used herem, a small footprmt device is a hardware device comprising computing resources such as processor and a system memory, but havmg significantly greater constramts on one or more of these resources than a typical desktop computer has For example, a typical small footprmt device may have two megabytes of memory or less, whereas a typical desktop system may have 64 megabytes or more Also a typical small footpnnt device may have significantly less processmg power than a typical desktop computmg system, either in terms of processor type, or processor speed, or both For example, a particular personal data assistant device may have a 16 MHz processor, whereas a typical desktop system may have a processor speed of 100 MHz or higher Also, a typical small footprmt device may have a display size significantly smaller than the display screen of a desktop computing system For example, the display screen of a handheld computer is typically small compared to the display screen of a desktop monitor It is noted that the specific numbers given above are exemplary only and are used for compaπson purposes Small footprint devices may also have constramts on other resource types compared to typical desktop computing systems, besides the memory, processor, and display size resources described above For example, a typical small footprmt device may not have a hard disk, may not have a network connection, or may have an intermittent network connection, or may have a wireless network connection, etc

Many small footpnnt devices are portable and/or are small compared to desktop computers, but are not necessarily so Also, many small footprint devices are primarily or exclusively battery-operated Also, small footpnnt devices may typically have a more limited or narrow range of usage possibilities than a typical desktop computmg system Thus, in vanous embodiments, the system illustrated m Figure 1 is illustrative of, but is not limited to, any one of the following handheld computers, wearable devices (e g , wnstwatch computers), personal data assistants (PDAs), "smart" cellular telephones, set-top boxes, game consoles, global positioning system (GPS) units, electronic textbook devices, etc Since new classes of consumer devices are rapidly emerging, it is not possible to provide an exhaustive list of small footpnnt devices However, the term 'small footprint device" is mtended to mclude such devices as may reasonably be mcluded within the spirit and scope of the term as descπbed above It is noted that in vaπous embodiments, the system and method descnbed herem may also be employed m a general-purpose computer system, such as a desktop PC or mamframe computer

Figure 2 - Table Layout Overview Figure 2 is a flowchart diagram illustrating an overview of one embodiment of a layout method for a display table

Display tables may be described in any of various ways, as appropriate for a particular type of table or application For example, a markup language table, such as an HTML table, may be described in a textual format, via the use of markup language tags Other types of display tables may be described differently, e g , in a binary format Depending on the particular type of table or application, the display table description may include vaπous types of information regarding the table, such as row and column definitions, the preferred size of the table, the content for each table cell, etc

In step 500, the display table descπption may be parsed and data structures representing the table description may be created and stored in system memory The table description data structures may be created and stored using any of vanous well-known methods, as appropriate for a particular type of table or application For example, a web browser application parsing an HTML table may create a set of objects related to each other as specified by the standard Document Object Model (DOM)

In step 502, the table data structures created m step 500 may be "inspected" As discussed above, vaπous factors may affect layout of a display table, such as the desued dimensions indicated by the table author, the available display device area for displaying the table, the minimum cell size necessary to display the content of each cell, the number of columns or rows spanned by particular cells, etc Thus, display table layout involves a negotiation between determining the possible size of a table, based on minimum and maximum dimensions of table cells, and assignmg final dimensions to the table rows and columns, based on the possible size of the table and the available display area for the table Step 502, table inspection, mvolves determining the possible size of the table, and is discussed in detail below

In step 504, the table may be "apportioned", based on the results of step 502 That is, final dimensions may be assigned to the table and to each of the table rows and columns Step 504, table apportioning, is discussed in detail below

In step 506, the table coordinates are "normalized" When laying out a cell, the final position of the cell is not yet known Thus, each object in the cell is assigned a position relative to the top corner of the cell Once a table's X,Y position has been set, these relative positions may be converted into absolute coordinates, which is referred to as normalization

In order to maximize efficiency when processmg nested tables, the normalization process may be delayed until the absolute coordmates of the outermost table are known The outermost table may then be traversed recursively to normalize coordmates for any nested tables By delay mg the normalization process until the coordmates of the outermost table are known, repetition of the normalization process can be avoided Figure 3 - Table Inspection Overview

Figure 3 is a flowchart diagram illustrating an overview of one embodiment of table inspection (step 502 of Figure 2)

In step 600, the number of rows in the table is determmed. In step 602, the number of columns in the table is determmed. As discussed above with reference to step 500 of Figure 2, the table may be parsed, and data structures representmg the table descπption may be created Each table description data structure may compnse information regarding which type of table element the data structure represents, such as a table row, a table cell, etc Thus, steps 600 and 602 may simply involve traversing through the table description data structures and countmg the number of table rows and columns. In an alternative embodiment, the number of table rows and columns may have been recorded as the table descnption was parsed, makmg steps 600 and 602 simply a matter of obtaining the recorded information.

In step 604, the data structures representing the table description are mapped to a table data structure suitable for efficiently accessing individual table cells, such as a two-dimensional array, using the number of rows and columns determined in steps 600 and 602 as the array dimensions In another embodiment, the mapping of step 604 may be unnecessary if the data structures representmg the table descnption already make it possible to efficiently traverse the table elements, quickly access mdividual cells, etc.

In step 606, the minimum and maximum possible widths for each table cell are determined The minimum and maximum possible cell widths may be calculated m various ways These calculations may depend on cell content. While certain types of cell content, such as images, may be associated with only one possible defined width, other types of cell content may be associated with various possible defined widths. For example, text may be displayable in various possible ways, such as being displayed in a smgle line, or bemg displayed in multiple lmes in a wraparound fashion. As another example, a cell may include content such as a nested table having one or more cells containing text or other content displayable m different widths.

The calculations may also use information comprised m the table descπption itself. For example, an author of a table contamed in a word processor document may set a table attribute which specifies the type of wrapping to apply to a cell. As another example, an HTML author may request that a cell be set to a certain width by using a WIDTH attribute.

However, in some embodiments, such information may be ignored when calculating the minimum cell widths. For example, HTML tables are typically designed with a desktop computer display screen m mind. However, these tables often do not display well on a small footprint device with a small display screen When the present method is applied to render tables for a small footprint device, information such as WIDTH attributes may be ignored, and the minimum cell width may instead be based on cell content, which minimizes the display space consumed by a table.

As discussed above, table cells may comprise nested tables. In this case, in order to perform step 606, it may be necessary to first layout a cell's nested table(s), m order to determine the minimum and maximum possible widths for the inner tables. The inner table calculation may be performed recursively, or may be performed usmg well-known methods to avoid recursion, such as tree traversal algorithms

In step 608, the minimum and maximum possible widths for each column m the table are determined, based on the minimum and maximum possible cell widths Note that some types of tables, such as HTML tables, may allow cells to span multiple columns Cells that span multiple columns may affect the widths of the spanned columns Step 608 involves processmg each cell of each column and tracking the minimum/maximum cell widths and also tracking which multiple-column-spanning cell (if there are any) has the largest maximum width Step 608 is illustrated in more detail m Figures 4 - 6 In step 610, the minimum and maximum possible widths for the display table are determined, based on the minimum and maximum possible column widths

Figures 4 - 6 Determining Minimum/Maximum Possible Column Widths

In step 608 of Figure 4, the minimum and maximum possible widths for each column are determmed Figures 4 - 6 are flowchart diagrams illustrating one embodiment of step 608 in more detail

As discussed above, some table cells may span multiple columns The following HTML code gives an example of an HTML table compπsing a multiple column-spanning cell

<TABLE> <TR><TD>Row 0, Column 0 <TD>Row 0, Column 1 <TD>Row 0, Column 2 <TRxTD>Row 1 , Column 0 <TD COLSPAN="2">Row 1, Column 1 <TR><TD>Row 2, Column 0 <TD>Row 2, Column 1 <TD>Row 2, Column 2 </TABLE>

Figure 7 illustrates how this table may look when displayed The cells of the table are labeled with their coπespondmg row and column numbers The second cell of the middle row (row 1 ) of the table has a "COLSPAN" attribute which specifies that the cell spans two columns Although this cell spans two columns, it is represented by a single entry in the table data structure created in step 604 of Figure 3 In that table data structure, the cell is a member of the middle column, column 1, and there is no row 1 cell for the right-most column, column 2 Thus, m this example, a cell which spans multiple columns may be said to be a member of the left-most column which it spans

In the steps illustrated in Figure 4, each column of the table is traversed For each column, all the cells of the column are processed in order to find the minimum/maximum possible cell widths The column cell with the largest minimum possible width determmes the minimum possible width for the column, and the column cell with the largest maximum possible width determmes the maximum possible width for the column Since any cells in the table which span multiple columns are members of the left-most column which they span, the columns are traversed in a πght-to-left order This allows the calculation of the minimum/maximum possible column widths to take place in a single pass through the table columns If the columns were traversed in a left-to-πght order then the minimum/maximum width values could not be determined for columns having a column-spanning cell on the first pass through, since the factors determining the width of the column-spanning cell would not yet be known

A similar process as descnbed above may be implemented for an embodiment m which multiple column- spanning cells are considered to be members of the πght-most column which they span In such an embodiment, the columns may be traversed in a left-to-πght order mstead of a πght-to-left order

To set up the πght-to-left column traversal, the column mdex is set to the index of the πght-most column in step 620 of Figure 4 In step 622 the column mdex loop control variable is tested to make sure it is within range If all the columns have been processed then the execution illustrated m Figure 4 completes Otherwise, m step 624 certain variables are initialized in preparation for an iteration through the column-processing loop The use of these variables is described below It is noted that the use of variables such as these represents one embodiment of the table layout method, and other embodiments are possible For example, information may be recorded in the table data structure itself instead of in variables

In step 626, each cell of the column specified by the column index is processed Step 626 is illustrated m more detail m the flowchart diagram of Figure 5 In step 640 of Figure 5, the row index is set to 0 In step 642 the row index loop control variable is tested to make it is within range If the index is out of range, then all the cells of the cunent column have been processed, and the execution illustrated in Figure 5 completes Otherwise, in step 646, the cunent cell, l e , the cell specified by the current columnlndex and rowlndex, is checked to see whether it spans multiple columns If the cell does not span multiple columns, then execution proceeds to step 648 In step 648, the minimum possible width for the cell is obtained, using information stored m step 606 of Figure 3 If this width is greater than the current minimum possible width recorded for the column, then the minimum possible column width is set to the minimum possible width for the cell (The minimum possible width for each column is mitialized to zero ) Steps 652 and 654 are sirmlar to steps 648 and 650 The maximum possible width for the cell is obtamed in step 652 The current maximum possible width for the column is updated to this value in step 654 if necessary Execution proceeds from step 654 to step 674

If it is determined m step 646 that the cell does span multiple columns, then execution proceeds to step 660 In step 660, the minimum possible width for the cell is obtamed, using information stored in step 606 of Figure 3 This step is identical to step 648 In step 662, the minimum cell width is compared to the colspanMmimumWidth variable A column may have more than one cell which spans multiple columns The colspanMimmumWidth variable tracks the largest minimum width value of all these cells If the minimum width value for the current cell is not greater than the colspanMimmumWidth value already recorded, then the cunent cell is ignored, and execution proceeds to step 674 As descnbed below, the colspanMmimumWidth variable is used to adjust the minimum widths of the columns spanned by the cell, if necessary For this adjustment it is only necessary to track the largest minimum possible cell width of all the spanning cells

If the minimum width value for the current cell is greater than the colspanMmimumWidth value already recorded, then the colspanMimmumWidth variable is updated in step 664 In step 666 the maximum possible width for the cell is calculated In step 668 the colspanMaximumWidth variable is set to this maximum possible cell width In step 670, the thisColumnsColspan variable is set to the number of columns spanned by the cell The use of the colspanMinimumWidfh, colspanMaximumWidth, and thisColumnsColspan variables is discussed below for Figure 6

As shown in Figure 5, step 674 is reached from step 654, step 662, or step 670 At this point, the cell referenced by the current column and row indices has been processed, and the next cell in the cunent column will be processed Thus, the rowlndex variable is incremented, and execution loops back to step 642 From step 642, another loop iteration through steps 646 - 674 occurs, or the loop ends, as appropriate Once the loop of Figure 5 ends, step 626 of Figure 4 is complete, and execution proceeds to step 628 of Figure 4 At this point, the cells of the current column have been processed to determine the minimum maximum possible widths for the column As descπbed previously, the colspanMmimumWidth and colspanMaximumWidth variables may be set in step 626 In step 628, these values are used to adjust the minimum and maximum possible column widths of columns spanned by a cell m the cunent column, if necessary Step 628 is described in more detail below with reference to Figure 6 Once step 628 is complete, the cunent column has been processed The columnlndex loop control variable is decremented in step 630 so that it references the next column to the left in the table From step 630 execution proceeds to step 622, where the loop ends if the column index is out of range, or another loop iteration is performed, as appropπate

Figure 6 is a flowchart diagram illustrating step 628 of Figure 4 m more detail The steps of Figure 6 utilize the variables colspanMmimumWidth, colspanMaximumWidth, and thisColumnsColspan which were set while processing the cunent column in the steps of Figure 5 As described above, information for only one of a column's multiple column-spanning cells is tracked (the one with the largest minimum possible width) This cell is referred to below as the "largest spannmg cell"

The thisColumnsColspan variable mdicates the number of columns spanned by the largest spanning cell In step 680 the thisColumnsColspan variable is checked to see whether it is greater than 1 This variable is mitialized to 1 in step 624 at the beginning of each iteration through the column-processing loop If thisColumnsColspan is not greater than 1, then no cells spannmg multiple columns were found m step 626, and execution returns to step 630 of Figure 4 Otherwise, execution proceeds to step 682 of Figure 6

In step 682, the minSpannedColumnWidth variable is calculated by summing up the mmimum possible width values recorded for each of the columns spanned by the largest spannmg cell Smce the table columns are traversed in a πght-to-left order, each of these values is already known In step 684 the maxSpannedColumnWidth vaπable is calculated by summing up the maximum possible width values recorded for each of the columns spanned by the largest spanning cell

In step 686, the colspanMimmumWidth variable is compared to the minSpannedColumnWidth variable If colspanMimmumWidth is less than or equal to minSpannedColumnWidth, then the minimum possible widths of the spanned columns are already sufficiently large to hold the minimum possible width of the largest spannmg cell In this case, execution proceeds to step 690 However, if colspanMmimumWidth is greater than minSpannedColumnWidth, then one or more of the minimum possible width values of the spanned columns must be adjusted in order to hold the largest spannmg cell As shown m step 688, m one embodiment, a factor based on colspanMinimumWidth - minSpannedColumn Width may be calculated, and the mmimum possible width value for each of the spanned columns may be scaled upward Other adjustment methods may be used in other embodiments

Steps 690 and 692 are similar to steps 686 and 688 If colspanMaximumWidth is greater than maxSpannedColumnWidth, then one or more of the maximum possible width values of the spanned columns are increased in step 692 so that the maximum possible column widths are large enough to hold the maximum possible width of the largest spannmg cell The processes described above of course represent one embodiment, and various steps may be added, omitted, combined, altered, performed in different orders, etc For example, the processes are discussed m terms of initializing an mdex to 0, etc However, any of vanous well-known techniques for properly controlling iteration may be used Figure 8 - Table Apportioning Overview

As described above, once a table has been inspected, it can be apportioned, 1 e , final dimensions may be assigned to the table and to each of the table rows and columns Figure 8 is a flowchart diagram illustrating an overview of one embodiment of table apportioning (step 504 of Figure 2) In step 550, the minimum/maximum possible column widths determmed during the table inspection process are considered along with the available space for the table in order to assign a width to each table column Step 550 is illustrated in more detail in Figure 9

In step 552, the width of the table is calculated, e g , by summing up the column widths assigned in step 550 Cell heights may be somewhat determined by cell widths Few constraints are placed on cell height, smce it is usually more visually appealmg to display a table of a width that fits on a display screen, rather than to control the cell heights and have the table width overflow

Thus, once the table columns have been assigned widths m step 550, a height may be assigned to each table row in step 554 Step 554 is illustrated m more detail in Figures 10 and 12 In step 556, the height of the table is calculated, e g , by summing up the row heights assigned in step 554

Figure 9 - Assigning Table Column Widths

Figure 9 is a flowchart diagram illustrating step 550 of Figure 8 in more detail As shown in Figure 9, there are three basic cases In step 700 the mmimum table width is calculated and compared to the available display space for the table The minimum table width may be calculated by summing the minimum possible column widths for each column m the table, which were determined durmg the table inspection process described above The available display space may be determined in various ways For example, the available space value may be passed as a parameter to a table apportioning method or function If the mmimum table width is too large to fit mto the available display space, I e , the table width must overflow the available display space, then the minimum table width is used, and in step 702 the final column width for each column is set to its minimum possible value

If the mmimum table width is small enough to fit mto the available space, then execution proceeds to step 704 If no prefened width for the table was specified, then the maximum table width is calculated Otherwise, execution proceeds to step 708 The maximum table width may be calculated by summing the maximum possible column widths for each column in the table If the maxunum table value is small enough to fit mto the available space, then the maximum table width is used, and m step 706 the final column width for each column is set to its maxunum value

If neither of the conditions m step 700 or 704 are met, then the table columns are scaled to make the table width be a particular value in step 708 If a prefened width for the table is specified, then the columns are scaled to match this prefened table width value If no prefened table width is specified and the maximum table width is too large for the available space, then the columns are scaled to match the available space value Any of vanous heuπstics or algorithms may be applied for the scaling For example, each column may be scaled with an equation such as colWidth = minColWidth + ((maxColWidth - mmColWidth) *

(availableSpace - mmTable Width) / (maxTable Width - mmTable Width))

Other scalmg methods may be applied in other embodiments For example, mdividual scalmg factors may be applied to different columns, dependmg on each column's content

Figures 10 and 11 - Assignmg Table Row Heights

In step 554 of Figure 8, a height is assigned to each table row Figures 10 and 11 are flowchart diagrams illustrating step 554 m detail

Just as table cells may span multiple columns, they may also span multiple rows The below descπption accounts for cells that span multiple rows by processing rows in a bottom-to-top order, for reasons similar to the πght-to-left column processmg order descπbed above

To set up the bottom-to-top row traversal, the row mdex is set to the mdex of the bottom-most column m step 720 of Figure 10 In step 722 the row mdex loop control vaπable is tested to make it is within range If all the rows have been processed then the execution illustrated m Figure 10 completes Otherwise, m step 724 certain vanables are mitialized in preparation for an iteration through the row-processmg loop The use of these vanables is descπbed below It is noted that the use of vanables such as these represents one embodiment of the table layout method, and other embodiments are possible For example, information may be recorded in the table data structure itself instead of in vanables

In step 726 each cell of the row specified by the row mdex is processed Step 726 is illustrated in more detail in the flowchart diagram of Figure 11 In step 740 of Figure 11, the column mdex is set to 0 In step 742 the column mdex loop control vanable is tested to make sure it is within range If the mdex is out of range, then all the cells of the current row have been processed, and the execution illustrated m Figure 11 completes Otherwise, m step 744, the contents of the cunent cell, I e , the cell referenced by the cunent row mdex and column mdex, are layed out The cell contents are layed out accordmg to the cell width, which is determmed from the assigned column widths as descnbed above Once the cell contents are layed out, the height of the cell is known

In step 746, the cell is checked to see whether it spans multiple rows If the cell does not span multiple rows, then execution proceeds to step 748 In step 748, the cell height is compared to the cunent height recorded for the row (The height for each row is mitialized to zero ) If the cell height is greater than the row height, then the height of the cunent row is set to the cell height Execution proceeds from step 748 to step 760

If the cunent cell does span multiple rows then execution proceeds from step 746 to step 750 In step 750 the number of rows spanned by the cunent cell is compared to the thisRowsRowspan vaπable value If the cunent cell spans more rows than the value of thisRowsRowspan, then execution proceeds to step 756, where the value of the rowSpanHeight vaπable is set to the height of the cunent cell The rowSpanHeight vanable mdicates the maximum height spanned by a row-spanning cell of the cunent row Execution proceeds from step 756 to step 758, where the thisRowsRowspan value is updated to the number of rows spanned by the cunent cell Execution proceeds from step 758 to step 760 In step 750, if the cunent cell does not span more rows than the value of thisRowsRowspan, then execution proceeds to step 752 In step 752, the number of rows spanned by the cunent cell is again compared to the thisRowsRowspan vaπable value If the two values are equal, then in step 754 the cunent cell height is checked to see if it is greater than the cunent value of rowSpanHeight If so, then rowSpanHeight is updated to the height of the cunent cell, and execution proceeds to step 760 If the number of rows spanned by the cunent cell is not equal to thisRowsRowspan m the comparison of step 752, then execution proceeds to step 760

Once step 760 is reached from step 748, 752, or 754, the cunent cell has been processed to determine how its height or other characteristics, such as the number of rows it spans, affect the calculation of the height of the cunent row In step 760, the column index is incremented to reference the next column in the row, and execution loops back to step 742 From step 742, another loop iteration may be performed, or if all of the row's cells have been processed, then the row processing illustrated in Figure 1 1 for step 726 of Figure 10 may end

Once the cells of the cunent row have been processed m step 726 execution proceeds to step 728 of Figure 10 In step 728, the heights of the rows spanned by the largest spannmg cell of the cunent row may be adjusted, if necessary The row heights of these rows may be summed If this sum is less than the height of the largest spannmg cell (mdicated by the rowSpanHeight vanable), then the row heights may be adjusted As discussed above for column width adjustment, the row height adjustment may be performed using any of vaπous methods

Once any necessary row height adjustments are made m step 728, the row index is decremented in step 730 to refer to the next highest row m the table, and execution loops back to step 722 From step 722, another loop iteration may be performed, or the execution illustrated in the flowchart diagram of Figure 10 may end if all the table rows have already been processed

Figure 12 - Efficient Layout of Nested Display Tables

As noted previously, some types of tables allow table nestmg For example, HTML tables may be nested The following HTML code shows an example of a nested HTML table

<TABLE>

<TRxTD>Row 0, Column 0 <TD>Row 0, Column 1 <TD>Row 0, Column 2 <TR><TD>Row 1, Column 0 <TD>Row 1, Column 1 <TD>Row 1, Column 2 <BR>Nested table

<TR><TD>Row 0, Column 0

<TD>Row 0, Column 1

<TR><TD>Row 1, Column 0 <TD>Row 1, Column 1

</TABLE> <TRxTD>Row 2, Column 0 <TD>Row 2, Column 1 <TD>Row 2, Column 2 < TABLE>

Figure 12 illustrates what this table may look like when displayed

In many cases, it may be desirable for a display table layout method to efficiently handle nested tables For example, nested HTML tables are commonly found m web pages Maximizing layout performance improvement may be especially important in laying out tables for small footpnnt devices, smce these devices may have very little processing power Also, the situations and environments in which these devices are used may make it especially important to layout tables quickly For example, a user of a web browser application running m a cellular phone may need to quickly view a web page including nested tables in order to obtain an important phone number needed for an immediate situation, whereas a desktop computer user may typically browse the web m a more leisurely manner

As discussed above, when a table descπption is parsed, data structures representmg the table descnption may be created and stored in system memory In one embodiment, the table descπption may be stored as objects comprising methods such as Inspect(), Apportιon(), Normalιze(), etc that conespond to the processes descnbed above The display table layout method may traverse through the table, invoking these methods and controlling the recursion process to efficiently handle nested tables

The following HTML code describes a simple HTML table with one cell

Figure 13 illustrates the resulting method mvocations when this HTML table is processed The method mvocation trace shown m Figure 13 follows the general process described above for laymg out a display table As shown, the display table is first inspected Inspecting the table comprises mspecting each table cell (In this example there is only one cell ) After the table is inspected, the table is then apportioned and normalized as descπbed above and shown in Figure 13

The following HTML code descπbes a simple HTML table with one cell that includes a nested table with one cell

<table>tablel

<tr>

<td>cell <table>table2 <trxtd>nested cell </table>

</table>

Figure 14 illustrates the resultmg method invocations when this HTML table is processed The method mvocation trace shown in Figure 14 is similar to that in Figure 13 However, as shown in Figure 14, the mspection process for the cell of the outer table results in a second inspection process being initiated for the nested table included m the cell of the outer table As shown m the figure, the nested table is inspected before minimum and maxunum possible widths are assigned to the outer table cell Similarly the apportionmg process for the cell of the outer table results in a second apportionmg process bemg initiated for the nested table mcluded m the cell of the outer table

The method invocation trace of Figure 14 illustrates a smgle method mvocation controlling the overall layout process for the outer table, I e , the "Layout (Body)" method invocation Note that when the cell of the outer table is layed out, (shown by the "Layout (Celll)" method call) there is no such method mvocation to layout the nested table mcluded in the cell of the outer table The nested table is identical to the table processed m Figure 13 Thus, mvokmg the "Layout (Body)" method on the inner table would result in the Figure 13 method mvocation trace bemg mcluded under the "Layout (Celll)" method mvocation m Figure 14. As shown m the Figure 14, each of the Figure 13 method mvocations are already performed m the Figure 14 method mvocation trace Thus, the layout method descπbed herem is able to avoid the duplication of processmg.

Although the embodiments above have been described m considerable detail, numerous variations and modifications will become apparent to those skilled m the art once the above disclosure is fully appreciated It is mtended that the following claims be interpreted to embrace all such vaπations and modifications.

Claims

WHAT IS CLAIMED IS:

1 A method for efficiently laymg out a display table specified by a display table descπption, wherem the display table compπses rows and columns, wherem the rows and columns define cells, the method compnsing mspecting the display table descnption, wherem said inspecting compπses determining the minimum and maximum possible widths for each cell of the display table and usmg the minimum and maximum possible widths for each cell to determine the minimum and maxunum possible widths for each column of the display table; apportionmg the display table, wherem said apportionmg compπses usmg the minimum and maxunum possible widths for each column of the display table to assign a width to each column of the display table and determmmg the resulting height of each table cell based on the assigned column widths, and usmg the cell height information to assign a height to each row of the display table

2 The method of claim 1 , further compnsing- normalizing the display table, wherem said normalizing compnses determmmg absolute table coordinate from relative table coordmates, wherem said apportiomng the display table compπses determining the relative table coordmates.

3 The method of claim 1 , wherem the display table compnses a plurality of row and columns, wherem the display table mcludes a cell that spans at least two columns.

4 The method of claim 1 , wherem the display table mcludes a cell compπsmg a nested table

5 The method of claim 1, wherem the display table is represented m memory as an object

6. The method of claim 5, wherem the display table object compnses an "inspect" method and an "apportion" method, wherem said mspecting the display table compnses mvokmg the "inspect" method of the display table object, wherem said apportiomng the display table compπses mvokmg the "apportion" method of the display table object

7. The method of claim 1, wherem said determmmg the minimum and maximum possible widths for each cell of the display table is dependent upon a content of said each cell

8. The method of claim 5 , wherem the content m a particular cell mcludes text, and wherem the text is displayable m a first width and a second width

9 The method of claim 8, wherem the first width and the second width represent the mmimum and maxunum possible widths for said particular cell

10. The method of claim 1, wherem the display table descnption compπses a markup language table descπption

11 The method of claim 1 , wherem the display table descnption compπses a hypertext markup language (HTML) table descπption.

12. The method of claim 1, wherem said mspecting and said apportiomng are implemented m a small footprmt device

13 A system comprising: a processmg unit; memory coupled to the processmg unit; a program stored in the memory, wherem the program is executable to lay out a display table specified by a display table descπption, wherem the display table compnses rows and columns, wherem the rows and columns define cells; wherem said laymg out a display table compnses inspecting the display table descnption, wherem said inspecting compnses determmmg the minimum and maxunum possible widths for each cell of the display table and usmg the minimum and maximum possible widths for each cell to determine the mmimum and maximum possible widths for each column of the display table; apportiomng the display table, wherem said apportionmg compnses usmg the minimum and maxunum possible widths for each column of the display table to assign a width to each column of the display table and determining the resulting height of each table cell based on the assigned column widths, and usmg the cell height information to assign a height to each row of the display table

14. The system of claim 13, wherem said laymg out a display table further compπses: normalizing the display table, wherem said normalizing compnses determmmg absolute table coordmates from relative table coordmates, wherem said apportionmg the display table compnses determmmg the relative table coordinates.

15. The system of claim 13, wherem the display table compπses a plurality of rows and columns; wherem the display table mcludes a cell that spans at least two columns

16. The system of claim 13, wherem the display table mcludes a cell compnsmg a nested table

17. The system of claim 13, wherem the display table is represented m the memory as an object.

18. The system of claim 17, wherem the display table object compnses an "inspect" method and an "apportion" method, wherem said mspecting the display table compπses mvokmg the "inspect" method of the display table object, wherem said apportiomng the display table compπses mvokmg the "apportion" method of the display table object

19. The system of claim 13, wherem said determining the minimum and maximum possible width for each cell of the display table is dependent upon a content of said each cell.

20. The system of claim 19, wherem the content m a particular cell mcludes text, and wheπn the text is displayable m a first width and a second width.

21 The system of claim 20, wherem the first width and the second width represent the minimum and maxunum possible widths for said particular cell.

22. The system of claim 13, wherem the display table descnption compnses a markup language table descnption.

23. The system of claim 13, wherem the display table descnption compπses a hypertext markup language (HTML) table descnption

24. The system of claim 13, wherem the processmg unit and memory are mcluded within a small footpnnt device

25. A memory medium compnsmg program instructions which implement laymg out a display table specified by a display table descπption, wherem the display table compπses rows and columns, wherem the rows and columns define cells, wherem said laymg out the display table compπses- mspecting the display table descnption, wherem said mspecting compnses determmmg the minimum and maxunum possible widths for each cell of the display table and usmg the minimum and maxunum possible widths for each cell to determme the minimum and maximum possible widths for each column of the display table; apportionmg the display table, wherem said apportiomng compnses usmg the minimum and maximum possible widths for each column of the display table to assign a width to each column of the display table and determmmg the resulting height of each table cell based on the assigned column widths, and usmg the cell height information to assign a height to each row of the display table.

26. The memory medium of claim 25, wherem said laymg out the display table further compnses: normalizing the display table, wherem said normalizing compπses determmmg absolute table coordmates, wherem said apportiomng the display table compπses determining the relative table coordmates.

27. The memory medium of claim 25, wherem the display table compnses a plurality of rows and columns; wherem the display table mcludes a cell that spans at least two columns

28. The memory medium of claim 25, wherem the display table mcludes a cell compnsmg a nested table

29. The memory medium of claim 25, wherem the display table is represented m memory as an object

30. The memory medium of claim 29, wherem the display table object compπses an "inspect" method and an "apportion" method, wherem said mspecting the display table compnses mvokmg the "inspect" method of the display table object; wherem said apportiomng the display table compnses mvokmg the "apportion" method of the display table object.

31. The memory medium of claim 25, wherem said determining the minimum and maxunum possible widths for each cell of the display table is dependent upon a content of said each cell.

32. The memory medium of claim 31 , wherem the content m a particular cell mcludes text, and wherem the text is displayable m a first width and a second width.

33. The memory medium of claim 32, wherem the first width and the second width represent the minimum and maximum possible widths for said particular cell

34. The memory medium of claim 25, wherem the display table descnption compπses a markup language table descπption

35 The memory medium of claim 25, wherem the display table descπption compπses a hypertext markup language (HTML) table descnption

36. The memory medium of claim 25, wherem said mspecting and said apportionmg are implemented m a small footpnnt device