Generic font specification leading to specific font selection5689724Abstract A generic font request is changed to an operating system specific format font request. A font request is received from an application by a font handler. Both the application and the font handler are typically run by an operating system in a computer memory. Once the font handler determines that the font request is a generic font request, i.e. is in a format different than the operating system specific format expected by the operating system, it translates the generic font request to an operating system specific format font request. Claims We claim: Description BACKGROUND OF THE INVENTION
______________________________________
typedef struct.sub.-- FONTDEF
PSZ pszFontNameString;
USHORT usPointSize;
USHORT usFontSize;
ULONG ulFont.sub.-- Mods.sub.-- Emphs
} FONTDEF;
______________________________________
where the PSZ pszFontNameString variable is the exact operating system syntax, the USHORT usPointSize variable is the desired font point size, the USHORT usFontSize variable is the desired font size in pels, the ULONG ulFont.sub.-- Mods.sub.-- Emphs variable is a 32-bit flag using #defines as font and FONTDEF variable contains the modifiers and/or emphasizers of the font change. By using the FONTDEF structure, the application can pass the font change message in the exact operating system syntax if desired, rather using the font interface tool generic font support. If the application developer does not know the exact syntax, then the generic descriptors should be used, and the font interface tool will create the string to use in the syntax the operating system requires. Different versions of the font interface tool code will reside on different versions of the operating system, so that the syntax used by the tool will be that required for the operating system. As shown in the flow diagram, the font interface support will set any combination of the desired point size, physical font size, the font, and any modifiers and emphasizers. If the point size is specified, the physical font size is ignored. Zero fields indicates a value is not being specified for that attribute. If the fontname string is passed in as well as some of the font interface needed information, then the fontname string will be tried first, but if that fails then the font will be selected per the generic processing based on that data. The font interface tool uses the #define statements to equate #defines to specific operating system values. A case or switch statement in the code will equate the fonts to the desired font name string. The LOUSHORT macro just looks at the lower 16 bits of the 32 bit ulFont.sub.-- Mods.sub.-- Emphs structure element. This lower 16 bits are where the font name is specified. By just looking at the lower 16 bits, the bits set to the #defines for the font name can be compared, and find a direct match to know what font is requested. Only the case statement that matches the value in the lower 16 bits is executed in the switch statement--the rest of the case statements are ignored. This is possible because only one font name can be requested.
______________________________________
switch(LOUSHORT(FontDef.ulFont.sub.-- Mods.sub.-- Emphs)
case 0x0001:
pszFontName = "Tms Rmn";
break;
case 0x0002:
pszFontName = "Courier";
break;
case 0x0003:
pszFontName = "Helvetica";
break;
}
______________________________________
For modifiers and emphasizers, since more than one of each can be set for these, each will be checked for sequentially, and the string created for them as we go. The strcat function concatenates the current string on to the string already in the buffer. Notice that the modifiers are preceded by the required space, while the emphasizers are preceded by the required period. The end result of this code will be to have created a string with all of the requested modifiers and emphasizers in the correct order, using the correct syntax and capitalization that will be recognized by the operating system. The "&" operator checks to see if the intersection of both operands is non-zero, i.e. checks to see if the same bit is set on in both sides.
______________________________________
if (HIUSHORT(FontDef.ulFont.sub.-- Mods.sub.-- Emphs) & ITALIC)
strcat(pszModifiers, " Italic");
}
if (HIUSHORT(FontDef.ulFont.sub.-- Mods.sub.-- Emphs) &
ITALIC)
{
strcat(pszModifiers, " Bold");
}
if (HIUSHORT(FontDef.ulFont.sub.-- Mods.sub.-- Emphs) &
OUTLINE)
{
strcat(pszEmphasizers, ".Outline");
}
if (HIUSHORT(FontDef.ulFont.sub.-- Mods.sub.-- Emphs) &
UNDERSCORE)
{
strcat(pszEmphasizers, ".Underline");
}
if (HIUSHORT(FontDef.ulFont.sub.-- Mods.sub.-- Emphs) &
STRIKEOUT)
{
strcat(pszEmphasizers, ".Strikeout");
}
______________________________________
Several examples of #define statements for fonts, modifiers and emphasizers are provided below in the preferred format for the font interface facility. Those skilled in the art would recognize that other formats could be utilized for the #define statements.
______________________________________
FONTS:
#define TIMES.sub.-- ROMAN
0x00000001
#define COURIER 0x00000002
#define HELVETICA 0x00000003
EMPHASIZERS:
#define OUTLINE 0x00010000
#define UNDERSCORE 0x00020000
#define STRIKEOUT 0x00040000
MODIFIERS:
#define ITALIC 0x01000000
#define BOLD 0x02000000
______________________________________
The 0x00000001 syntax denotes the number "1" in hexadecimal notation. Each digit in this notation represents four bits in the binary representation used internally in the computer. 0x00000001, 0x00000002, 0x00000003 are not bit-unique because internally they are represented in binary as: 00000000000000000000000000000001 00000000000000000000000000000010 00000000000000000000000000000011 The first and third numbers each have the first bit set, though they represent different numbers when taken in total. The #defines for emphasizers, for example, are bit-unique. 0x00010000, 0x00020000 and 0x00040000 are represented internally as: 0000000000000001000000000000000 0000000000000010000000000000000 0000000000000100000000000000000 None of the bits overlap between #defines, so are can just check to see if a given bit is set on to see if that emphasizer or modifier is requested. Fonts must be distinct, i.e. only one can be requested, so they are assigned constants that do not need to be bit-unique. Emphasizers and modifiers can be combined, i.e. more than one can be requested, so their constants must be bit-unique. Therefore, fonts can be assigned constants in the lower half of the 32-bit value, emphasizers and modifiers must be assigned constants in the upper half. This is the low 16 bits, or the right half of the ULONG when denoted in hexadecimal notation. The modifiers and emphasizers go in the high half of this structure element, or the left half when denoted in hex. This is transparent to the application, since this intelligence is build into the #define values assigned to each of these things. Zero in the font half of the means no font is specified. No emphasizers and no modifiers are also indicated by zeros in those bytes. The font interface tool will equate these constants to the unique strings and case sensitivity that the operating system requires when setting fonts. The invention can be run in a multi operating system environment, e.g., a network running DOS, Windows, and OS/2 clients at individual workstations. The generic nature of the font description allows it to be used on any platform or operating system that is supported by the font interface tool. Since the generic information is descriptive of the font and characteristics desired rather than being in an operating system specific format, the same generic description can be used in application code written for a variety of specific platforms. The version of the font interface running on that platform will convert the generic description into the proper syntax for that platform once the exact font, size and characteristics that are closest to those desired is found. A more detailed process flow is depicted in FIGS. 4A through 4C. In step 150, the application passes a FONTDEF structure to the set the font. Optionally, the application may also pass an operating system specific font string. Thus, the invention gives the application the ability to try to set the font exactly, but provides a series of fail safes in case there is an error in format or spelling. In step 151, a test is performed to determine whether the exact font and point size were passed in an operating system specific format. If so, in step 153, the font interface tool attempts to set the font exactly as passed by the application by sending the operating system specific message on to the operating system. In step 155, a test is performed to establish whether the font was successfully set, usually by the presence or absence or an error message from the operating system. If the font was successfully set, the process ends, step 156. In step 157, the font interface tool determines whether there is any useful information in the FONTDEF structure passed by the application, i.e. whether there the physical size or font size is specified, or whether there are #define statements for font or any modifiers or emphasizers. If not, in step 159, the system default is used. To attempt to make a more appropriate selection based on the system format string requires knowing why the match did not occur. It could be because of spelling error, capitalization, misplaced periods or spaces, or other typing type errors. To catch these and know what the application intended requires a parser or spell checker. A spell checker or parser can be added as an element of the font interface tool. If the font string is passed in and setting the font fails, then the parser can be invoked to see if the error(s) can be pinpointed and corrected to the most likely meaning as intended by the application. The font name could be matched against valid font names, and if no match is found, the closest match could be used. Any modifiers and emphasizers could be matched to the most likely intended meaning in the same manner as the font name. Any capitalization, ordering or punctuation errors could be corrected in the modified string. If the parsing found corrections that needed to be made, the new string is sent to the operating system to see if it will be successful in setting the font. If the font was not set successfully in step 155, the parser is used in step 158 to find mispellings, capitalization and syntax errors. A test in step 160 determines whether the parser came up with a likely alternative font string to try in the operating system specific format. If an alternative string is identifed, in step 162 the font handler tries to set the font with the operating system. Step 164 tests whether the font was successfully set. If so, the application window is presented and the process ends, step 166. The process continues with step 161 which determines whether a point size is specified. If so, step 163 determines whether the point size is valid. If the point size specified by the application is not valid, the closest valid point size is calculated in step 165. Valid point sizes on OS/2 are even numbers, e.g., 6, 8, 10, 12, 14, 18, 24. Any odd numbers are invalid, and any numbers between 6 and 24 that are not in the listed group are invalid. If a point size is not specified, in step 167, a test determines whether a physical font size is specified. If a physical font size is specified, in step 169, the point size is calculated. If the physical font size is passed in instead of the point size, it must be converted to the appropriate point size for the given resolution of the screen. The screen resolution can be obtained with the DevQueryCaps API. Given that, and knowing there are 72 points per inch, the font interface tool can perform conversions to and from pels, points and inches. To query the fonts on the system that the font interface tool may use, in OS/2, the tool calls the GpiQueryFonts API. Other functions would be called in the appropriate operating system. The GpiQueryFonts API will return font metric information on requested fonts. If a font name is supplied, the GpiQueryFonts API will return info just on fonts of that name. If no font name is supplied, the GpiQueryFonts API will supply info on all fonts in the system. The font interface tool loops through the returned font metrics structures, searching for the best match of the desired font. The modifier and emphasizer information is found in the font metrics information (jointly in fsType and fsSelection). A sample font metric structure which would be returned by the API follows:
______________________________________
typedef struct.sub.-- FONTMETRICS
CHAR szFamilyname›FACESIZE!;
CHAR szFacename›FACESIZE!;
USHORT idRegistry;
USHORT usCodePage;
LONG lEmHeight;
LONG lHeight;
LONG lMaxAscender;
LONG lMaxDescender;
LONG lLowerCaseAscent;
LONG lLowerCaseDescent;
LONG lInternalLeading;
LONG lExternalLeading;
LONG lAveCharWidth;
LONG lMaxCharInc;
LONG lEmInc;
LONG lMaxBaselineExt;
SHORT sCharSlope;
SHORT sInlineDir;
SHORT sCharRot;
USHORT usWeightClass;
USHORT usWidthClass;
SHORT sXDeviceRes;
SHORT sYDeviceRes;
SHORT sFirstChar;
SHORT sLastChar;
SHORT sDefaultChar;
SHORT sBreakChar;
SHORT sNominalPointSize;
SHORT sMinimumPointSize;
SHORT sMaximumPointSize;
USHORT fsType;
USHORT fsDefn;
USHORT fsSelection;
USHORT fsCapabilities;
LONG lSubscriptXSize;
LONG lSubscriptYSize;
LONG lSubscriptXOffset;
LONG lSubscriptYOffset;
LONG lSuperscriptXSize;
LONG lSuperscriptYSize;
LONG lSuperscriptXOffset;
LONG lSuperscriptYOffset;
LONG lUnderscoreSize;
LONG lUnderscorePosition;
LONG lStrikeoutSize;
LONG lStrikeoutPosition;
SHORT sKerningPairs;
SHORT sFamilyClass;
LONG 1Match;
LONG FamilyNameAtom;
LONG FaceNameAtom;
PANOSE panose;
} FONTMETRICS;
______________________________________
In the prior art, if the font is sent in operating system format and a match is not made, the application loses control of the font selection process. It is much better to choose the most appropriate font based on the application input as does the applicants' invention. The application can pass in both an exact string and also the generic information. If the string does not succeed, then any generic information also in the message will be used to select the font. This allows the application to use exact syntax if the application itself has font support built in, but also to set generic data to be used in case the run time environment is a case that the application's font support can not handle. The calculated point size is tested in step 163. If the calculated point size is invalid, the closest valid point size is calculated in step 165. Step 169, which uses the DevQueryCaps API, calculates a point size based on the number of pels requested. The point size based on this pal count might not be valid, since there is no guarantee that the pel size passed in will equate exactly to a valid point size on the current screen resolution. This step just converts the pels to point size, then step 163 checks if it is valid. Since there are two paths from which a point size can originate, the validity is checked in step 163, so that the check is performed only once. If the font size is not specified either in terms of a point size or its physical size, in step 171, the system default point size is used. In step 173, the font interface tool determines whether the font is specified. If the font is not specified, in step 175, the most appropriate font of that point size and any specified modifiers and emphasizers is used. In step 177, a test is performed to determine whether the requested font, with desired point size and all the requested modifiers and emphasizers is present on the system. If the requested font is not available, in step 179, the most appropriate replacement font is chosen by the font interface tool. In OS/2, the GpiQueryFonts call can be used to determine the available fonts. The conversion process in which the #defines are passed is shown in the last step of the flow diagram, step 181. The conversion step follows the rules of the particular operating system, to construct the actual string that is passed to the operating system. By this time, the #defines will have been converted to the actual strings that the operating system requires be used, and the string is ready to be put together out of the individual pieces of point size, font name, modifiers and emphasizers. The process for converting the font from a generic or incorrect format to an operating system specific format is depicted in FIG. 5. The process steps are specific to OS/2; other operating systems would have similar, but slightly different steps depending on their desired format. The process begins in step 200 which starts the string with the point size, followed by a period. In step 201, the font name is concatenated into the string. In OS/2, each word in the font name starts with a capital, the rest of the characters are lower case. Next, in step 203, the modifiers, if any, are concatenated into the string. Each modifier in OS/2 is preceded by a space, the first letter is capitalized and the rest are lower case. In step 205, the emphasizers are concatenated into the string. Each of the emphasizers are preceded by periods, but there are no capitalization rules in OS/2 for emphasizers. Finally, in step 207, the font handler sets the font using this string. The process for choosing the most appropriate font is depicted in FIG. 6 and is invoked by step 175 or step 179 in FIG. 4C. The process begins in step 250 and proceeds to the test in step 251 which determines whether a font was specified by the application. If a font was specified, the process for choosing the most appropriate font was invoked by step 179 because the requested font was unavailable on the system. The process performs an iterative table lookup in step 253 until the test in step 255 determines that the most similar font is available. The table used in step 253 has a series of entries for a hundred or so of the more well known fonts, some of which may not be available on this particular system. The fonts which most closely resemble the specified font follow in order of similarity. If an esoteric font is specified, i.e. one not in the table, after step 254 the process will proceed to step 259. Assuming that the font entry is known, the test in step 255 will determine whether the first replacement font is available on the system. If not available, step 256 will test whether there are more fonts in the table. The process will repeat until a most appropriate font is available and used in step 257, or all the similar fonts have been found to be unavailable on the system. In step 259, if a font has not been specified, or if none of the similar replacement fonts are available on the system, the test determines whether an application default font has been specified. If so, the application default font is used in step 261. If no application default font has been specified, in step 263, the operating system default font is used. In step 265, all of the identified modifiers and emphasizers are added. Finally, in step 267, the font is set in the operating system specific format as described above in connection with FIG. 5. The embodiment above includes a parser to try to find spelling errors, however, in the preferred embodiment, if the application wants the font interface tool to choose the most appropriate font, then it should not pass in the font description in operating system format. One purpose of this invention is to not force the application to know the exact system syntax for font selection, and to be able to get an close approximation of the desired font if a direct match is not made. In OS/2, the WINQUERYPRESPARAM AND WINSETPRESPARAM functions are used to query the application window for font and to set the font for an application window. Other operating systems would have similar functions. These are described below for sake of example. The WINQUERYPRESPARAM function queries the values of presentation parameters for a window.
______________________________________
#define INCL.sub.-- WINSYS
#include <os2.h>
HWND hwnd;
ULONG idAttrType1;
ULONG idAttrType2;
PULONG pidAttrTypeFound;
ULONG cbAttrValueLen;
PVOID pAttrValue;
ULONG flOptions;
ULONG cbRetLen;
______________________________________
The hwnd variable (HWND) is the value input for the window handle. The idAttrType1 (ULONG) variable is the first attribute type identity. This identifies the first presentation parameter attribute to be queried. It can be zero to reference no presentation parameter attribute. The idAttrType2 (ULONG) variable is the second attribute type identity. This identifies the second presentation parameter attribute to be queried. It can be zero to reference no presentation parameter attribute. The pidAttrTypeFound (PULONG) variable is the Attribute type identity found. This identifies which of the presentation parameter attributes idAttrType1 and idAttrType2 has been found. This parameter can be passed as NULL (if, for example, only one attribute is being queried). The cbAttrValueLen (ULONG) variable is the byte count of the size of the storage pointed to the pAttrValue parameter. The pAttrValue (PVOID) variable is the output attribute value. The flOptions (ULONG) variable contains the options controlling the query. Any of these can be ORed together. Two presentation parameter attribute identities can be passed, and both will be searched for along the chain of owners of the window hwnd (subject to QPF.sub.-- NOINHERIT). The first one found satisfies the query. If both idAttrType1 and idAttrType2 are present for the same window, idAttrType1 takes precedence. If the presentation parameter attribute value is too long to fit in the pAttrValue buffer provided, it is truncated, and the number of bytes copied is returned in cbRetLen.
______________________________________
=========================
The WINSETPRESPARAM function sets a presentation parameter for a
window.
#define INCL.sub.-- WINSYS
#include <os2.h>
HWND hwnd;
ULONG idAttrType;
ULONG cbAttrValueLen;
PVOID pAttrValue;
BOOL fSuccess;
fSuccess = WinSetPresParam(hwnd, idAttrType,
cbAttrValueLen, pAttrValue);
______________________________________
The hwnd (HWND) variable is the window handle. The idAttrType (ULONG) variable is the attribute type identity. This is either one of the system-defined presentation parameter attribute types (See the id parameter of the PARAM data type), or an application-defined type. The cbAttrValueLen (ULONG) variable is the byte count of the data passed in the PAttr Value Paramet. The pAttrValue (PVOID) variable is the attribute value to which the presentation parameter should be set. See the abab›1! parameter of the PARAM data type for the values of system-defined attributes. This function associates the presentation parameter attribute identified by idAttrType with the window hwnd. If the attribute already exists for the window, its value is changed to the new value specified by pAttrValue. If the attribute does not exist, it is added to the window's presentation parameters, with the specified value. When a presentation parameter is set, a WM.sub.-- PRESPARAMCHANGED message is sent to all windows owned by the window calling the WinSetPresParam function. While the invention has been described with respect to particular embodiments above, it will be understood by those skilled in the art that modifications may be made without departing from the spirit and scope of the present invention. These embodiments are for purposes of example and illustration only and are not to be taken to limit the scope of the invention narrower than the scope of the appended claims.
|
Same subclass Same class Consider this |
||||||||||