| Previous | Contents | Index |
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 4.8.1.1.1 and Section 4.8.1.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 |
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 4-7 shows the languages and their 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 |
Vertical writing is not supported by the CDA converters. All vertical text is printed horizontally. |
This section contains information about the XNL library.
4.9.1 Changes and Enhancements
The following notes describe changes and enhancements made to the XNL
library.
4.9.1.1 xnl_parsedatetime
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.
4.9.1.2 xnl_langinfo
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.
This section contains information about Xlib.
4.10.1 Changes and Enhancements
The following notes describe changes and enhancements made to the Xlib.
4.10.1.1 X11 Environment Variable Parsing
Xlib now accepts the equivalent X11 Release 5 (X11 R5) forms of the following environment variables:
| OpenVMS Form | X11 R5 Form |
|---|---|
| DECW$DISPLAY | DISPLAY |
| DECW$RESOURCE_NAME | RESOURCE_NAME |
On startup, if the OpenVMS variable is not defined, Xlib then checks
for the X11 R5 equivalent before returning a status value.
4.10.1.2 UIDPATH Environment Variable
When opening a hierarchy, Xlib searches the DECW$USER_DEFAULTS and DECW$SYSTEM_DEFAULTS areas for the User Interface Definition (UID) file. On UNIX systems and according to X11 R5 specifications, the search path is defined using the UIDPATH variable and its fallbacks.
Now, Xlib also checks for the UIDPATH variable if the UID file is not found using either of the OpenVMS variables state above. This variable references a UNIX-style pathname (for example, /foo/bar) and allows the substitutions strings as specified by X11 standards. For more information on the UIDPATH variable, see the OSF/Motif Programmer's Reference.
The UIDPATH variable does not work with OpenVMS directory specifications. Use the DECW$xxx_DEFAULTS logicals to specify OpenVMS-style search paths. |
In XtResolvePathname, the default pathname is required to have certain properties when either no other path information is present in the call, or when it is referenced by the environment variable XFILESEARCHPATH. The former default OpenVMS format of the pathname consisted of a type-name-suffix substitution. The modified pathname now reflects the 6-part fallback, as specified by X11 Release 5.
The new pathname behavior is enabled by setting the DECW$VSW_COMPLIANT variable, as follows:
$ DEFINE DECW$VSW_COMPLIANT 1 |
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.
4.10.1.5 Locale Support in OpenVMS Systems
The locale support provided in DECwindows Motif Version 1.2--4 for OpenVMS is compatible with the locale support in the DEC C Run-Time Library. If you write internationalized applications using these functions in the locale environment, do the following:
/define=(X_LOCALE,X_WCHAR,_WCHAR_T_,XLIB_XPG4_FUNCS) |
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.
4.10.1.6.1 Vendor Pluggable Layer
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")
|
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:
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.
4.10.1.8 Command Procedure Builds .PEN Files
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.
4.10.2 Corrections
The following notes describe the resolution of any problems specific to
Xlib that previously resulted in an error or required a workaround.
4.10.2.1 UNIX Filename Emulation (Alpha Only)
V1.2--6
Previously, UNIX-style filenames with embedded path syntax "../" within functions such as XtResolvePathname and MrmOpenHierarchy were not handled correctly. While this syntax is highly unusual, it can occur when both the filename and the pathname contain a relative path specification.
This problem has been corrected; UNIX-style filenames with this
embedded syntax are parsed as expected.
4.10.2.2 XmTextField Widget Switches Focus Correctly
V1.2--6
A crash no longer occurs when the losingFocus callback peforms an
XtSetValues() on an XmTextField routine.
4.10.2.3 XrmoptionStickyArg Produces Correct Results
V1.2--6
Problems with the XrmoptionStickyArg routine have been corrected; this
routine no longer returns incorrect results when referenced from the
command line.
4.10.2.4 PAllHints Macro Corrected
The value of the PAllHints macro in XUTILS.H has been corrected.
4.10.3 Problems and Restrictions
The following notes describe problems and restrictions that currently
pertain to Xlib.
4.10.3.1 XtOpenDisplay Routine and Case Sensitivity
In some cases the application name in XtOpenDisplay comes from argv[0], which represents the name of the application on the command line.
Be aware that case sensitivity must be preserved in such environments
as when referencing ODS-5 system with case preservation enabled or when
passing a user-defined argv list.
4.10.3.2 Parameter/Protocol Datasize Mismatches
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 4-8 lists routine names and the longword arguments that are sent only 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 |
This chapter describes corrections to the DECwindows Motif
documentation.
5.1 Getting Started With the New Desktop
This section contains documentation corrections to the Getting Started With the New Desktop
manual.
5.1.1 File Specification Incorrect
V1.2--5
A file specification for a command procedure in Getting Started With the New Desktop (part number AA-QUW1A-TE) is incorrect. The file specification appears in Section 3.4.9, paragraph 5, as follows:
"Optional DECwindows applications, such as DECwindows Notes, may not provide any information and therefore are not restarted. For such cases, there is a command procedure called disk$:[user.DT]SESSIONETC.COM that you can use to start any applications that cannot be restarted automatically. This procedure is analogous to the DECW$LOGIN.COM procedure in the traditional DECwindows environment."
The correct file specification is:
disk$:[user.DT.SESSIONS]SESSIONETC.COM
5.2 DECwindows Motif for OpenVMS Applications Guide
This section contains documentation corrections to the DECwindows Motif for OpenVMS Applications Guide
manual.
5.2.1 Enhancing Information About the Finish Printing Option
V1.2--3
The section called "Printing Information" in the chapter on DECterm provides information about the Print menu. To further clarify the information in the Finish Printing section, note the following:
Selecting the Finish Printing option on the Print menu closes the print job and toggles Auto Print mode back to Normal Print mode.
5.3 Using DECwindows Motif for OpenVMS
This section contains documentation corrections and enhancements to the
Using DECwindows Motif for OpenVMS manual.
5.3.1 Using the Drag-and-Drop Feature
The drag-and-drop feature lets you move or copy screen objects. For example, you can move text from buttons and paste it elsewhere.
To drag and drop text into a new location:
Drag-and-drop is provided primarily for programmers to incorporate the feature into their applications.
The DECwindows Motif Version 1.2 for OpenVMS applications support the drag-and-drop feature, with
the exception of Notepad. DECwindows Mail supports drag-and-drop in all
windows except the main message area, where DECwindows Mail has its own
drag-and-drop feature; you can use MB2 to move messages around with the
SVN interface.
5.3.2 Using Tear-Off Menus
The DECwindows Mail application supports tear-off menus.
The DECwindows Motif applications allow you to tear off pull-down and popup menus. Tear-off menus let you keep frequently used menus displayed without repeatedly pulling them down or popping them up.
To tear off a menu:
To close a tear-off menu:
The following applications do not support tear-off menus:
V1.2
The example "Adding Target Screen Options to Application Menu Items" in Using DECwindows Motif for OpenVMS is incorrect. To correct the problem, remove the first occurrence of the following line:
$ select_qualifiers:
5.3.4 Changing the Startup Environment
V1.2
The example "Changing Your Logo" is incorrect. To correct the problem, change the following code example in step one:
$ COPY SYS$COMMON:[SYSMGR]DECW$PRIVATE_APPS_SETUP.TEMPLATE - _$ SYS$SPECIFIC:[SYSMANAGER]DECW$PRIVATE_APPS_SETUP.COM/LOG |
The code example should read as follows:
$ COPY SYS$COMMON:[SYSMGR]DECW$PRIVATE_APPS_SETUP.TEMPLATE - _$ SYS$SPECIFIC:[SYSMGR]DECW$PRIVATE_APPS_SETUP.COM/LOG |
V1.1
Extensive SYLOGIN.COM or LOGIN.COM command procedures slow down application startup. Many of the operations performed in a SYLOGIN.COM or LOGIN.COM are meaningless for DECwindows application startup. Therefore, the SYLOGIN.COM and LOGIN.COM files should be conditionalized for DECwindows application startup performance. When starting a DECwindows application, a minimum of SYLOGIN.COM and LOGIN.COM commands should be executed.
Typically, the commands that should be executed are the redefinition of DECW$USER_DEFAULTS (if present), and other logical name definitions if the user will be referencing them from within the context of a DECwindows application. The following code segment can be inserted into SYLOGIN.COM and LOGIN.COM immediately following the commands necessary for DECwindows:
$ mode = f$mode()
$ tt_devname = f$trnlnm("TT")
$ session_mgr_login = (mode .eqs. "INTERACTIVE") .and. -
(f$locate("WSA",tt_devname) .ne. f$len(tt_devname))
$ session_detached_process = (mode .eqs. "INTERACTIVE") .and. -
(f$locate("MBA",tt_devname) .ne. f$len(tt_devname))
$ if session_mgr_login .or. session_detached_process then exit
|
Applications continue to run even if these lines are not added to the SYLOGIN.COM and LOGIN.COM files.
| Previous | Next | Contents | Index |