AU2005200007A1 - Data format for rendering text - Google Patents

Description

I

S&F Ref: 705304

AUSTRALIA

PATENTS ACT 1990 COMPLETE SPECIFICATION FOR A STANDARD PATENT Name and Address of Applicant: Actual Inventor(s): Address for Service: Invention Title: Canon Kabushiki Kaisha, of 30-2, Shimomaruko 3chome, Ohta-ku, Tokyo, 146, Japan Andrew R Coker Spruson Ferguson St Martins Tower Level 31 Market Street Sydney NSW 2000 (CCN 3710000177) Data format for rendering text ASSOCIATED PROVISIONAL APPLICATION DETAILS [33] Country [31] Applic. No(s) AU 2004900882 [32] Application Date 20 Feb 2004 The following statement is a full description of this invention, including the best method of performing it known to me/us:- 5815c -1- DATA FORMAT FOR RENDERING TEXT Field of the Invention The present invention relates generally to graphics processing and, in particular, to the rendering of text. The present invention also relates to a method and apparatus for rendering text, and to a computer program product including a computer readable medium having recorded thereon a computer program for rendering text.

Background Many conventional computer systems and similar electronic devices employ graphical user interfaces to provide a means of human computer interaction. Such user interfaces often display textual information or "text". The text is typically defined in a graphics-independent format American Standard Code for Information Interchange (ASCII))). Such a format typically references "typeface" specific information that defines the general appearance and style of one or more textual characters displayed by a user interface.

Typically, a set of textual characters comprises all alphanumeric and punctuation symbols used in the printed form of one or more human languages. Each character in a set of characters has an associated "glyph" that defines the general shape of a character but is independent of any specific design. The exact appearance of each particular character is dependent on the font applied to the glyph defining the shape of the particular character.

For example, a set of characters may be based on the well known "Arial Italic" font. In this instance, the glyph representing the shape of a particular character will have the Arial Italic font applied to the glyph to generate the particular character.

User interfaces are typically implemented as one or more computer application programs or code modules. A particular user interface may employ both graphical elements and text. In order to provide a user interface that is intuitive and effective, 705304.doc -2particular attention may be required to be given to size, layout and font of text used in the user interface.

In recent times, the physical size, resolution and colour-depth of display screens on computer systems and similar electronic devices has become increasingly large.

However, the quality of displayed graphics and text on a user interface may deteriorate greatly when displayed at high resolutions. In particular, the quality of text may be limited by the size of each original character bitmap defining each displayable character.

One known method for rendering text at high resolutions is to use font data defining the shape of each glyph in order to construct the outline of one or more textual characters.

Such a method improves the quality of displayed text at a range of resolutions. However, one disadvantage of this method is that it requires a large amount of storage capacity in order to store data representing a plurality of fonts. A further disadvantage of using font data defining the shape of each displayable character is that the appearance of each displayable character must be determined individually on the basis of outline data and other data representing the size and colour of each character. Such storage and computational requirements are too great for many computer systems and, in particular, for embedded computer systems.

In addition, when determining the correct appearance of displayed text, a kerning process is often used to adjust the amount of spacing between each pair of adjacent characters representing a pair of adjacent displayable characters. For example, many lower-case characters placed after an upper-case character are moved slightly to the left by a kemrning process. Such a kerning process improves the appearance and readability of text. However, kerning creates additional computational requirements for a user interface displaying text. Again, such computational requirements are too great for many computer systems such as embedded computer systems.

Thus a need clearly exists for an improved method of generating text.

705304.doc -3- Summary It is an object of the present invention to substantially overcome, or at least ameliorate, one or more disadvantages of existing arrangements.

According to one aspect of the present invention there is provided a method of rendering one or more text strings, the method comprising steps of: determining one or more glyphs in said text strings; determining one or more kemrning distances between any of said glyphs; storing a representation of each of said glyphs and the predetermined kerning distances; determining a list of indices referencing each of the stored representations and the predetermined kemrning distances; and rendering said text by concatenating said representations based on said list, the concatenated representations being spaced according to the predetermined kemrning distances.

According to another aspect of the present invention there is provided a method of rendering one or more text strings, the method comprising steps of: determining one or more glyphs in said one or more text strings; determining one or more kemrning distances between any of said glyphs; storing a representation of each of said glyphs and the predetermined kerning distances; determining a list of indices referencing each of the stored representations and the predetermined keming distances; generating one or more rendering instructions based on said representations, the predetermined kerning distances and said list; and rendering said text by executing the rendering instuctions.

705304.doc -4- According to still another aspect of the present invention there is provided a method of rendering one or more text strings, each of said text strings comprising one or more glyphs, said method being characterised in that kerning distances between each of said glyphs are predetermined and stored prior to rendering said text strings.

According to still another aspect of the present invention there is provided an apparatus for rendering one or more text strings, the apparatus comprising: glyph determining means for determining one or more glyphs in said text strings; kemrning distance determining means for determining one or more kerning distances between any of said glyphs; storage means for storing a representation of each of said glyphs and the predetermined kerning distances; list determining means for determining a list of indices referencing each of the stored representations and the predetermined kerning distances; and rendering means for rendering said text by concatenating said representations based on said list, the concatenated representations being spaced according to the predetermined kerning distances.

According to still another aspect of the present invention there is provided an apparatus for rendering one or more text strings, the apparatus comprising: glyph determining means for determining one or more glyphs in said one or more text strings; kerning distance determining means for determining one or more kerning distances between any of said glyphs; storage means for storing a representation of each of said glyphs and the predetermined kerning distances; list determining means for determining a list of indices referencing each of the stored representations and the predetermined kerning distances; 705304.doc rendering instruction determining means for generating one or more rendering instructions based on said representations, the predetermined kerning distances and said list; and rendering means for rendering said text by executing the rendering instuctions.

According to still another aspect of the present invention there is provided an apparatus for rendering one or more text strings, each of said text strings comprising one or more glyphs, said apparatus being characterised in that kemrning distances between each of said glyphs are predetermined and stored prior to rendering said text strings.

According to still another aspect of the present invention there is provided a computer program product comprising a computer readable medium comprising recorded thereon a computer program for rendering one or more text strings, the computer program comprising: code for determining one or more glyphs in said text strings; code for determining one or more kerning distances between any of said glyphs; code for storing a representation of each of said glyphs and the predetermined keming distances; code for determining a list of indices referencing each of the stored representations and the predetermined keming distances; and code for rendering said text by concatenating said representations based on said list, the concatenated representations being spaced according to the predetermined kemrning distances.

According to still another aspect of the present invention there is provided a computer program product including a computer readable medium having recorded thereon a computer program for rendering one or more text strings, the computer program comprising: code for determining one or more glyphs in said one or more text strings; 705304.doc -6code for determining one or more keming distances between any of said glyphs; code for storing a representation of each of said glyphs and the predetermined kemrning distances; code for determining a list of indices referencing each of the stored representations and the predetermined kerning distances; code for generating one or more rendering instructions based on said representations, the predetermined kerning distances and said list; and code for rendering said text by executing the rendering instuctions.

According to still another aspect of the present invention there is provided a computer program product including a computer readable medium having recorded thereon a computer program for rendering one or more text strings, each of said text strings comprising one or more glyphs, said computer program being being characterised in that kerning distances between each of said glyphs are predetermined and stored prior to rendering said text strings.

According to still another aspect of the present invention there is provided a computer program product for rendering one or more text strings, the computer program comprising: code for determining one or more glyphs in said text strings; code for determining one or more kerning distances between any of said glyphs; code for storing a representation of each of said glyphs and the predetermined kerning distances; code for determining a list of indices referencing each of the stored representations and the predetermined kemrning distances; and code for rendering said text by concatenating said representations based on said list, the concatenated representations being spaced according to the predetermined kemrning distances.

705304.doc -7- According to still another aspect of the present invention there is provided a computer program for rendering one or more text strings, the computer program comprising: code for determining one or more glyphs in said one or more text strings; code for determining one or more kemrning distances between any of said glyphs; code for storing a representation of each of said glyphs and the predetermined kerning distances; code for determining a list of indices referencing each of the stored representations and the predetermined kerning distances; code for generating one or more rendering instructions based on said representations, the predetermined kerning distances and said list; and code for rendering said text by executing the rendering instuctions.

According to still another aspect of the present invention there is provided a computer program product for rendering one or more text strings, each of said text strings comprising one or more glyphs, said computer program being being characterised in that kerning distances between each of said glyphs are predetermined and stored prior to rendering said text strings.

Other aspects of the invention are also disclosed.

Brief Description of the Drawings Some aspects of the prior art and one or more embodiments of the present invention will now be described with reference to the drawings and appendicies, in which: Fig. 1 is a flow diagram showing a method of rendering text; Fig. 2 is a flow diagram showing a method of processing a glyph; Fig. 3A shows an example ofa glyph table; Fig. 3B shows an example of a string table; Fig. 4 shows an outline for a single glyph; 705304.doc -8- Fig. 5 shows two successive glyphs of a text string; Fig. 6 shows a glyph aligned to a right-hand edge of a region; Fig. 7 is a schematic block diagram of a general purpose computer upon which arrangements described can be practiced; and Appendix A shows a section of programming code in the C programming language representing an example set of tags for rendering a glyph.

Detailed Description including Best Mode Where reference is made in any one or more of the accompanying drawings to steps and/or features, which have the same reference numerals, those steps and/or features have for the purposes of this description the same function(s) or operation(s), unless the contrary intention appears.

It is to be noted that the discussions contained in the "Background" section and that above relating to prior art arrangements relate to discussions of documents or devices which form public knowledge through their respective publication and/or use. Such should not be interpreted as a representation by the present inventor(s) or patent applicant that such documents or devices in any way form part of the common general knowledge in the art.

The steps of the methods described herein have been described below with reference to the rendering of text on a user interface. However, it is not intended that the present invention be limited to the described methods. The principles of the methods described herein have general applicability to the rendering of graphical objects.

A method 100 (see Fig. 1) of rendering text, is described below with reference to Figs. 1 to 7. The method 100 may be practiced using a general-purpose computer system 700, such as that shown in Fig. 7 wherein the processes of the methods described below may be implemented as software, such as an application program executing within the computer system 700. Alternatively, the method 100 may be practiced using hand-held 705304.doc -9computers, or special purpose devices such as photocopiers, digital cameras and the like.

The method 100 may also be implemented in a non-interactive application program, such as where text is rendered for display on an electronic sign.

The steps of the method 100 may be effected by instructions in the software that are carried out by the computer system 700. The instructions may be formed as one or more code modules, each for performing one or more particular tasks. The software may also be divided into two separate parts, in which a first part performs the method 100 and a second part manages a user interface between the first part and the user. The software may be stored in a computer readable medium, including the storage devices described below, for example. The software is loaded into the computer from the computer readable medium, and then executed by the computer. A computer readable medium having such software or computer program recorded on it is a computer program product.

The use of the computer program product in the computer preferably effects an advantageous apparatus for implementing the method 100.

The computer system 700 is formed by a computer module 701, input devices such as a keyboard 702 and mouse 703, output devices including a printer 715, a display device 714 and loudspeakers 717. A Modulator-Demodulator (Modem) transceiver device 716 is used by the computer module 701 for communicating to and from a communications network 720, for example connectable via a telephone line 721 or other functional medium. The modem 716 can be used to obtain access to the Internet, and other network systems, such as a Local Area Network (LAN) or a Wide Area Network (WAN), and may be incorporated into the computer module 701 in some implementations.

The computer module 701 typically includes at least one processor unit 705, and a memory unit 706, for example formed from semiconductor random access memory (RAM) and read only memory (ROM). The module 701 also includes a number of 705304.doc input/output interfaces including an audio-video interface 707 that couples to the video display 714 and loudspeakers 717, an IO interface 713 for the keyboard 702 and mouse 703 and optionally a joystick (not illustrated), and an interface 708 for the modem 716 and printer 715. In some implementations, the modem 716 may be incorporated within the computer module 701, for example within the interface 708. A storage device 709 is provided and typically includes a hard disk drive 710 and a floppy disk drive 711. A magnetic tape drive (not illustrated) may also be used. A CD-ROM drive 712 is typically provided as a non-volatile source of data. The components 705 to 713 of the computer module 701, typically communicate via an interconnected bus 704 and in a manner which results in a conventional mode of operation of the computer system 700 known to those in the relevant art. Examples of computers on which the described arrangements can be practised include IBM-PC's and compatibles, Sun Sparcstations or alike computer systems evolved therefrom.

Typically, the application program is resident on the hard disk drive 710 and read and controlled in its execution by the processor 705. Intermediate storage of the program and any data fetched from the network 720 may be accomplished using the semiconductor memory 706, possibly in concert with the hard disk drive 710. In some instances, the application program may be supplied to the user encoded on a CD-ROM or floppy disk and read via the corresponding drive 712 or 711, or alternatively may be read by the user from the network 720 via the modem device 716. Still further, the software can also be loaded into the computer system 700 from other computer readable media. The term "computer readable medium" as used herein refers to any storage or transmission medium that participates in providing instructions and/or data to the computer system 700 for execution and/or processing. Examples of storage media include floppy disks, magnetic tape, CD-ROM, a hard disk drive, a ROM or integrated circuit, a magneto-optical disk, or a computer readable card such as a PCMCIA card and the like, whether or not such 705304.doc 11 devices are internal or external of the computer module 701. Examples of transmission media include radio or infra-red transmission channels as well as a network connection to another computer or networked device, and the Internet or Intranets including e-mail transmissions and information recorded on Websites and the like.

The method 100 may alternatively be implemented in dedicated hardware such as one or more integrated circuits performing the functions or sub functions of the method 100. Such dedicated hardware may include graphic processors, digital signal processors, or one or more microprocessors and associated memories.

The software implementing the user interface described herein may be responsible for presenting a user with available operations from which the user may make a selection.

The software may also notify the user of events that have occurred. Text may be displayed on the user interface in the form of a text string a sequence of data values representing each of a sequence of characters in the text string).

Text strings may be displayed in various screens, controls, dialog boxes and other components of the described user interface. A text definition file may be used to list the text strings that may be displayed in the various screens, controls, dialog boxes and other components of the described user interface. For each such text string listed, a unique textual identifier may be provided.

In one implementation, a complete set of text strings may be defined for each of a plurality of different human languages. Such a complete set of text strings allows a userinterface that may be displayed in a plurality of human languages. In such an implementation, a character encoding method such as the well known Unicode a 16bit code, defined by the Unicode Consortiom) may be used to store sets of text strings where human languages being used are not compatible with the standard ASCII character set.

705304.doc 12- As an example, two unique text strings defined for the languages English and French are shown below: LANGUAGE name=English; TEXT name=OUT, value="Outside"; TEXT name=IN, value="Inside"; (1) LANGUAGE name=French; TEXT name=OUT, value="Exterieur"; TEXT name=IN, value="Interieur"; (2) A graphical or artistic design for graphical user interface components of the user interface may be created. The creation of such a graphical or artistic design results in a set of appearance definition data being established. The definition data comprises information defining the graphical appearance and layout of individual components of the user interface. A particular graphical user interface component may comprise one or more text label objects. For example, appearance definition data for a user-interface component representing a "dialog box" may specify that two text labels are included. The first text label may be used for a caption on a title bar of a dialog box window for the dialog box. The second text label may be used for a message that is written in the body of the dialog box window. The component definition data may comprise information representing the visual appearance of the dialog box, including the size and position of the text labels.

For each text label, a font name for use by a renderer in displaying a given text label may be defined. A set of one or more text identifiers may also be defined for each text label. The text identifiers may be taken from a text definition file. The text identifiers enumerate a set of text strings that are intended to be displayed in a corresponding text label of the user-interface. A given text label in a user-interface component definition may have more than one possible text string, as there may be several distinct instances of a particular user interface component that is displayed to the user with different textual content, either concurrently or at different times. That is, a particular text string may have 705304.doc -13one or more text instances in which the particular text string is displayed. Each particular text instance may differ in regard to particular properties font) of the text string.

A text string being displayed in a given text label of a user-interface component may be altered at run-time, in response to user input or some other external event.

The method 100 of generating text will now be described. The method 100 may be implemented as software resident on the hard disk drive 710 and being controlled in its execution by the processor 704. The method 100 generates a set of data values that may be used by an application program for displaying text on a user-interface. In the method 100, a glyph table glyph table 300 of Fig. 3A) comprising a set of unique glyphs used in the user-interface is generated. The method 100 also generates a string table string table 301 of Fig. 3B) comprising a sequence of indices into the glyph table for glyphs in each text instance. The glyph table and the string table are generated by iterating over each glyph in each text instance of the user-interface.

The method 100 begins at step 110 where a string table and a glyph table configured in memory 706 are initialised by the processor 705 as empty tables containing no entries. The string table and the glyph table may be configured as data structures that store an extensible list of <key, value> pairs.

At the next step 120, the processor 705 detects a next unprocessed text instance a current text instance). The next unprocessed text instance may be sourced from memory 706, from the keyboard 702 via the I/O interface 713, or from the computer network 720 via the 1/O interface 708. A particular text instance may be represented by a choice of text identifier and an associated font. At the next step 130, the processor 705 initially determines a first glyph a current glyph) in the text instance received at step 120. The method 100 then proceeds to step 140, where the processor 705 processes the current glyph. At step 140, the method 100 determines a <key, value> entry in the glyph 705304.doc -14table if one does not already exist. A method 200 of processing a glyph as executed at step 140 will now be described with reference to the flow diagram of Fig. 2.

The method 200 may be implemented as software resident on the hard disk drive 710 and being controlled in its execution by the processor 704. The method 200 begins at step 210, where the current glyph of the current text instance is examined. If the processor 705 determines that a <glyph, font> pair for the current glyph does not yet exist as the 'key' parameter of a <key, value> entry in the glyph table configured in memory 706, then the method 200 proceeds to step 220. Otherwise the method 200 proceeds to step 230. At step 220, a new entry is created with the <glyph, font> pair for the current glyph as the key parameter. The new entry is then added to the glyph table configured within memory 706. The 'value' parameter of the new glyph table entry is an integer value defining the position in the glyph table for the new entry. The position of the glyph table entry assigned for the current glyph is then added to a list of glyph indices configured in memory 706 for the current text instance.

If a <glyph, font> pair for the current glyph already exists as the key parameter of an entry in the glyph table, at step 210, then the method 200 proceeds to step 230. At step 230, the value parameter of the existing entry for the current glyph is added to the list of glyph indices for the current text instance.

The method 200 then proceeds to step 240, where a kerning distance between the current glyph, and a glyph (if any) that occurs immediately after the current glyph in the current text instance, is determined. That is, a spacing between the current glyph and an immediately adjacent glyph in the current text instance, is determined at the next step 250, the processor 705 examines the glyph table to determine if an entry representing the kemrning distance, determined at step 240, exists as the key parameter of an entry in the glyph table. If the processor 705 determines that such a kerning distance does not yet 705304.doc exist as the key parameter of an entry in the glyph table, then the method 200 proceeds to step 260. Otherwise, the method 200 proceeds to step 270.

At step 260, a new entry is created in the glyph table with the kemrning distance determined at step 240 as the key parameter. The new entry is added to the glyph table configured within memory 706. The value of the new glyph table entry determined at step 260 is an integer value giving the position in the glyph table for the new entry. The position of the glyph table entry assigned for the kemrning distance determined at step 240 is then added to the list of glyph indices configured within memory 706 for the current text instance.

At step 270, the position value of the existing entry for the current glyph is added to the list of glyph indices configured within memory 706 for the current text instance. For a kerning distance equal to zero, the step of storing a glyph table entry and recording a glyph table position may be omitted. Following step 260 or 270, execution proceeds to step 150 of the method 100.

If the processor 705 determines that there are any unprocessed glyphs in the current text instance, at step 150, then the method 100 returns to step 130. Thus the method 100 iterates over the sequence of glyphs in the current text instance. Otherwise, if all the glyphs in the current text instance have been processed at step 150, then the method 100 proceeds to step 160. At step 160 the list of glyph indices calculated at steps 220, 230, 260 and 270 for the current glyph are added to the string table configured within memory 706. At the next step 170, if there are any remaining unprocessed text instances, then the method 100 returns to step 120. Otherwise, the method 100 proceeds to step 180. Thus the method 100 iterates over all of the text instances in a set of user-interface components.

At step 180, the processor 705 converts the glyph table entries into rendering data.

For each entry in the glyph table, the outline for a specified glyph code in the specified font may be obtained by opening a file containing a definition of a font a True Type 705304.doc -16font file). An outline of each glyph of the glyph table may be determined via a conversion process. For example, Fig. 4 shows an outline 410 for a single glyph Each entry representing a kemrning distance is similarly converted into an output form at step 180. The output format for each entry representing a kerning distance is the same format used for the glyph outlines. The method 100 then proceeds to step 190, where the string table is output and the method 100 concludes.

In one implementation, data representing the glyph table, associated glyph table entries, the string table and associated string table entries, may be output in the form of C code. The C code may then be utilised by compiling and linking to form an executable program for display on the user-interface. Such C code output may declare and initialise data variables to store tables and table entries.

The method 100 will be explained in more detail by way of several examples with reference to Figs. 3A to 6.

Figs. 3A and 3B show an example of a constructed glyph table 300 and string table 301, respectively, as generated using the method 100. The glyph table 300 and string table 301 comprise entries for two text instances "text" and "exit") in the same font.

A first column 302 of the glyph table 300 indicates an index for an entry in a second column 303. Entries of the glyph table 300 indicated by a single character the character at index 0 of the glyph table 300) represent data forming an outline for a corresponding glyph. Entries of the glyph table 300 indicated by a pair of characters the pair of characters at index 1 of the glyph table 300) represent data forming a keming distance spacing) between two glyphs.

Similarly, a first column 304 of the string table 301 indicates an index for one or more entries in a second column 305. As seen in Fig. 3B, row 2 index 1) of the string table 301 comprises the value representing index 2 of the glyph table 300) indicating that the text string "exit" comprises an entry representing the character 705304.doc -17the value of the entry in column 303 corresponding to index 2 of the glyph table 300).

The next value at row 2 of the string table is representing a keming distance spacing) between the character and the next character of the text string "exit". Similarly, the next value at row 2 of the sting table is representing index 4 of the glyph table 300) indicating that the text string "exit" comprises an entry representing the character the value of the entry in column 303 corresponding to index 4 of the glyph table 300).

As seen in Fig. 3, some glyphs and kerning distances are referenced more than once in the string table 301, but are listed only once in the glyph table 300. For example, the glyph at row 2 of the glyph table 300 is referenced in both rows 1 and 2 of the string table 301.

Data for drawing a particular glyph may be stored in memory 706 as a sequence of tags and numerical arguments, which when processed by a graphical rendering system such as the computer system 700, give instructions for constructing the outline of that particular glyph. Appendix A shows a section of programming code in the C programming language representing an example set of tags for generating and rendering a glyph.

In the example of Appendix A, a declared variable 'Glyph_O' comprises data for drawing a glyph made up of 13 instructions to a graphical rendering system such as the computer system 700. The declared variable 'Glyph_0' also comprises data for associated numerical arguments for each instruction. A "MOVE_TO" instruction at line 11 of the programming code moves a current drawing position. Two numerical arguments following the "MOVE_TO" instruction at line 11 represent distance in x and y co-ordinates to move the current drawing position. A "LINETO" instruction at line 12 of the programming code creates an outline segment from a current drawing position to a new drawing position (thus moving the current drawing position), at a distance in x and y 705304.doc -18co-ordinates given by two numerical arguments following the LINE_TO instruction. A "CURVE TO" instruction at line 13 of the programming code creates a curved outline segment from the current drawing position. The four numerical arguments following the CURVE TO instruction at line 13 give a relative position of a curve control-point and position of an endpoint for the curved outline segment. The position of the curve control point affects the shape and amount of curvature of the curved outline segment.

Fig. 4 shows an outline 410 for a single displayed glyph, From a starting position 401 on a baseline 420, a first tag and following numerical arguments instruct a graphical rendering system such as the computer system 700 to move a current drawing position to a point 405, which is some location on the outline 410 of the displayed glyph.

From the point 405, a sequence of one or more further tags (and associated numerical arguments) instruct the graphical rendering system 700 to create a set of outline segments to create the outline 410 forming the displayed glyph Upon returning to the point 405, a final tag and following numerical arguments instruct the graphical rendering system 700 to move the current drawing position to a point 402 on the baseline 420.

When the set of tag data for the displayed glyph is calculated, the point 402 is selected such that the point 402 lies on the baseline 420 at a distance from initial point 401 equal to the normal width for the displayed glyph A normal width for a displayed glyph includes normal spacing on either side of the glyph, but not additional spacing adjustment that is performed by a kerning process.

The sequence of instructions for displaying a glyph include an instruction for returning a current drawing position to a starting location required for drawing a successive glyph. The sequence of tags for displaying each successive glyph in a text instance may be constructed by concatenating tag data for each glyph in the text instance.

The method 100 alleviates the need for a program for displaying text in a user interface to 705304.doc -19separately obtain the normal width for each glyph and perform a calculation to determine correct placement of each glyph in a displayed text instance.

Fig. 5 shows two successive glyphs 501 and 502 of a text string. As seen in Fig. filled regions occupied by the two glyphs 501 and 502 overlap a right-hand part of the glyph overhangs a left-hand part of the glyph To create such an overlap, the position of the second glyph 502 has been adjusted by having a kemrning distance applied to the glyph 502. The graphics rendering system 700 executes instructions for rendering the first glyph 501, including the step of moving the current drawing position from the final point 510 on the outline of the first glyph 501, to a baseline point 520. Instructions representing a kerning distance 530 are then executed, by moving the current drawing position from the point 520 of the first glyph to a required starting position 540 of the second glyph 502.

The kerning distance 530 may be stored in memory 706 as an instruction to the graphical rendering system 700. The kerning distance may be stored in the same format as is used for storing outlines of glyphs. Therefore, a sequence of instructions to the graphical rendering system 700 for displaying a kerned text string may be constructed by concatenating sequences of instructions representing an interleaved sequence of glyphs and kerning distances.

An alignment type may be defined for each text instance. Such an alignment type specifies that displayed text is positioned at a left-hand edge, a right-hand edge, or centrally located within a defined available width region of a display such as the display 714.

Fig. 6 shows a glyph 600 aligned to a right-hand edge 601 of a region 610. The region 610 may be defined on the display screen 714, for example. The width of the region 610 may be configured as part of a specification of the appearance of a relevant user-interface component. For example, a group of related text instances may be aligned 705304.doc in a set of regions of the same width. A sequence of tags for constructing an outline of the displayed glyph 600, may define a current drawing position to begin at point 620, as shown in Fig. 6. The point 620 is positioned on a text baseline 603 at a left-hand edge 602 of the region 610. A string table entry for the text instance comprising the glyph 600 begins with an additional spacing distance 630. The additional spacing distance 630 may be stored as an entry in a glyph table configured within memory 706 and corresponding to the string table for the text string comprising the glyph 600. The glyph table entry defining the additional spacing distance 630 is processed in the same manner as a kerning distance as described above. From point 640, drawing of the glyph 600 occurs as previously described above for the glyph 501, such that a final drawing position is located on the text baseline 603 at the right-hand edge 601 of the region 610 at point 660.

Other typesetting functionality may be implemented by providing appropriate instructions to a renderer. Such instructions may be stored in a glyph table such as the glyph table 300 and referenced by an index in a corresponding string table 301). For example, a text string may be typeset over multiple lines by including a spacing instruction that is calculated to represent the action of moving a current drawing position to a starting location of a subsequent line of displayed text. In a further example, an additional spacing distance may be factored in to a kerning distance for each pair of characters, in order to display text where glyphs are further apart (or closer together) than normal. In a still further example, the glyphs in a displayed text string may be laid out on a baseline that is at an oblique angle, or is vertical, or consists of a plurality of line segments or curves. The methods described above may also be used for displaying text strings for languages that are typeset in a right to left direction.

Glyph tables and string tables such as the glyph table 300 and string table 301 described above provide several advantages. Firstly, the amount of space required for storing data for calculating the appearance of displayed textual information is minimised.

705304.doc -21 The glyph table 300 comprises only entries for glyphs that are used in a user-interface that is being displayed. Therefore storage space in memory such as the memory 706 is not wasted by the inclusion of glyphs that do not appear in the user-interface that is being displayed.

Additionally, the glyph table 300 comprises kerning distances only for pairs of glyphs that occur sequentially in a displayed user-interface. Accordingly, the glyph table 300 uses less storage space than, for example, storing a list or two-dimensional array comprising a kerning distance for every possible pair of glyphs. The glyph table 300 is particularly advantageous for user-interfaces that use a variety of different fonts.

A second advantage of the methods described above is that stored data may be processed efficiently. In a graphics rendering system using the described methods, the visual appearance of a user interface is determined by rendering a current set of displayed shapes stored in memory memory 706) as outlines. In this example, the data is outline data representing instructions for a graphics rendering system is stored in memory.

In the methods described above, sequences of such instructions for both glyphs and kerning distances exist in memory. Accordingly, the need for rendering system to detennrmine such instructions at run-time, or temporarily allocate, manage, and free memory for storing the instructions is alleviated.

The aforementioned preferred method(s) comprise a particular control flow. There are many other variants of the preferred method(s) which use different control flows without departing the spirit or scope of the invention. Furthermore one or more of the steps of the preferred method(s) may be performed in parallel rather sequential.

The foregoing describes only some embodiments of the present invention, and modifications and/or changes can be made thereto without departing from the scope and spirit of the invention, the embodiments being illustrative and not restrictive. For example, in one implementation a separate glyph table and string table may be created for 705304.doc -22 each distinct "unit" of a user-interface. In such an implementation, a unit may be a set of related screens, for example. Such an implementation allows text data for a current screen to be dynamically loaded into memory 706.

In the context of this specification, the word "comprising" means "including principally but not necessarily solely" or "having" or "including", and not "consisting only of'. Variations of the word "comprising", such as "comprise" and "comprises" have correspondingly varied meanings.

705304.doc -23- Appendix A struct int tagsNb; int const Glyph45 Glyph_0 13, MOVE TO, 73, -289, LINE TO, 58, 131, CURVE TO, 4, 7, 2, 12, CURVE TO, 3, 12, 0, 7, CURVE TO, -26, 5, -12, LINE TO, 60, -131, LINE TO, 82, 0, LINETO, -189, 417, LINE TO, -81, 0, LINE TO, 86, -189, LINE TO, -105, -228, LINE TO, 84, 0, MOVE TO, -73, 289 705304.doc

Claims (4)

1. A method of rendering one or more text strings, the method comprising steps of: determining one or more glyphs in said text strings; determining one or more kerning distances between any of said glyphs; storing a representation of each of said glyphs and the predetermined kerning distances; determining a list of indices referencing each of the stored representations and the predetermined kerning distances; and rendering said text by concatenating said representations based on said list, the concatenated representations being spaced according to the predetermined kerning distances.

2. A method according to claim 1, further comprising the step of generating one or more rendering instructions based on said representations, the predetermined kerning distances and said list.

3. A method according to claim 2, further comprising the step of storing said one or more rendering instructions.

4. A method according to claim 3, further comprising the step of rendering said text according to the stored rendering instructions. A method according to claim 1, wherein a single representation of a glyph that occurs multiple times in said text strings is used to render said glyph each time that said glyph occurs in said text string.

705304.doc 6. A method according to claim 1, further comprising the step of determining a spacing distance associated with any of said glyphs. 7. A method according to claim 6, said method further comprising the step of storing s said spacing distance together with said representation of each of said glyphs and the predetermined kemrning distances. 8. A method according to claim 2, said method further comprising the step of moving a current drawing position from a point adjacent a baseline of a particular glyph to a point on an outline of said particular glyph. 9. A method according to claim 8, said method further comprising the step of generating an outline of said particular glyph. 10. A method according to claim 9, said method further comprising the step of moving said current drawing position from said point on said outline of said particular glyph to a further point adjacent said baseline of said particular glyph. 11. A method of rendering one or more text strings, the method comprising steps of: determining one or more glyphs in said one or more text strings; determining one or more kerning distances between any of said glyphs; storing a representation of each of said glyphs and the predetermined kerning distances; determining a list of indices referencing each of the stored representations and the predetermined kemrning distances; 705304.doc -26- generating one or more rendering instructions based on said representations, the predetermined kerning distances and said list; and rendering said text by executing the rendering instuctions. 12. A method according to claim 11, further comprising the step of storing said one or more rendering instructions. 13. A method according to claim 12, further comprising the step of rendering said text according to the stored rendering instructions. 14. A method according to claim 11, wherein a single representation of a glyph that occurs multiple times in said text strings is used to render said glyph each time that said glyph occurs in said text string. 15. A method according to claim 11, further comprising the step of determining a spacing distance associated with any of said glyphs. 16. A method according to claim 15, said method further comprising the step of storing said spacing distance together with said representation of each of said glyphs and the predetermined kemrning distances. 17. A method according to claim 12, said method comprising the step of moving a current drawing position from a point adjacent a baseline of a particular glyph to a point on the outline of said particular glyph. 705304.doc -27- 18. A method according to claim 17, said method further comprising the step of generating an outline of said particular glyph. 19. A method according to claim 18, said method further comprising the step of moving said current drawing position from said point on the outline of said particular glyph to a further point adjacent said baseline of said particular glyph. A method of rendering one or more text strings, each of said text strings comprising one or more glyphs, said method being characterised in that kerning distances between each of said glyphs are predetermined and stored prior to rendering said text strings. 21. An apparatus for rendering one or more text strings, the apparatus comprising: glyph determining means for determining one or more glyphs in said text strings; kerning distance determining means for determining one or more kerning distances between any of said glyphs; storage means for storing a representation of each of said glyphs and the predetermined kerning distances; list determining means for determining a list of indices referencing each of the stored representations and the predetermined kerning distances; and rendering means for rendering said text by concatenating said representations based on said list, the concatenated representations being spaced according to the predetermined kerning distances. 22. An apparatus for rendering one or more text strings, the apparatus comprising: glyph determining means for determining one or more glyphs in said one or more text strings; 705304.doc -28- keming distance determining means for determining one or more kerning distances between any of said glyphs; storage means for storing a representation of each of said glyphs and the predetermined kerning distances; list determining means for determining a list of indices referencing each of the stored representations and the predetermined keming distances; rendering instruction determining means for generating one or more rendering instructions based on said representations, the predetermined kerning distances and said list; and rendering means for rendering said text by executing the rendering instuctions. 23. An apparatus for rendering one or more text strings, each of said text strings comprising one or more glyphs, said apparatus being characterised in that kerning distances between each of said glyphs are predetermined and stored prior to rendering said text strings. 24. A computer program product comprising a computer readable medium comprising recorded thereon a computer program for rendering one or more text strings, the computer program comprising: code for determining one or more glyphs in said text strings; code for determining one or more kerning distances between any of said glyphs; code for storing a representation of each of said glyphs and the predetermined kerning distances; code for determining a list of indices referencing each of the stored representations and the predetermined kerning distances; and 705304.doc -29- code for rendering said text by concatenating said representations based on said list, the concatenated representations being spaced according to the predetermined kerning distances. 25. A computer program product including a computer readable medium having recorded thereon a computer program for rendering one or more text strings, the computer program comprising: code for determining one or more glyphs in said one or more text strings; code for determining one or more kerning distances between any of said glyphs; code for storing a representation of each of said glyphs and the predetermined kerning distances; code for determining a list of indices referencing each of the stored representations and the predetermined kerning distances; code for generating one or more rendering instructions based on said representations, the predetermined kerning distances and said list; and code for rendering said text by executing the rendering instuctions. 26. A computer program product including a computer readable medium having recorded thereon a computer program for rendering one or more text strings, each of said text strings comprising one or more glyphs, said computer program being being characterised in that kerning distances between each of said glyphs are predetermined and stored prior to rendering said text strings. 27. A computer program product for rendering one or more text strings, the computer program comprising: code for determining one or more glyphs in said text strings; 705304.doc code for determining one or more kerning distances between any of said glyphs; code for storing a representation of each of said glyphs and the predetermined kerning distances; code for determining a list of indices referencing each of the stored representations and the predetermined kerning distances; and code for rendering said text by concatenating said representations based on said list, the concatenated representations being spaced according to the predetermined kerning distances. 28. A computer program for rendering one or more text strings, the computer program comprising: code for determining one or more glyphs in said one or more text strings; code for determining one or more kerning distances between any of said glyphs; code for storing a representation of each of said glyphs and the predetermined kemrning distances; code for determining a list of indices referencing each of the stored representations and the predetermined kemrning distances; code for generating one or more rendering instructions based on said representations, the predetermined keming distances and said list; and code for rendering said text by executing the rendering instuctions. 29. A computer program product for rendering one or more text strings, each of said text strings comprising one or more glyphs, said computer program being being characterised in that kerning distances between each of said glyphs are predetermined and stored prior to rendering said text strings. 705304.doc 31 A computer program according to any one of claims 27 to 29, wherein said program is resident in memory of an apparatus and is executed by one or more processors of said apparatus. 31. A method of rendering one or more text strings, the method being substantially as herein before described with reference to Figs. 1 to 7. DATED this Fourth Day of January, 2005 CANON KABUSHIKI KAISHA Patent Attorneys for the Applicant SPRUSON FERGUSON 705304.doc