Method for allowing single-byte character set and double-byte character set fonts in a double-byte character set code page5689723Abstract The method of the invention allows both single-byte character set (SBCS) and double-byte character set (DBCS) fonts in a DBCS code page. The invention stores the SBCS and DBCS text of the document in separate areas. Each area contains the following specific information about the text: the actual text itself, the length in bytes of the text, the horizontal starting position of the text, the font attributes for that text, a flag to indicate that the text is SBCS or DBCS text, and the value which points to the next area containing some text. The font attributes contain information such as the font typeface name, point size, color, weight, width, and the value to indicate whether the font type is an SBCS or a DBCS font type. A document is then set up to use different fonts, SBCS or DBCS, for specific sections of text and alternating back and forth between the fonts as many times as is necessary. The text of the document that uses the different fonts will be in separate areas and each area will contain its own text and font specific information. Claims What is claimed is: Description BACKGROUND OF THE INVENTION
______________________________________
Table 1 for FIG. 5
Single-Byte Text Using a Single-Byte Font
This text string is English text. All of the text is represented by
one text node. The font being used has the following attributes set:
Code Page - 850
______________________________________
Family Times Roman
Weight medium
Italic off
Width normal
Uline off
Over off
Box off
Color Black
Base base
Size 36 point
These attributes are stored in the font table entry 1 which is the font
index stored in the text node.
______________________________________
FIG. 6 illustrates a text node and the corresponding font table and font attributes for DBCS text using a DBCS font. Reference should be made to Table 2 which shows greater detail of the contents of FIG. 6.
______________________________________
Table 2 for FIG. 6
Double-Byte Text Using & Double-Byte Font
This text string is double-byte Kanji text in Kanji state. All of the
text is
represented by one text node. The font being used has the following
attributes set:
Code Page - 942
______________________________________
Family Mincho
Weight medium
Italic off
Width normal
Uline off
Over off
Box off
Color Black
Base base
Size 48 point
These attributes are stored in the font table entry 1 which is the font
index stored in the text node.
______________________________________
FIG. 7 illustrates a sequence of nine text nodes and their corresponding font tables and font attributes for a mixed text of SBCS and DBCS characters. Reference should be made to Table 3 to illustrate in more detail the contents of the various portions of FIG. 7. Still further, FIG. 8 illustrates the WYSIWYG ("what you see is what you get") appearance of the text which is specified by the text nodes illustrated in FIG. 7.
TABLE 3
______________________________________
Mixed Single/Double-Byte Text Using Mixed Single/Double-Byte Fonts
This text string consists of the following: A single-byte English string
in
normal state taking up one text node 701. The font being used has the
following attributes:
Code Page - 850
______________________________________
Family Times Roman
Weight medium
Italic off
Width normal
Uline off
Over off
Box off
Color Black
Base base
Size 36 point
These attributes are stored in the font table entry 711 which is the
font
index stored in the text node.
______________________________________
A double-byte Hiragana string in normal state taking up one text node 702. The font being used has the following attributes:
______________________________________
Code Page - 942
______________________________________
Family Mincho
Weight medium
Italic off
Width normal
Uline off
Over off
Box off
Color Black
Base base
Size 30 point
______________________________________
These attributes are stored in the font table entry 712 which is the font index stored in the text node. A second double-byte Hiragana string in normal state taking up one text node 703. The font being used has the following attributes:
______________________________________
Code Page - 942
______________________________________
Family Mincho
Weight bold
Italic off
Width normal
Uline off
Over off
Box off
Color Black
Base base
Size 30 point
______________________________________
These attributes are stored in the font table entry 713 which is the font index stored in the text node. A second single-byte English string in normal state taking up one text node 704. The font being used has the following attributes:
______________________________________
Code Page - 850
______________________________________
Family Helvetica
Weight bold
Italic off
Width normal
Uline off
Over off
Box off
Color Black
Base base
Size 36 point
______________________________________
These attributes are stored in the font table entry 714 which is the font index stored in the text node. A third single-byte English string in normal state taking up one text node 705. The font being used has the following attributes:
______________________________________
Code Page - 850
______________________________________
Family Gothic
Weight bold
Italic off
Width normal
Uline off
Over off
Box off
Color Black
Base base
Size 30 point
______________________________________
These attributes are stored in the font table entry 715 which is the font index stored in the text node. A double-byte Kanji string in normal state taking up one text node 706. The font being used has the following attributes:
______________________________________
Code Page - 942
______________________________________
Family Gothic
Weight bold
Italic off
Width normal
Uline off
Over off
Box off
Color Black
Base base
Size 30 point
______________________________________
These attributes are stored in the font table entry 716 which is the font index stored in the text node. A second double-byte Kanji string in normal state taking up one text node 707. The font being used has the following attributes:
______________________________________
Code Page - 942
______________________________________
Family Mincho
Weight medium
Italic off
Width normal
Uline off
Over off
Box off
Color Black
Base base
Size 31 point
______________________________________
These attributes are stored in the font table entry 717 which is the font index stored in the text node. A fourth single-byte English string in normal state taking up one text node 708. The font being used has the following attributes:
______________________________________
Code Page - 850
______________________________________
Family Times Roman
Weight bold
Italic off
Width normal
Uline off
Over off
Box off
Color Black
Base base
Size 30 point
______________________________________
These attributes are stored in the font table entry 718 which is the font index stored in the text node. A third double-byte Kanji string in normal state taking up one text node 709. A font being used has the following attributes:
______________________________________
Code Page - 942
______________________________________
Family Mincho
Weight medium
Italic off
Width normal
Uline off
Over off
Box off
Color Black
Base base
Size 31 point
______________________________________
These attributes are stored in the font table entry 717 which is the font index stored in the text node. Since this text has the same font attributes as the second double-byte Kanji string, the font attribute table entry is reused by storing the same font index in the text node. FIG. 9 is a flow diagram of the sequence of operational steps for the method 500 which is a method for creating SBCS and DBCS font index. The method 500 of FIG. 9 creates the text nodes for characters as they are typed into the system shown in FIG. 1. As the operator types in characters, if the operator switches fonts or switches the character set, the method of FIG. 9 will adapt to that and generate additional sequential text nodes to define the text and to faithfully reproduce the WYSIWYG appearance of the text. FIG. 9 starts with step 502 which gets a character, usually from the keyboard 112. Then step 504 determines whether the typed character is an SBCS character. If it is not, then step 506 sets the DBCS flag to one. Alternately, if it is an SBCS character, then step 508 sets the DBCS flag to zero. Then step 510 checks the current document position. The current document position is the current location of the cursor in the editor. As the operator sequentially types characters into the editor, the document position advances and corresponds to the cursor position shown on the display of the system. Then in step 512, it is determined whether the DBCS flag is set to 0 and the document position is in an SBCS area of the text being typed. If it is, then the method flows to step 514 which inserts the character in the text node. For example, in FIG. 5, the next character will be inserted into the text node of the SBCS text node illustrated. Then in step 516 of FIG. 9, if it is appropriate, such as at the end of a line, the document is reformatted. This can for example be a word wrap operation where if the word extends beyond the right hot zone, then the entire word is transferred to the beginning of the left margin on the next line. Then in step 518, the character is displayed in WYSIWYG form on the monitor of the system. Then step 518 flows back to the beginning of the method 500 of FIG. 9, to get the next character in step 502. If step 512 was not satisfied, that is if either the DBCS flag is not zero or the document position is not SBCS, then step 512 flows to step 520. In step 520, a determination is made whether the DBCS flag is set to zero and the document position is DBCS. If it is, then step 522 creates an SBCS text node. Reference can be made at this point to FIG. 6 which shows the beginning condition and FIG. 5 which shows the next condition resulting from step 522. If step 520 determines that the current character is an SBCS character and that the document position is currently DBCS, then the current text node is similar to that shown in FIG. 6. But this is not an SBCS text node. Therefore, step 522 creates the next consecutive text node which is an SBCS text node such as is shown in FIG. 5. The character which has been typed, which is an SBCS character, is the first character inserted into the text character portion of the text node illustrated in FIG. 5. Then step 524 executes the process of FIG. 10, which updates the SBCS or DBCS font table entry. The process of FIG. 10 will be described below, after further describing the rest of the steps in the flow diagram of FIG. 9. In the flow diagram of FIG. 9, if step 520 determines that the DBCS character is not equal to the zero or that the document position is not DBCS, then step 520 flows to step 526. Step 526 determines whether the DBCS flag is set equal to one and whether the document position is SBCS. If both of these conditions are satisfied, then step 526 flows to step 528 which creates the DBCS text node. In a sense, this is a mirror image of the transition from step 520 to step 522. When step 526 transitions to step 528, it has been determined that there is the character which has just been typed is a DBCS character and yet the document position is currently at SBCS portion of the text. Reference can be made to FIG. 5 which shows the before condition and FIG. 6 which shows the after condition from the execution of step 528 of FIG. 9. If the current document position is SBCS, then the text node shown in FIG. 5 is currently being filled, for SBCS text. Since the new character which has just been typed is determined to be a DBCS character, step 528 creates a DBCS text node such as is shown in FIG. 6 and the currently typed character is now the first character to be inserted into the text portion of the text node shown in FIG. 6. Then step 528 of FIG. 9 transfers to step 524. As previously mentioned, step 524 will be discussed below. After step 524 has been executed, the process 500 of FIG. 9 flows to step 514 and the new character is inserted into the text node which has just been created. Steps 514, 516 and 518 have been previously described. If step 526 in FIG. 9 is not satisfied, that is if either the DBCS flag is not equal to one or the document position is not SBCS, then step 526 flows to step 530. Step 530 determines whether the DBCS flag is set equal to one and whether the document position is DBCS. If that condition is satisfied, then step 530 flows to step 514 and the DBCS character is inserted into the DBCS text node currently being filled. If step 530 is not satisfied, then all of the possible values for the DBCS flag and the document position have been tested and an error has been made so the process 500 flows to step 532 to process an error condition. FIG. 10 carries out the process 524 in the step 524 of FIG. 9. The process 524 of FIG. 10 is a method for updating or creating a new SBCS or DBCS font table entry, such as those not shown in FIGS. 3 and 4. The process 524 of FIG. 10 begins with step 602 which starts at the beginning of the editor font table. Then step 604 determines whether the font attributes match the editor font table entry attributes. If they do, then the flow proceeds from step 604 to step 606 which returns the font index into the editor's font table of the font to use and the program returns to the flow diagram 500 of FIG. 9. Alternately, if step 604 determines that the font attributes do not match the editor font table entry attributes, then the process of FIG. 10 flows to step 608 which moves to the next font table entry. Step 608 then transitions to step 610 which determines if this is the last font table entry. If it is not, then step 610 flows back to the beginning of step 604 to determine if the font attributes match the editor font table entry attributes. Alternately, if step 610 determines that this is the last font table entry, then the process 524 of FIG. 10 flows to step 612 which starts the beginning of the operating system font table. The operating system in this example, can be the IBM OS/2 Operating System, which contains a large font table which includes both SBCS and DBCS fonts. Then step 612 transitions to step 614 which determines whether the font attributes match the operating system font table entry attributes. If they do, then step 614 transitions to step 616, which creates the font using the font's code page. Then step 616 transitions to step 618 which appends the operating system font attributes to the end of the editor's font table. Then step 618 transitions to step 606 which returns the font index into the editor's font table of the font to use. Then the process of FIG. 10 returns to the process previously described in FIG. 9. If step 614 determines that the font attributes do not match the operating system font table entry attributes, then step 614 transitions to step 620 which moves to the next font table entry in the operating system font table. Step 620 then transitions to step 622 which determines whether this is the last font table entry for the operating system font table. If it is not, then step 622 transitions to the beginning of step 614 to determine if the font attributes match the operating system font table entry attributes. Alternately, if step 622 determines that this is the last font table entry for the operating system font table, then step 622 transitions to step 624 which substitutes a default operating system font. A default operating font can be any alternate font which will represent the meaning of the originating author's text but which cannot be replicated by the fonts currently stored in the system. Step 624 then transitions to steps 616, 618 and 606, which have been previously described. Then the process 524 of FIG. 10 returns to the flow diagram illustrated in FIG. 9. Although a specific embodiment of the invention has been disclosed, it will be understood by those having skill in the art that changes can be made to that specific embodiment without departing from the spirit and the scope of the invention.
|
Same subclass Same class Consider this |
||||||||||
