US 20100287467 A1
A process is set forth for previewing a table attachment on a mobile communication device, and upon identifying table content of interest viewing and/or retrieving the entire table from an attachment server. In one embodiment, a small 4×4 row/column preview is presented on the device of every table found in a document attachment, with the cell content textual information limited to the requesting device display capabilities. This limitation avoids any requirement to download large amounts of individual cell content to the device. Thus, the user is able to quickly identify which tables are of interest and then request a full table download from the attachment server in an on-demand fashion. In this regard, the preview table itself preferably also functions as a link to the full table stored at the server to facilitate easy retrieval to the device for viewing in a spreadsheet view.
1. A process for implementation on a mobile communication device, comprising:
issuing a request for a remotely stored document, said request including an indication of display capabilities for said mobile communication device;
receiving at least a portion of said remotely stored document;
determining whether said portion includes a table preview of a full table;
if said portion does not include a table preview then displaying normal text content of said document;
if said portion includes a table preview then displaying said table preview embedded in said document at the location of said full table, said preview table having a predetermined number of rows and columns of said table with cell content textual information limited to said display capabilities for said mobile communication device; and
generating a menu at said mobile communication device for initiating one of either retrieval or viewing of said full table in response to which said device transmits a further request for additional portions of said full table.
2. The process of
3. The process of
4. The process of
5. The process of
6. The process of
7. The process of
8. The process of
9. The process of
10. A mobile communication device process comprising:
issuing a request for a remotely stored document having at least one embedded table, said request including an indication of display capabilities for said mobile communication device;
receiving and displaying said remotely stored document with a preview table component embedded in said document at the location of said table, said preview table component having a predetermined number of rows and columns of said table with cell content textual information limited to said display capabilities for said mobile communication device, wherein said receiving and displaying further includes receiving a document ID associated with said table in said remotely stored document; and
generating a menu selection at said mobile communication device for initiating one of either user retrieval or viewing of said table in response to which said device transmits said document ID to identify said table in said remotely stored document.
11. The mobile communication device process of
12. The mobile communication device process of
13. The mobile communication device process of
14. The mobile communication device process of
15. The mobile communication device process of
16. The mobile communication device process of
17. The mobile communication device process of
The instant application is a continuation of U.S. patent application Ser. No. 11/093,853, filed Mar. 30, 2005, titled “Method for Requesting and Viewing a Preview of a Table Attachment on a Mobile Communication Device,” the contents of which are incorporated herein.
The following is directed in general to displaying content on mobile communication devices, and more particularly to a method for previewing a table attachment on a mobile communication device.
Mobile communication devices are becoming increasingly popular for business and personal use due to a relatively recent increase in number of services and features that the devices and mobile infrastructures support. Handheld mobile communication devices, sometimes referred to as mobile stations, are essentially portable computers having wireless capability, and come in various forms. These include Personal Digital Assistants (PDAs), cellular phones and smart phones. While their reduced size is an advantage to portability, limitations in download bandwidth and device screen size give rise to challenges in viewing large documents with multiple embedded tables, having a large number of columns and rows for presenting information in a tabular format.
For wireless devices that support viewing of attachments, this represents a large amount of information for downloading, requiring a large amount of bandwidth and the associated cost thereof. Additionally, the user must wait for an extended period of time while the device is downloading the complete table.
Since mobile communication devices have limited screen real estate, it is known in the art to provide an Attachment Server (AS) for delivering “on-demand” content to wireless device users in order to minimize bandwidth, and device CPU/memory usage. When the user of a wireless device views a document attachment that uses tables, the Attachment Server typically downloads the document text to the Attachment Viewer (AV) on the mobile device along with a selectable link (e.g. [Table: N]), rather than the entire table contents. The user can then retrieve the entire table, if desired, by selecting the link. By downloading only the text and a link to the table, and providing the user with an option for retrieving or viewing the entire table attachment, such existing architectures thereby adhere to the on-demand design principle set forth above.
Unfortunately, the selectable link (e.g. [Table: N]) provides no information relating to the actual content of the table. Some documents use tables extensively to present information. Indeed, in some cases the entire document is created using only tables containing the entire textual content. These types of table-centric documents, when viewed on the wireless device through the foregoing on-demand architecture, are represented only by a large number of selectable table links, without any other textual information. For these types of documents the user is unable to discern which of the table(s) contain information that is relevant to them and thus should be retrieved. The user is therefore required to retrieve some, if not all, of the tables in the document in order to identify any table(s) of interest. Consequently, the design principle of offering on-demand retrieval, wherever possible, is defeated by such multiple downloads of irrelevant attachment parts.
According to one aspect, a method is provided for previewing a table attachment on a mobile communication device, and upon identifying table content of interest viewing and/or retrieving the entire table.
In one embodiment, a small 4×4 row/column preview is presented on the device of every table found in a document attachment, with the cell content textual information limited to the requesting device display capabilities (e.g. typically 8-32 characters per cell). This limitation avoids any requirement to download large amounts of individual cell content to the device, which otherwise would defeat the on-demand architectural design principle.
Thus, the embodiments set forth herein allow the user to quickly identify which table(s) is (are) of interest and then request full table download from the Attachment Server in an on-demand fashion. In this regard, the preview table itself preferably also functions as a link to the full table stored at the server to facilitate easy retrieval to the device for viewing in a spreadsheet view.
Additional aspects and advantages will be apparent to a person of ordinary skill in the art, residing in the details of construction and operation as more fully hereinafter described and claimed, reference being had to the accompanying drawings.
A detailed description of the preferred embodiment is set forth in detail below, with reference to the following drawings, in which:
With reference to
As discussed above, for documents that use embedded tables, or for documents that are constructed using only tables the existing “on-demand” architecture displays a series of embedded links to the tables, as shown in
The table preview feature set forth herein, presents the user with a small preview of the table content on a mobile device 12 in “Document View”, as show in
Finally, the full table in the document can be viewed in Spreadsheet View after it has been successfully been retrieved from the Attachment Service, as shown in
Before turning to the specifics of the client-side and server-side applications for the table preview feature, a description is provided herein of the structure of a Document Object Model (DOM) for a document attachment to be viewed on the mobile communication device 12.
The attachment server 28 uses a file-parsing distiller in the preferred embodiment, for a specific document type, to build an in-memory Document Object Model (DOM) structure representing an attachment of that document type. The document DOM structure is stored in a memory cache of server 28, and can be iterated bi-directionally.
As shown in
The document DOM structure is divided into three parts: top-level, component and references. The top level refers to the document root structure, while the main document is constructed in the component and the references represent document references to either internal or external sub-document parts. The following paragraphs examine each part in detail.
The root node of a document DOM structure, referred to as “Document”, contains several children nodes, referred to as “Contents”, which represent different aspects of the document contents. Each “Contents” node contains one or multiple “Container” nodes used to store various document global attributes. The children of the “Container” nodes are components, which store the document structural and navigational information. When the attachment server 28 builds the DOM structure for an attachment file for the first time, the top-level structure is a single parent-child chain as shown in
Three types of components are defined by the attachment server 28: text components, table components and image components, which represent text, tables and images in a document, respectively. The text and table components are described in detail below, and the image component structure is identical.
A component consists of a hierarchy of command nodes. Each command represents a physical entity, a property, or a reference defined in a document. For the text component, the physical entity commands are page, section, paragraph, text segments, comments, footnote and endnote commands, which by name define the corresponding entity contained in a document. The property commands for the text component are font, text color, text background color, hyperlink start/end and bookmark commands. The text component has only one reference command, referred to as the text reference command, which is used to reference a subdocument defined in the main body of a document. Usually, the children of a text component are page or section command nodes that, in turn, comprise a set of paragraph command nodes. The paragraph command can contain one or multiple nodes for the remaining command types.
Using the following sample text document, the corresponding document DOM structure is shown in
The table component has the same three types of commands as the text component, but different command names. The document DOM structure for the sample table document below is shown in
As shown in the
The structure shown in
Returning now to the preferred embodiment, the client component (Attachment Viewer (AV) application on device 12), when requesting a document attachment conversion from the server component (Attachment Server (AS) 28), informs the server of its device and feature specific capabilities such as screen size, color capabilities and functionality support when requesting an operation. This allows the server 28 to tailor its response to the requesting device 12 and optimize bandwidth utilization and minimize device CPU/storage usage while preserving the device presentation capabilities (e.g. color presentation data will not be returned to a monochrome device and vice versa).
For the table preview capability, the client (AV) will as part of the attachment conversion request inform the server 28 that it is capable of showing table previews as well as supplying the requesting device 12 screen resolution and color information.
This information enables the server 28 to return UCS (Universal Content Stream) data back to the device 12 containing preview table information preferably for a 4×4 row/column table with individual cell content limited to between 8-32 characters based on the requesting device screen information as well as preview table color information if supported by the device. A DOM ID for the full table is also returned to the AV on device 12 that allows the user to request the full table for viewing in spreadsheet view, if desired.
A flow chart of the device side request process is shown in
If the download request is successful (a YES branch at step 120), the client-side AV determines whether a table preview is included in the first portion (e.g. 3K of downloaded data. If not (step 125), the device displays the normal text content (step 130).
The AV then issues any further requests for additional chunks of the document attachment (a YES at step 135), and process flow returns to step 120. Otherwise, if the entire document has been downloaded (a NO at step 135), then the process terminates (step 140).
If a request to download a chunk of data from the AS on server 28 is unsuccessful (i.e. a NO at step 120), then an error flag is generated and an error message displayed (step 145), following which the process terminates (step 140).
If, as step 125, a table preview is included in the chunk of downloaded data the AV displays the table preview, as shown in
Turning now to the server-side process, when the attachment server 28 receives a document containing embedded tables, it first constructs the DOM structure for the document if it does not already exist in the in-memory DOM structure cache. Each embedded table in the file is constructed as an external table component and is added to the DOM structure as an attribute of an external component reference (ECR) command, as described in greater detail below.
The corresponding DOM structure for the following sample document containing an embedded table, is shown in
As shown in
The server-side process of
The preview table component contains only partial information about the referenced table. By default, as discussed above, the preview table preferably has only a maximum of 4 rows and 4 columns of the original table, and each table cell includes up to 16 characters. However, a person skilled in the art will understand that the numbers of table rows, columns and table cell characters are configurable and can be dynamically set in the conversion request. In addition the table formatting information is preserved in the preview table component.
After the preview table component is constructed, it is added as an attribute to the original ECR command, as discussed above. During the response and resulting DOM graph construction for a conversion request, the attachment server 28 persists the ECR command and the attached preview table component with its formatting properties. The flow chart of
After initialization of variables (140), the server process iterates the referenced table component (step 145) extracted from the ECR command shown in
If the next command is a Table Row command (step 160), a determination is made at step 180 as to whether the Table row index (m_iRowIndex) exceeds the maximum number of rows in the preview table (kiMaxRow). If no, then a table row command is created and the attributes from the original table row command are copied to the new table row command (step 185), the table row index (m_iRowIndex) is incremented (step 190), the table cell index (m_iCellIndex) and Table cell character index (m_iCharindex) are reset (step 195), and the new command is added to the preview table DOM structure hierarchy (step 200).
If the next command is a Table Cell command (step 165), a determination is made at step 210 as to whether the table cell index (m_iCellIndex) exceeds the maximum number of cells in the preview table (kiMaxCell). If no, then a table cell command is created and the attributes from the original table cell command are copied to the new table cell command (step 215), the table cell index (m_iCellIndex) is incremented (step 220), the table cell character index (m_iCharindex) is reset (step 225), and the new command is added to the preview table DOM structure hierarchy (step 200). If at step 210 the table cell index (m_iCellIndex) does not exceed the maximum number of cells in the preview table (kiMaxCell), then process flow returns to step 150.
If the next command is a Text Segment command (step 170), a determination is made at step 230 as to whether the table cell character index (m_iCharindex) is less than the maximum number of characters in each cell (kiMaxCellChar). If yes, then a text segment command is created (step 235), then at step 140 the text from the original text segment command is copied, where the amount of text to be copied is the lesser of the number of characters in the original text segment and (kiMaxCellChar−m_iCharindex). At step 245, the copied text is added to the new text segment command as an attribute, where m_iCellIndex. +=number of character copied. The new command is then added to the preview table DOM structure hierarchy (step 200). If at step 230 the table cell character index (m_iCharindex) is not less than the maximum number of characters in each cell (kiMaxCellChar), then process flow returns to step 150.
If at step 175 the table cell character index (m_iCharindex) is less than the maximum number of character in each table cell (kiMaxCellChar), then a command is created (step 250) that is of the same type as in the original document. The new command is then added to the preview table DOM structure hierarchy (step 200).
In summary, since the preview table for a table component is cached in the DOM structure as an attribute of the corresponding ECR command, memory consumption is slightly increased. However the processing time is significantly reduced by eliminating extra iterations of the table component on repeated file conversion requests.
A person skilled in the art, having read this description of the preferred embodiment, may conceive of variations and alternative embodiments.
All such variations and alternative embodiments are believed to be within the ambit of the claims appended hereto.