Generic Font Specification Leading to Specific Font Selection

This invention relates generally to a graphical user interface to control a computer system. More particularly, it relates to changing a generic font request to operating system specific font change request.

It is well known to provide a graphical user interface to allow a user to control a computer system and to present the results of user actions on the system display. In newer graphical user interfaces, it is possible for an application to select the font by which the information is displayed. However, with most operating systems, the syntax of the font string passed by the application must be exactly correct, or the attempt to set the font will fail. An application developer will naturally want to present itself in the most appropriate font given a particular run time environment. However, the coding effort necessary to port an application for all possible environments is so large that many will settle for using the default system font. This is particularly undesirable when a product is being marketed internationally, since the best font to use will vary from environment to another and may be critical to the product's acceptance.

Other problems are presented by using the system default font in all situations within a GUI. Some panels may need to be presented with different fonts than other panels in an application, to emphasize their relative importance to the user. An example might be a message box that is displayed indicating a particularly important error. The developer might want to use a larger or more bold faced font. Particular controls in a panel may need to use a different font from other controls, again to emphasize relative importance to the user, or to emphasize particular states in which the control may be. Optional fields could use prompt or prefix text that requires a different font, emphasizer or modifier from those of required fields.

This invention solves the problems of prior art graphical user interfaces.

Therefore, it is an object of the invention to translate a generic or incorrect font specification into a platform specific font format.

It is another object of the invention to choose the most appropriate font for a given run time environment based on generic or incorrect font specification.

These and other objects, features and advantages are accomplished by a font interface tool which allows an application to specify fonts in a generic manner. At run time, the generic or incorrect font descriptions are translated by the font interface tool into the exact syntax required for the platform on which the application is running. Thus, the font specific intelligence resides in the font interface tool, rather then requiring each application developer to understand how this is to be provided in their application.

These objects, features and advantages will be more clearly understood with reference to the attached drawings and following description.

FIG. 1 shows a computer comprising system unit, keyboard, mouse and display.

FIG. 2 is a block diagram of the components of the computer shown in FIG. 1.

FIG. 3 is a flow diagram depicting the available process flow of the present invention.

FIGS. 4A-4C show the process of changing a generic fonts specification to an operating systems specific specification.

FIG. 5 depicts the process of converting a generic font specification to an operating system specific font specification.

FIG. 6 depicts the process of choosing the most appropriate replacement font.

The invention may be run on a variety of computers or collection of computers under a number of different operating systems. The computer could be, for example, a personal computer, a mini computer, mainframe computer or a computer running in a distributed network of other computers. Although the specific choice of computer is limited only by disk and disk storage requirements, computers in the IBM PS/2 (TM) series of computers could be used in the present invention. For additional information on IBM's PS/2 series of computers, the reader is referred to Technical Reference Manual Personal Systems/2 Model 50, 60 Systems IBM Corporation, Part No. 68X2224 Order Number S68X-2224 and Technical Reference Manual Personal Systems/2 (Model 80) IBM Corporation Part No. 68X 2256 Order Number S68X-2254. One operating system which an IBM PS/2 personal computer may run is IBM's OS/2 2.0 (TM) for more information on the IBM OS/2 2.0 Operating System the reader is referred to OS/2 2.0 Technical Library, Programming Guide Vol. 1, 2, 3 Version 2.00 Order Nos. 10G6261, 10G6495, 10G6494.

In the alternative, the computer system might be in the IBM RISC System/6000 (TM) line of computers which run on the AIX (TM) operating system. The various models of the RISC System/6000 is described in many publications of the IBM Corporation for example, RISC System/6000, 7073 and 7016 POWERstation and POWERserVer Hardware Technical reference, Order No. SA23-2644-00. The AIX operating system is described in General Concepts and Procedure--AIX Version 3 for RISC System/6000 Order No. SC23-2202-00 as well as other publications of the IBM Corporation.

In FIG. 1, a computer 10, comprising a system unit 11, a keyboard 12, a mouse 13 and a display 14 are depicted. The screen 16 of display device 14 is used to present the visual changes to the data object. The graphical user interface supported by the operating system allows the user to use a point and shoot method of input by moving the pointer to an icon representing a data object at a particular location on the screen 16 and press one of the mouse buttons to perform a user command or selection.

FIG. 2 shows a block diagram of the components of the personal computer shown in FIG. 1. The system unit 11 includes a system bus or plurality of system buses 21 to which various components are coupled and by which communication between the various components is accomplished. The microprocessor 22 is connected to the system bus 21 and is supported by read only memory (ROM) 23 and random access memory (RAM) 24 also connected to system bus 21. A microprocessor in the IBM multimedia PS/2 series of computers is one of the Intel family of microprocessors including the 386 or 486 microprocessors. However, other microprocessors including, but not limited to, Motorola's family of microprocessors such as the 68000, 68020 or the 68030 microprocessors and various Reduced Instruction Set Computer (RISC) microprocessors manufactured by IBM, Hewlett Packard, Sun, Intel, Motorola and others may be used in the specific computer.

The ROM 23 contains among other code the Basic Input-Output system (BIOS) which controls basic hardware operations such as the interaction and the disk drives and the keyboard. The RAM 24 is the main memory into which the operating system and application programs are loaded. The memory management chip 25 is connected to the system bus 21 and controls direct memory access operations including, passing data between the RAM 24 and hard disk drive 26 and floppy disk drive 27. The CD ROM 32 also coupled to the system bus 21 is used to store a large amount of data, e.g., a multimedia program or presentation.

Also connected to this system bus 21 are various I/O controllers: The keyboard controller 28, the mouse controller 29, the video controller 30, and the audio controller 31. As might be expected, the keyboard controller 28 provides the hardware interface for the keyboard 12, the mouse controller 29 provides the hardware interface for mouse 13, the video controller 30 is the hardware interface for the display 14, and the audio controller 31 is the hardware interface for the speakers 15a and 15b. Also coupled to the system bus 21 is digital signal processor 33 which corrects the sound produced by the speaker system and is preferably incorporated into the audio controller 31. The speakers 15a and 15b may be used to present audio objects to the user. An I/O controller 40 such as a Token Ring Adapter enables communication over a network 46 to other similarly configured data processing systems.

One of the preferred implementations of the present invention is as a set of instructions in a code module resident in the random access memory. Until required by the computer system, a set of instructions may be stored on a computer readable medium, for example, the hard disk in hard disk drive 26, optical disk in the CD ROM 32 or a floppy disk in the floppy disk drive 27. As shown in the figure, the operating system 50 and presentation manager 52 are resident in RAM 24. Some operating systems such as OS/2 have an embedded presentation manager. Other systems use a presentation manager which is a stand alone piece of code. In this example, the invention is embodied in a font interface tool 54 which is coupled to the operating system or presentation manager. An application 56 uses the font interface tool to have the operating system present its GUI in the most appropriate and available font on the system.

Font specification or change messages can be sent by the application 56 at any time to change the font of any panel that the application owns. Typical font specification or change times include when the application is first launched. During application initialization, the `global` font to be used for the Graphical User Interface for the application can be set. The font specified at this time will serve as the default application font for all of the application's panels.

A font specification will also occur on panel creation. If the application has special needs to change the font of a specific panel, a change message is issued after the panel is created and before it is displayed to the user. Examples of this would be when a panel needs to be shrunk due to a large number of controls on the panel or grown for touch screens or vision impaired users.

Another time when a font may be specified is on application translation. Most applications are developed to support multiple languages to enable marketing to a world-wide customer base. Depending on the language, the font may need to be changed. Situations that may require this are countries that have different `default` fonts than the US, translated languages that result in text strings that are longer and require a smaller font to fit on a panel, as well as fonts that may need to be enlarged so that glyphs, hyphens, and accents can be seen.

The font interface tool is a layer of abstraction that is placed on top of the native Operating System (OS) and below an application. It provides a layer of APIs, services, and messages that ease the development of Graphic User Interfaces. The application issues messages to the font interface tool and API calls and the tool then maps these calls into the necessary native operating system calls and messages. As a result, the application only needs to talk in a syntax which the font interface tool understands and the tool is responsible for talking the native OS language. This allows applications to run unchanged on multiple operating systems with the exception of possibly requiring a recompile.

The basic interactions between the operating system, the application and the font interface tool are depicted on the flow chart shown in FIG. 3. First, in step 101, the application requests a font from the font interface tool using FONTDEF structure which defines the generic font format. Second, in step 103, if the exact string is passed in, the font interface tool sets the font with the operating system. "Setting a font" with the operating system means to call the WinSetPresParam API, passing the font string and the window handle. The operating system should change the font for that window to the font indicated in the passed font string. The return code from this API indicates whether the font was successfully changed. Third, if the application has not sent a font string in the FONTDEF structure or the font string fails, the font interface tool creates the string to use, step 105. In step 107, the interface tool queries any needed font information from the operating system which the operating system returns. Several examples of font information which might need to be queried include what fonts are on the system, what characteristics (modifiers/emphasizers) each of these fonts support, and what point sizes each of these fonts support. In OS/2, this information can all be obtained or calculated from the information in the FONTMETRICS structures returned from the GpiQueryFonts call. Then, in step 109, the font interface tool sets the font using the string constructed from the generic data and sends it to the operating system. Then, in step 111, the operating system presents the application window according to the font set.

Normally, the application resident in the system must use the correct font format to have its information presented on the display as desired by the application and user. Examples of correct and incorrect font string formats in the OS/2 operating system follow. A message to OS/2 in the correct format for helvetica in both bold and italic in 10 pitch where the phrase is both outlined and underscored would read:

"10.Helvetica Bold Italic.Outline.Underscore"

The font string is in the format:

"point.sub.-- size.font.sub.-- name modifier modifier.emphasizer.emphasizer "

There is a period between point size and font name, a space before each modifier, and a period before each emphasizer. The modifiers are case sensitive, but not emphasizers. Modifiers such as bold and italic and emphasizers such as outline and underscore are optional. The distinction between modifiers and emphasizers is an OS/2-dictated distinction. In essence, modifiers change the style of the font, e.g., shape or boldness of the font, while emphasizers simply add unique characteristics to a font of given shape or boldness. OS/2 has the following Capitalization rules: Font names and modifiers capitalize first letter in each word. Emphasizers' capitalization is ignored.

With no emphasizers or modifiers, ten pitch helvetica would be presented with the message:

"10.Helvetica"

Any other font string format would be treated as an error. For example, if the application developer did not know the correct format or was confused as to whether a given variable was a modifier or emphasizer in OS/2, it would be relatively easy to place periods before the modifiers bold and italic above. The message passed to OS/2 would read:

"10.Helvetica.Bold.Italic.Outline.Underscore"

which would be treated as an error. As different operating environments will have similar but slightly varying font format requirements, one easily see that a programmer who ports his application from environment to environment could easily encounter problems.

If the format is incorrect, the request to change the presentation parameter may fail, or the correct parts may be taken and the incorrect parts ignored, depending on the operating environment and the exact nature of the format error. For example, in the OS/2 environment, if there is no period between point size and font name or there is a capitalization mistake or spelling error on the font or the modifier, there is complete failure of the message. Similarly, if there is no period before an emphasizer the font change fails. If there is a spelling error on an emphasizer, the emphasizer is ignored, other emphasizers will succeed. If there is a period before a first emphasizer, but missing before a subsequent emphasizer, all the emphasizers are ignored, even the one with the correct preceding period, but the rest of the change succeeds, i.e. new font and modifiers. Other operating environments have similar but slightly varying reactions to incorrectly formatted font change requests.

An incorrect font string is one that is not in the font interface tool understood format nor is understood by the operating system. A generic font string is one that the font interface tool is expecting and from which it can determine exactly what point size, font, emphasizers and/or modifiers are being requested.

In preferred embodiment, the font will be specified in a FONTDEF structure, composed as follows:

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.

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.

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.

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:

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:

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:

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.

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 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.