WO1994023379A1

WO1994023379A1 - Font selection system

Info

Publication number: WO1994023379A1
Application number: PCT/US1994/000018
Authority: WO
Inventors: Russel Sonnenschein
Original assignee: Taligent, Inc.
Priority date: 1993-04-05
Filing date: 1994-01-03
Publication date: 1994-10-13
Also published as: AU6390994A; US5500931A

Abstract

A method and system for automatically selecting a set of characters and applying a font so that a user sees the characters and fonts expected to appear in a document. The preferred embodiment of the invention is used when a client applies a font style change to a range of characters. The logic intelligently applies the font style to the selection. For example, applying the Chicago font to the characters 'Σ n/2' would produce 'Σ n/2'.

Description

FONT SELECTION SYSTEM

COPYRIGHT NOTIFICATION

Portions of this patent application contain materials that are subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure, as it appears in the Patent and Trademark Office patent file or records, but otherwise reserves all copyright rights whatsoever.

CROSS-REFERENCE TO RELATED PATENT APPLICATIONS

This patent application is related to the patent application entitled Object Oriented Framework System, by Debra L. Orton, David B. Goldsmith, Christopher P. Moeller, and Andrew G. Heninger, filed 12/23/92, and assigned to Taligent, the disclosure of which is hereby incorporated by reference.

This patent application is related to the patent application entitled TEXT INPUT FONT SYSTEM, by Russell Sonnenschein and Mark Davis, filed concurrently with this application, and assigned to Taligent, the disclosure of which is hereby incorporated by reference.

Field of the Invention

This invention generally relates to improvements in computer systems and more particularly to intelligently adding font styles as text is entered into a computer.

Background of the Invention

Systems such as the Apple ® Macintosh ® or Microsoft ® Windows (TM) overload the meaning of their character codes. For example the code 0x53 might represent the roman character 'S' or the Greek character 'S' depending upon the context. This overloading of character codes creates problems when clients need to edit text with multiple scripts and symbols. A script is a collection of character codes that have meanings that are semantically related. Usually a language maps into a single script. For example, encodings for Roman, Greek and Hebrew are all separate scripts. Almost all commercial systems overload the semantics of their character encoding. Some systems do so with code page architectures, others do it simple by changing a font — which is similar to specifying a code page. Code pages are common to IBM systems. The context of a character depends upon the font or code page currently in use. Most systems can't even handle text from multiple scripts. Many that can, can only handle text in at most two scripts. Most systems also cannot detect, when a character is entered, if that character exists in the current font. Thus, someone might think that they were entering a 'S' but the character might display as a 'S' depending upon the current font. This is because the system cannot distinguish what a character's semantics is based solely on the character code. Some systems try to deal with the problem at the user interface level by associating a keyboard with a specific font. However, this type of solution does not work when characters are programmatically entered without the use of a keyboard.

There is another problem caused by the overloading of character codes.

When a client tries to apply a font style to a string of characters from different scripts, the characters may become garbled. For example, text might contain a simple equation like "S n/2". A user might want to change the font on the text to something a little bolder looking like a Chicago font. The user would select the equation, change the font, and the result would look like "S n/2". The problem is even worse when the selection contains characters from many different scripts.

Both of these problems are inherent to systems that overload character codes. Systems that are based on an universal encoding, where all characters have unique codes, have the opportunity to work around these problems. However, to date, these systems have not effectively dealt with the problem. Systems that use universal character encoding, such as a system produced by Xerox, generally only indicates that a character is missing from the current font. For example, the sigma ould display as a missing glyph rather than mapping it to some random glyph. A glyph is a visual representation of a character code. Prior art code page based systems would map the character to a random glyph.

Summary Of the Invention

Accordingly, it is a primary objective of the present invention to provide a system and method for automatically selecting a font so that a user sees the characters and fonts expected to appear in a document. The preferred embodiment of the invention is used when a client applies a font style change to a range of characters. The logic intelligently applies the font style to the selection. For example, applying the Chicago font to the characters "∑ n/2" would produce "∑ n/2" even though the Chicago font does not have a ∑.

Brief Description of the Drawings

Figure 1 is a block diagram of a personal computer system in accordance with the subject invention;

Figure 2 sets forth the logic for automatically styling a character with a new font style when the current font cannot display the character in accordance with the subject invention;

Figure 3 is a flowchart of the logic for finding a font that matches in accordance with the subject invention;

Figure 4 illustrates an example of glyph insertion in accordance with the subject invention;

Figure 5 illustrates an example of missing characters in accordance with the subject invention;

Figure 6 illustrates an example of font processing in accordance with the subject invention;

Figure 7 is a flowchart of glyph processing in accordance with the subject invention;

Figures 8a, 8b, 8c, 8d, 8e and 8f are examples of typing style modification in accordance with the subject invention;

Figure 9 is a flowchart of the logic for setting a font on a text selection in accordance with the subject invention;

Figure 10 is another flowchart of alternative logic for setting a font on a text selection in accordance with the subject invention;

Figure 11 is an example of a Greek sentence in accordance with the subject invention; Figure 12 is an example of applying the logic set forth in Figure 10 to the Greek sentence in Figure 11 in accordance with the subject invention;

Figure 13 is an example of applying the logic set forth in Figure 9 to the Greek sentence in Figure 11 in accordance with the subject invention;

Figure 14 sets forth five Greek words for an example in accordance with the subject invention;

Figure 15 is an example of applying a Chicago font to the Greek words set forth in Figure 14 in accordance with the subject invention;

Figure 16 is an example of applying a Greek font to the Greek words set forth in Figure 14 in accordance with the subject invention;

Figure 17 is an example of applying a Courier font to the Greek words set forth in Figure 14 in accordance with the subject invention;

Figure 18 is an example of applying a Zapf Dingbats font to the Greek words set forth in Figure 14 in accordance with the subject invention;

Figure 19 is an example of applying a Zapf Dingbats font to the Greek words using a prior art system;

Figure 20 is an example of applying a Courier font to the Greek words using a prior art system; and

Figure 21 is an example of applying a Courier font to Hebrew on a Macintosh prior art computer system.

Detailed Description Of The Invention

A preferred embodiment of the invention is practiced in the context of an operating system resident on a personal computer such as the IBM ® PS/2 ® or Apple ® Macintosh ® computer. A representative hardware environment is depicted in Figure 1, which illustrates a typical hardware configuration of a workstation in accordance with the subject invention having a central processing unit 10, such as a conventional microprocessor, and a number of other units interconnected via a system bus 12. The workstation shown in Figure 1 includes a Random Access Memory (RAM) 14, Read Only Memory (ROM) 16, an I/O adapter 18 for connecting peripheral devices such as disk units 20 to the bus, a user interface adapter 22 for connecting a keyboard 24, a mouse 26, a speaker 28, a microphone 32, and /or other user interface devices such as a touch screen device (not shown) to the bus, a communication adapter 34 for connecting the workstation to a data processing network and a display adapter 36 for connecting the bus to a display device 38. The workstation has resident thereon an operating system such as the Apple System/ 7 ® operating system.

A preferred embodiment employs two processes, used by the text subsystem, to manipulate character codes and font styles. The first process intelligently adds font styles to characters upon text entry. The second process applies font styles to a selection containing characters from multiple scripts.

As mentioned before, systems such as the Apple ® Macintosh ® overload the meaning of their character codes. For example the code 0x53 might represent the roman character 'S' or the Greek character '∑' depending upon the context. This overloading of character codes creates problems when clients need to edit text with multiple scripts and symbols. The context of a character depends upon the font or code page currently in use.

Most systems cannot detect, when a character is entered, if that character exists in the current font. Thus, someone might think that they were entering a '∑' but the character might display as a 'S' depending upon the current font. This is because the system cannot distinguish what a character's semantics is based solely by examining the character code. Some systems try to deal with the problem at the user interface level by associating a keyboard with a specific font. However, this type of solution is impossible when characters are programmatically entered without a keyboard.

There is another problem caused by the overloading of character codes. When a client tries to apply a font style to a string of characters from different • scripts, the characters may become garbled. For example, text might contain a simple equation like "∑ n/2". A user might desire to change the font on the text to something a little bolder looking, for example, a Chicago font. The user would select the equation, change the font, and the result would look like "S n/2". The problem is even worse when the selection contains characters from many different scripts.

Both of these problems are inherent to systems that overload character codes.

Systems that are based on a universal encoding, where all characters have unique codes, have the opportunity to work around these problems. However, to date these systems have not effectively dealt with the problem.

Systems that use universal character encoding, such as a system produced by

Xerox, only indicate that a character is missing from the current font. For example, a sigma would display as a missing glyph rather than mapping to a random glyph.

A preferred embodiment employs two sets of processes, one for text entry and one for applying font styles to a text selection. A font style is just a symbolic reference to a font. All the functionality of a font is available through a font style. This processing eliminates problems experienced in other systems. By combining these processes, a user always sees the character that he expected to see, in the font he expected to see it in.

The first process is used when a character, or string of characters, is entered into a text stream. If the character is missing from the font specified in the current typing style the process will choose a font that can display the character. For example, if the code for a "∑" is inserted before "n/2" the process would automatically style the code with a font that could display the "∑."

The second process is used when a client applies a font style change to a range of characters. The process intelligently applies the font to the selection. For example, applying a preferred embodiment of the invention, Chicago font to the characters "∑ n/2" would produce "∑ n/2".

Both of the processes can be used by code page based systems if:

• they have the ability to track the code page with their character codes,

• their systems can handle characters from multiple code pages within a single stream of text, and

• they have the ability to detect if a character is missing. In practice, it is more difficult, but not impossible, for code page based systems to use a process like the ones described below. The reason why it is harder for code page based system to make use of these processes is that they usually have one or more of the following restrictions that complicate their situation: • they can only handle a single code page at a time,

• they overlap characters within a single code page,

• they can't detect if a character is missing from a font or,

• they map the same character to multiple code pages.

That is why these processes are of more use to systems that use a universal character encoding such as Unicode. The process behaves the same if it is invoked once with all the input text, or if it is called repeatedly with successive pieces of all the text.

Changing The Typing Font For Text Input

The logic set forth in Figure 2 automatically styles a character with a new font style when the current font cannot display the character. The process iterates on the input text to determine if the font associated with the current character can display that character. If not, it tries to find a font that can. The process then tries to keep all subsequent characters of the input text in the same font.

With reference to Figure 3, to find a font that can display the current character, the process parses all the previous characters in the text stream and then parses all subsequent characters until a font referenced by one of those characters can display the current character. If no font is found, the system searches all the available fonts on the system (in a sorted order either specified by a user preference or by a stylistic matching process).

Every character in a text stream has a font style associated with it. Usually the font style will initially be set from a typing style, but it may also be set by another means. Characters can have a NIL style which is similar to a font that cannot display any characters. Second, the processes refer to a special missing glyph font. This is a special font that is used for character substitution purposes only — when no other font can display a character. In a preferred embodiment, this font will map the characters in an entire script range to a single glyph. For example, all Cyrillic characters mught display as a backwards R (the Cyrillic letter IA).

Processing commences in Figure 2 at terminal 200 and immediately passes to function block 210 to obtain the text input and identify the insertion point for the new text. Then, at function block 220, the input text is styled and inserted into the text string at the insertion point. At decision block 222, all the inserted characters are processed until insertion processing is completed. When insertion processing is completed, then the typing style is equated with the font style of the last character processed at function block 224 and processing is completed at terminal 226.

Iteration of inserted characters is processed in the loop commenced at decision block 230 where a test is performed to determine if the current character is in the last font processed set. As set forth in function block 240, this processing attempts to map the character code to a valid glyph and returns true if a valid glyph exists. If a valid glyph is obtained, then newfont is equated to lastfontprocessed in function block

262, the current character is styled with the newfont, lastfontprocessed is set equal to newfont, and processing is passed to decision block 222 to determine if all insertion characters have been processed.

If a valid glyph is not detected at decision block 230, then a further test is performed at decision block 250 to determine if the current character is in the character's own font style. If so, then lastfontprocessed is set equal to the current character's font and control is passed to decision block 222 to determine if additional characters are available for insertion. If the current character is not in the character's own font style at decision block 250, then a font must be found using the logic set forth in Figure 3. Then, a test is performed at decision block 264 to determine if a font was found. If no font was located, then the character is styled with a predefined missing glyph system font and control is passed to decision block 222 if additional characters are to be inserted. If a font was located at decision block 264, then control passes to function block 266 to set newfont equal to found font, style the current character with the new font, set lastfontprocessed equal to newfont at function block 268, and return control to decision block 222 to determine if additional characters remain to be processed.

Figure 3 sets forth the detailed logic for finding a font in accordance with the subject invention. Processing commences at function block 310 where the text stream is obtained and a pointer to the initial character is identified. Then, at decision block 320, each character y from the initial character to the beginning of the text is checked and a determination is made at decision block 330 to determine if the character is available in the y's font. If the character is available, then the font is returned at terminal 370. If the character is not available, then decision block 320 is executed to determine if additional characters remain for processing. When all characters have been processed backward, then another loop is commenced at decision block 340 for each character x from z until the end of the text to determine at decision block 350 if z is available in x's font. If a font is available, then the font is returned at terminal 370. If not, then the next character is processed at decision block 340 until all characters are processed. Then, at function block 360, a list of fonts is created and at decision block 380, the current character is checked against each font in the list to attempt to identify a mapping. If a mapping is obtained, then the font is returned via terminal 370. If no mapping is obtained, then font not found is returned via terminal 390.

Figures 4, 5 and 6 illustrate examples to further illuminate the processing set forth in Figures 2 and 3.

Lets assume that we have two fonts:

• Font 'G' has glyphs for all characters in the range 0x370...0x3FF and for character 0x020- • Font Ε has glyphs for all characters in the range 0x000... OxOFF. Notice both fonts can map character 0x20.

Given the code string 400, font 410, appearance 420, and string index 430 as shown Figure 4, if the new string 440 is inserted after the character at index 15, without using the process, the new characters will adopt the font style . The resulting string would look like the string shown in Figure 5.

This processing will result in a string displaying missing characters (question

Marks in this example) 500 for everything except for occurrences of the code for spaces — code 0x20. Systems that overlap code pages will usually show random characters from another code page instead of question marks. For example, a Macintosh computer would display characters 16..24 as " ton Qeon" instead of how the characters look (" ton Qeon ") Applying the process to the string will give the following desired result in the string illustrated in Figure 6 at label 600.

The interesting thing to note is that the first 0x20 remained in font 'E', but that the second 0x20 was changed to font 'G'. The process has the desirable feature that once a switch is made to a new font, that all subsequent characters are styled with the new font if it is possible to do so. A slight modification of the above process is illustrated in the flowchart appearing in Figure 7. When a client wants to fix missing glyph characters in text that already has font styles the logic shown in Figure 7 is employed. The major difference with this process is that the process first checks if a character can be displayed in it's own font style before it checks if it can display in the previously processed font style. The effect of this process on characters that can be displayed in their current font is that they are left unchanged. For instance, this process could be used when transferring text between systems which have different font configurations.

Processing commences at terminal 700 and passes immediately to function block 710 to get the text string, text to be input, the insertion point where the input text will be added, and to set lastFontProcessed equal to a nil character. Then, at decision block 720, a loop is commenced to iterate on each of the newly inserted characters until all characters are processed. When all characters have been processed, then the typing style is set equal to the font style of the last character processed at function block 722 and processing is completed at terminal 724.

If characters remain to be processed, then at decision block 730, a test is performed to determine if the current character is in the character's own font style. If so, then lastFontProcessed is set equal to the current characters font at function block 750 and control is returned to decision block 720 to process the next character. If not, then at decision block 734 a test is performed to determine if the current character is in the lastFontProcessed. If so, then newFont is set equal to lastFontProcessed at function block 740, the current character is styled with the new font, lastFontProcessed is set equal to newFont at function block 770, and control is returned to decision block 720 to process the next character.

If the current character is not in the lastFontProcessed, then at function block 736 a font is located that has the current character, and a test is performed at decision block 742 to determine if a font was located. If a font was located, then newFont is set equal to found font, the current character is styled with the new font, lastFontProcessed is set equal to newFont at function block 770, and control is returned to decision block 720 to process the next character. If a font was not found at decision block 742, then the character is styled with a special missing glyph system font as shown in function block 760 and control is returned to decision block 720 for further character processing. Changing The Typing Font While Transliterating

The processing set forth in Figure 2 can run into a problem when two fonts share some characters, and text is being transliterated. The problem is best demonstrated by example.

Suppose you type the Greek word "LogόV " and then the characters "P". The String would now look like: "LogoV P" where P would be styled with the Bookman font and the rest of the string in a Greek font. Also, assume the system had a transliterator that turned 'Pi' into 'P' and both fonts could display the Greek Pi character. If the user then types an T the resulting string would look like: "LogoV π ". Notice that the pi character has the Bookman font style rather than the Greek font style. A more desirable result would display a Pi character in the Greek font (so that it looks like: "LogoV P").

To accomplish this we have to add the following extra logic to a typing style and the transliteration software:

• When the typing style is explicitly changed by the user, the current typing style must retain a copy of the new typing style that is access only by the transliterator software — this copy is referred to as the explicit typing style. When the process described above with reference to Figure 2 changes the typing style, this change does not effect the explicit typing style.

• A transliterator must do the following when it replaces text:

If the character preceding the replaced characters is not styled with the same font as the current typing style then reset the typing style to the explicit typing style.

This processing handles the following cases:

Suppose we have two Greek fonts (G and F) and one Roman font (E). Also, assume we have a transliterator that maps the 'Pi' characters into a 'P' character.

Now suppose we have the strings set forth in Figures 8a, 8b and 8c. Also assume that the user explicitly changed the font in the typing style to font F before typing the 'P' in the second string, as illustrated in Figure 8b. When the user types an 'i' after the 'P' in all three strings, the strings will appear as shown in Figures 8d, 8e and 8f. In all three cases this is the result that a user would have expected.

Applying a Font Style to a Selection

When applying a font style change to a range of characters, clients would like a system to only apply the font style to the characters that the font is able to display. The process in Figure 9 does precisely this. The process commences at function block 910 where a reference is obtained to the font style to be applied, a styled text stream and a range or selection on the text stream onto which the fontStyle is to be set. Then, at decision block 920, a loop is commenced to process the appropriate portion of the text stream from the startlndex to the stoplndex. When the stopindex's character has been processed, then processing is completed as indicated at terminal 930. If additional characters remain, then at decision block 940 a test is performed to determine if the current character being processed is in the fontStyle. If so, then the fontStyle is set on the character and control is passed to decision block 920 to process the next character. If the character being processed is not in the fontStyle, then control is returned to decision block 920 to process the next character.

The processing set forth in Figure 10 is more complex in that it tries to keep all surrounding spaces and punctuation (including quotes, commas, periods...) in the same font as the surrounding letters. In practice, this processing produces a more pleasant result — result that was the desired result of the font designer. Furthermore, this processing prevents font styles from alternating back and forth between every word and space. This switching can cause performance problems on many systems.

Processing commences at function block 1010 where a reference is obtained to the font style to be applied, a styled text stream and a range or selection on the text stream onto which the fontstyle should be set. Also, the current font style is set equal to nil, this Character A Space is set equal to false, and newFontStyle is set equal to fontStyle. Then, at decision block 1020, a test is performed to determine if the fontstyle of the current character is available. If not, then processing is completed at terminal 1024. If so, then a test is performed at decision block 1022 to determine if all stopindex has been reached. If so, then processing is completed at terminal 1024. If not, then currentfontstyle is equated to the fontstyle of the character currently being processed in the text stream as depicted in function block 1030. Then, at decision block 1032, another test is performed to determine if the character currently being processed in the text string is a space or punctuation character. If so, then lastcharacterspace is equated to thischaracterspace in function block 1034.

At decision block 1040, a further test is performed to determine if the current character is a special character. If so, then a loop is commenced at decision block 1050 to if the character is a space or a punctuation character. If so, then the next character is processed at decision block 1050. If not, then nextFontStyle is equated to the character's font style at function block 1056, a test is performed at decision block 1058 to determine if the character is not in fontstyle and if the current font style is a nil character. If so, then a further test is performed at decision block 1080 to ascertain if the current font style is the same as the next font style and if the current character is in font style. If so, then a final test is performed to determine if the font actually exists on the system at decision block 1082. If it exists, then previous font is equated to current font at function block 1060 and the next character is processed at decision block 1022.

If the current character does exist in font style or the current font style is not a nil character, then a test is performed at decision block 1090 to determine if the character is in fontstyle. If so, then the character's fontstyle is set, the current font style is equated with font style, previous font is equated to current font, and the next character is selected at decision block 1022. If the current character is not in the font style, then previous font is equated to current font at function block 1060 and control is passed to decision block 1022 to process the next character.

If the current character is not a space or punctuation character as determined at decision block 1032, then thisCharacterASpace is set to false, and control passes to decision block 1090 for processing as discussed above.

If no special character is detected at decision block 1040, then a further test is performed at decision block 1042 to determine if the first character is being processed. If not, then nextFontStyle is equated to previousStyle at function block 1044 and control is passed to decision block 1080 for processing as discussed above. If the first character is being processed, then nextFontStyle is equated to currentFontStyle and control is passed to decision block 1080 for processing as discussed above. The smart process presented in Figure 10 works by parsing the text and applying the new font styles to characters that the font is able to display. Spaces and punctuation are treated as special characters, and the process peeks ahead to the first non-space or non-punctuation character to check if that character is in the same font as the space or punctuation character. It also checks if the font can display the non-space or non-punctuation character. Using this information the process decides if it wants to apply the font style change to the space or punctuation character.

It is important to notice that the process works on a selection. If a selection contains only spaces and punctuation the process will change the font on the characters regardless of the font of the surrounding characters — assuming the font can display the characters.

Figures 11 to 21 are examples of the processing that transpires on typical multi-script text. The first example, set forth in Figure 11, illustrates a Greek sentence. If all the text is selected and the Courier font style is applied, the processing will produce the result illustrated in Figure 12. The important thing to notice is that the quotes, period, spaces and commas in the Greek portion are kept in the Greek font. This even includes the trailing punctuation at the end of the sentence.

Had we just mapped the characters using the simple processing set forth in Figure 9, the resulting text would appear as set forth in Figure 13.

A second example is set forth regarding the five Greek words illustrated in

Figure 14. Note that all the spaces, commas and period use the Courier font. If all the text is selected and the Chicago font is applied, the processing in accordance with an embodiment of the invention will produce the result set forth in Figure 15. Notice that the spaces, commas, and period changed to Chicago. This is because the processing is sensitive to the fact that the font of these characters was different from that of the surrounding characters. Applying the Greek font to the result from the last example produces the text illustrated in Figure 16. Notice that only the commas, period, and the spaces between the Greek words changed to the Greek font.

Finally, applying Courier to the sentence above produces the words set forth in Figure 17. Notice that the commas, period, and spaces between the Greek words remain in the Greek font. This is because the process is sensitive to the fact that these characters were styled with the same font as the Greek text. The other thing to notice in all these examples is that the colon always stayed in the same font as the Roman text while the other punctuation behaved differently depending upon their font styles.

Now for examples that may be more familiar to computer users. If we apply the font Zapf Dingbats to the above line, the process will not alter the line. It will still display as shown in Figure 18. However applying Zapf Digbats using most commercial, prior art, systems will produce the text set forth in Figure 19. Applying Courier to the above sentence using most products on the market today will produce the text presented in Figure 20. This is not a very useful result. Had this sentence been Hebrew, it would have looked something like the text shown in Figure 21 on the Apple Macintosh computer using prior art techniques. Greek happens to look slightly more readable, but it is still garbage, because on many systems the Greek character codes happen to share the same character codes as the Roman phonetic equivalents.

The preferred embodiment set forth in this invention, at first glance, might not seem impressive. This is precisely because they produce the results that user's desire. What is amazing is that users today put up with systems that are so hard to work with. The system and method presented are all truly unique in that nobody uses anything like them in today's systems. Today's systems put the burden upon the user to get their text looking correct. Users have to put up with the fact that they don't always see what they type in, or when they change fonts their text is changed into characters not intended.

As computer systems become more global, and target non-Roman markets, the importance of the subject invention increases. Most manufactures have only recently started thinking about producing global system. Which implies supporting Roman based languages only. As non-Roman markets become more influential, and as bi-lingual and multi-lingual documents become more common, users will demand more from their computers.

Claims

CLAIMSHaving thus described our invention, what we claim as new, and desire to secure by Letters Patent is:

1. A computer system for processing text, comprising: (a) a storage for storing a plurality of fonts; (b) a display for displaying text and fonts; (c) means for selecting text and selectively applying a first font selected from the plurality of fonts to the text and displaying the resultant text on the display; and (d) means for determining if any of the text is not displayable in the first font.

2. The system as recited in claim 1, including processing means for initiating the text processing operation through an iconic operation.

3. The system as recited in claim 2, including processing means for initiating the text operation by double-clicking on an icon.

4. The system as recited in claim 2, including processing means for drop- launching the text operation.

5. The system as recited in claim 1, including a parser to parse the text.

6. The system as recited in claim 1, including a processor for processing special characters.

7. The system as recited in claim 6, including a user selectable options for special character processing.

8. The system as recited in claim 7, wherein the user selectable options include ignoring application of the new font to special characters.

9. The system as recited in claim 6, including a storage for storing character codes associated with special characters.

10. A method for processing text on a computer, comprising the steps of: (a) storing a plurality of fonts; (b) displaying text and fonts; (c) selecting text and selectively applying a first font selected from the plurality of fonts to the text and displaying the resultant text on the display; and (d) determining if any of the text is not displayable in the first font.

11. The method as recited in claim 10, including the step of initiating the text processing operation through an iconic operation.

12. The method as recited in claim 11, including the step of initiating the text processing operation by double-clicking on an icon.

13. The method as recited in claim 11, including the step of drop-launching the text processing operation.

14. The method as recited in claim 10, including the step of parsing the text.

15. The method as recited in claim 10, including the step of processing special characters.

16. The method as recited in claim 15, including a user selectable options for special character processing.

17. The method as recited in claim 16, including the step of ignoring application of the new font to special characters.

18. The method as recited in claim 15, including the step of storing character codes associated with special characters.