DECwindows Motif
Version 1.2-5 for OpenVMS
Release Notes


Previous Contents Index

To destroy a shared memory XImage, first instruct the server to detach from it, then destroy the segment itself. The following example illustrates how to destroy a shared memory XImage:


XShmDetach (display, shminfo); 
XDestroyImage (image); 
shmdt (shminfo.shmaddr); 
shmctl (shminfo.shmid, IPC_RMID, 0); 

3.19.3.3 Using Shared Memory Pixmaps

Unlike X images, for which any image format is usable, the shared memory extension supports only a single format for the data stored in a shared memory pixmap (XYPixmap or ZPixmap). This format is independent of the depth of the image and independent of the screen. (For 1-bit pixmaps the format is irrelevant.)

The XShmPixmapFormat routine returns the shared memory pixmap format for the server. The XShmPixmapFormat routine has the following format:


int XShmPixmapFormat (display) 
       Display *display; 

Your application can only use shared memory pixmaps in the format returned by the XShmPixmapFormat routine (including bits-per-pixel). To create a shared memory pixmap do the following:

3.19.4 Using Extension Include Files

V1.2

To ensure that programs that contain extension include files compile properly, add the logical name DECW$INCLUDE to the C include directory search list.

To add the logical name for VAX C, enter the following command:


$ DEFINE C$INCLUDE DECW$INCLUDE
To add the logical name for DEC C, enter the following command:


$ DEFINE DECC$USER_INCLUDE DECW$INCLUDE

3.20 Internationalization Enhancements

V1.2--3

Additional internationalization support enables users to view and convert files that contain Asian-language characters.

This section provides the following information about internationalization support for the CDA Viewer application:

3.20.1 Using the CDA Viewer to View Asian-Language Text

V1.2--3

You can use the CDA Viewer in two ways to view text files that contain Asian characters:

Refer to the DECwindows Motif for OpenVMS Applications Guide for information about using the CDA Viewer.

3.20.1.1 Specifying an Options File

V1.2--3

Specify an options file by including a one-line entry in the file in the following format:


TEXT TEXT_ENCODING text_encoding_value

Table 3-11 shows the languages, codesets, and text-encoding values.

Table 3-11 Asian Language Codes for Options Files
Language Codeset Text Encoding Value
Japanese DEC Kanji DEC_KANJI
Japanese Super DEC Kanji SDECKANJI
Traditional Chinese DEC Hanyu DEC_HANYU
Simplified Chinese DEC Hanzi DEC_HANZI
Korean DEC Korean DEC_HANGUL

The following table shows examples of one-line entries.
Options File One-Line Entry
HANYU.CDA$OPTIONS TEXT TEXT_ENCODING DEC_HANYU
HANZI.CDA$OPTIONS TEXT TEXT_ENCODING DEC_HANZI
HANGUL.CDA$OPTIONS TEXT TEXT_ENCODING DEC_HANGUL

To view the EXAMPLES_CUSTOMERS.TXT file that contains Japanese text in DEC Kanji, use your editor to create an options file called KANJI.CDA$OPTIONS. Add the following one-line entry to the file:


TEXT TEXT_ENCODING DEC_KANJI 

When you access the file through the Options File dialog box with the CDA Viewer, the EXAMPLES_CUSTOMERS.TXT file is viewable in the DEC Kanji codeset (Japanese language).

3.20.1.2 Defining Logical Names

V1.2--3

The second option to enable viewing files in Asian languages is to specify the text file and encoding value by defining two logical names:

Table 3-12 shows the logical names and associated encoding values.

Table 3-12 Logical Names for Specifying Text Encoding
DDIF$READ_TEXT_GL DDIF$READ_TEXT_GR Encoding Value
LATIN1 MCS MCS
LATIN1 LATIN1 ISO Latin--1
LATIN1 KATAKANA ASCII--Kana
LATIN1 KANJI DEC Kanji
ROMAN MCS Roman--MCS
ROMAN LATIN1 Roman
ROMAN KANJI Roman--Kanji
ROMAN KATAKANA Roman--Kana
LATIN1 HANZI DEC Hanzi
LATIN1 HANGUL DEC Hangul
LATIN1 HANYU DEC Hanyu

You can define the logical names on the DCL command line or in your LOGIN.COM file. For example:


$ DEFINE DDIF$READ_TEXT_GL LATIN1
$ DEFINE DDIF$READ_TEXT_GR KANJI

Note that this example defines the text encoding for DEC Kanji (see Table 3-12).

3.20.2 Converting Files That Contain Asian-Language Characters

V1.2--3

You can convert an Asian-language text file to another format by specifying an options file or by defining the logical names DDIF$READ_TEXT_GL and DDIF$READ_TEXT_GR as discussed in Section 3.20.1.1 and Section 3.20.1.2.

The format for converting a document from TEXT to another format is as follows:


$ CONVERT/DOCUMENT/OPTION=language.CDA$OPTIONS filename.TXT/FORMAT=TEXT -
_$ filename.output_extension/FORMAT=output_format

For example, to convert a traditional Chinese language text file to a DDIF file, enter the following command line:


$ CONVERT/DOCUMENT/OPTION=HANYU.CDA$OPTIONS -
_$ GUIDELINES_PERSONNEL.TXT/FORMAT=TEXT  GUIDELINES_PERSONNEL.DDIF

Note that this command line does not include the /FORMAT=DDIF qualifier; DDIF is the default.

The output file, GUIDELINES_PERSONNEL.DDIF, contains language data.

You can also create Asian language PostScript files from a DDIF, DTIF, or text (ASCII) file. For example, to convert a DDIF file to PostScript (.PS) format, enter the following command:


$ CONVERT/DOCUMENT filename.DDIF filename.PS/FORMAT=PS

Note

Convert only DDIF and DTIF files that contain language data to Asian language PostScript format.

When you print an Asian language PostScript file on a PostScript printer, ensure that the required language fonts are available on the printer. Otherwise, the PostScript file defaults to a basic set of fonts. If these fonts do not exist, the PostScript file defaults to Courier fonts. Table 3-13 shows the languages and their associated basic fonts.

Table 3-13 Languages and Associated Basic Fonts
Language Basic Fonts
Japanese Ryumin-Light-EUC-H or Ryumin-Light-Hankaku
Hanyu Sung-Light-CNS11643, Sung-Light-DTSCS
Hangul Munjo
Hanzi XiSong-GB2312-80

Note

Vertical writing is not supported by the CDA converters. All vertical text is printed horizontally.

3.21 XNL Library Issues

This section contains information about the XNL library.

3.21.1 xnl_parsedatetime

V1.2--5

xnl_parsedatetime (and its VAX binding, XNL$PARSE_DATE_TIME) accepts two-digit or four-digit years in the input argument XmString s (which is the date-time string to be parsed). Valid years in the two-digit format are in the range 70 to 99, which mean the years from 1970 to 1999. Values from 00 to 69 are invalid. Year 2000 and later must be specified in the four-digit format.

3.21.2 xnl_langinfo

V1.2--5

xnl_langinfo (and its VAX binding, XNL$LANGINFO) returns a string for date-time formatting when D_FMT or D_T_FMT is specified in the item argument. In the locales listed below, this function returns a formatting string containing %y. This formatting string should be used carefully after the year 2000, as %y indicates the two-digit year format.

3.22 Xlib Issues

This section contains information about Xlib.

3.22.1 Command Procedure Builds .PEN Files

V1.0

To allow Pascal programs to inherit environment files for Xlib and Motif, execute the command procedure SYS$LIBRARY:DECW$PEN_BUILD.COM. This command procedure generates the DECW$XLIBDEF.PEN and DECW$MOTIF.PEN files. The .PEN files compile into Pascal programs faster than the provided .PAS files.

3.22.2 Parameter/Protocol Datasize Mismatches

V1.0

Several Xlib routines accept longword parameters that are not sent in their entirety in the X Protocol message to the server. In each case, the Xlib routine sends out only the least significant 16 bits of the parameter value. This is a constraint of the field size within the X Protocol message. Table 3-14 lists routine names and the longword arguments that are sent only as 16-bit values.

Table 3-14 Routine Names and Arguments Sent as 16-Bit Values
Routine Name Routine Arguments
XAllocColorCells/ALLOC_COLOR_CELLS nplanes,npixels
XDrawArc/DRAW_ARC x,y,width,height, angle1,angle2
XDrawLine/DRAW_LINE x1,x2,x3,x4
XDrawPoint/DRAW_POINT x,y
XDrawRectangle/DRAW_RECTANGLE x,y,width,height
XDrawString/DRAW_STRING x,y
XDrawString16/DRAW_STRING16 x,y
XDrawText/DRAW_TEXT x,y
XDrawText16/DRAW_TEXT16 x,y
XFillArc/FILL_ARC x,y,width, height,angle1,angle2
XFillRectangle/FILL_RECTANGLE x,y,width,height

3.22.3 XtAppMainLoop Routine

V1.2--5

Previously, if a program entered its event loop, (for example, by calling XtAppMainLoop) without having opened a display or specified a timer or event flag for the program to wait for (by calling XtAppAddTimeout or XtAppAddInput), Xlib terminated the program with the following error message:


        X Toolkit Error: Error in XMultiplexInput 

Starting with DECwindows Motif Version 1.2-5 for OpenVMS, if there is nothing to wait for, Xlib stalls waiting for input instead of terminating with an error status.

To allow Xlib to process events at a later time, applications should provide some means of regaining control, such as specifying an event flag by calling XtAppAddInput.

3.22.4 XSelectAsyncEvent and XSelectAsyncInput Routines

V1.1

The XSelectAsyncEvent and XSelectAsyncInput routines allocate memory for the storage of AST delivery information. This memory is freed in the following ways:

The AST delivery information for subwindows is not freed by XDestroyWindow.

If you want to turn off AST notification for all event types within a given window and also free the AST delivery information, the client application can call XSelectAsyncEvent or XSelectAsyncInput passing the event_mask argument equal to minus one (all bits set) and the ast_routine argument equal to zero.

3.22.5 Xlib Internationalization

V1.2

The X Window System Version 11, Release 5 (X11 R5) defines a number of services to support writing internationalized X applications. Internationalization of X is based on the concept of a locale. A locale defines the localized behavior of a program at run time. Locales affect Xlib by:

The X Window System defines a general methodology and a set of application programming interfaces (APIs) to standardize programming in X. Standards have not been established for implementing these internationalization features. Currently, the X11 R5 distribution makes two sample implementations of Xlib internationalization support available: Xsi and Ximp. In addition, Compaq provides an implementation called Xi18n. You can select which I18N implementation you want. All three implementations provide the same functionality through the same set of public APIs, but their underlying processing differs. These differences are described in the following sections.

3.22.5.1 Vendor Pluggable Layer

V1.2

Compaq provides a general mechanism called the vendor pluggable layer, which allows you to choose your own internationalization implementations. Different implementations can be built as standalone shareable libraries and can be selected through the logical DECW$XVENDORLAYER.

If this logical is not defined, the mechanism searches for an internationalization implementation library in the following order:

If a shareable library is not found, the default is the Xi18n implementations that are already linked with Xlib.

The following functions act as interfaces between Xlib and the internationalization implementation shareable library:

When creating the Xsi or the Ximp shareable library, you need to know the names of the interfaces because they are defined within Xlib. Compaq recommends that you rename the functions during compilation by adding the following compilation flags:


/define=(- 
    "XDefaultString"="_XDefaultString",- 
    "XwcFreeStringList"="_XwcFreeStringList",- 
    "XwcTextListToTextProperty"="_XwcTextListToTextProperty",- 
    "XmbTextListToTextProperty"="_XmbTextListToTextProperty",- 
    "XwcTextPropertyToTextList"="_XwcTextPropertyToTextList",- 
    "XmbTextPropertyToTextList"="_XmbTextPropertyToTextList",- 
    "_XrmInitParseInfo"="__XrmInitParseInfo",- 
    "_XlcDefaultLoader"="__XlcDefaultLoader") 

3.22.5.2 Compaq Internationalization Xlib Implementation

V1.2

The Compaq implementation (Xi18n) provides enhanced support and a stable internationalization environment. The Compaq implementation (Xi18n) provides the following advantages over the Xsi or Ximp environments provided with the X distribution:

3.22.5.3 Locale in OpenVMS Systems

V1.2--4

DECwindows Motif for OpenVMS software is dependent on a locale environment that conforms to the ANSI C specification. In OpenVMS versions prior to Version 6.2, the DEC C Run-Time Library's implementation of locale support is very limited, so Xlib provides its own internal locale environment. In OpenVMS Version 6.2 and higher, Xlib uses the locale environment provided by the DEC C Run-Time Library.

The locale support provided in DECwindows Motif Version 1.2-4 for OpenVMS has been modified to make it compatible with the locale support in the DEC C Run-Time Library. This corrects a problem that was introduced in DECwindows Motif Version 1.2 for OpenVMS and that is described in the OpenVMS Version 6.2 Release Notes.

If you write internationalized applications using these functions in the locale environment, do the following:


Previous Next Contents Index