friedkiwi/ibm-information-center
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
0332907f0f
ibm-information-center/dist/eclipse/plugins/i5OS.ic.rzakd_5.4.0.1/rzakdmstuniscript.htm

291 lines
18 KiB
HTML
Raw Blame History

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE html
PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html lang="en-us" xml:lang="en-us">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<meta name="security" content="public" />
<meta name="Robots" content="index,follow" />
<meta http-equiv="PICS-Label" content='(PICS-1.1 "http://www.icra.org/ratingsv02.html" l gen true r (cz 1 lz 1 nz 1 oz 1 vz 1) "http://www.rsac.org/ratingsv01.html" l gen true r (n 0 s 0 v 0 l 0) "http://www.classify.org/safesurf/" l gen true r (SS~~000 1))' />
<meta name="DC.Type" content="reference" />
<meta name="DC.Title" content="UNISCRIPT (Unicode Text Layout) keyword in printer files" />
<meta name="abstract" content="Use this field-level keyword to control the selection of text marked for complex script processing." />
<meta name="description" content="Use this field-level keyword to control the selection of text marked for complex script processing." />
<meta name="DC.subject" content="UNISCRIPT (Unicode Text Layout) keyword, Unicode Text Layout (UNISCRIPT) keyword" />
<meta name="keywords" content="UNISCRIPT (Unicode Text Layout) keyword, Unicode Text Layout (UNISCRIPT) keyword" />
<meta name="DC.Relation" scheme="URI" content="rzakdmstprkey.htm" />
<meta name="DC.Relation" scheme="URI" content="../nls/rbagssyssuplocalesourcedef.htm" />
<meta name="DC.Relation" scheme="URI" content="http://www.unicode.org/unicode/reports/tr15/" />
<meta name="DC.Relation" scheme="URI" content="http://www-306.ibm.com/software/globalization/icu/index.jsp" />
<meta name="copyright" content="(C) Copyright IBM Corporation 2001, 2006" />
<meta name="DC.Rights.Owner" content="(C) Copyright IBM Corporation 2001, 2006" />
<meta name="DC.Format" content="XHTML" />
<meta name="DC.Identifier" content="rzakdmstuniscript" />
<meta name="DC.Language" content="en-us" />
<!-- All rights reserved. Licensed Materials Property of IBM -->
<!-- US Government Users Restricted Rights -->
<!-- Use, duplication or disclosure restricted by -->
<!-- GSA ADP Schedule Contract with IBM Corp. -->
<link rel="stylesheet" type="text/css" href="./ibmdita.css" />
<link rel="stylesheet" type="text/css" href="./ic.css" />
<title>UNISCRIPT (Unicode Text Layout) keyword in printer files</title>
</head>
<body id="rzakdmstuniscript"><a name="rzakdmstuniscript"><!-- --></a>
<!-- Java sync-link --><script language="Javascript" src="../rzahg/synch.js" type="text/javascript"></script>
<h1 class="topictitle1">UNISCRIPT (Unicode Text Layout) keyword in printer files</h1>
<div><p>Use this field-level keyword to control the selection of text marked
for complex script processing.</p>
<div class="section"><p>The keyword has two possible formats:</p>
<pre>UNISCRIPT</pre>
<p>All
of the parameters for the UNISCRIPT keyword have defaults. When the keyword
is provided without parameters, the default for each parameter value is used.</p>
<p>You
can also use the keyword with one or more optional parameters. The parameters
can be provided in any order.</p>
<pre>UNISCRIPT([*PRECHK] [*NORMALIZE]
[(*ICULOC 'locale_constant_string' | *NONE | &amp;iculocale_field_name)]
[(*PARDIR *RL | *LR | *PREV | *CALC | &amp;paragraph_dir_field)]
[(*ALTIPOS position_value | &amp;alternate_inline_position_field])</pre>
<p>If
a parameter is not provided, the default for that parameter value is used.</p>
<p>Use the precheck_data parameter, *PRECHK, to request that
the data be tested at print time to determine whether complex layout techniques
are needed. When this optional parameter is specified, the data is first analyzed
to determine whether complex text layout is required to properly present the
string. If complex layout is not required, the Unicode data is not marked
and is processed with traditional text-layout techniques. As such, any subsequent
UNISCRIPT parameters are ignored for this field. If complex layout is required
or this parameter is omitted, the data is marked for complex text layout.
You must have installed i5/OS™ Option 39—International Components for Unicode
(ICU)—to perform this preprocessing.</p>
<p>Use the icu_locale parameter, *ICULOC,
to specify a locale to guide the application of the text layout functions.
Most applications can determine the correct layout for the text using the
Unicode code points alone. However, a small number of TrueType fonts provide
substitute glyphs for specific languages, countries, or regions. For example,
if a single font contains both Chinese and Japanese glyphs, a locale will
be needed to access the correct character variant. The specification of an
ICU locale is not recommended unless the font is known to contain such variants
and the print application is limited to that language or region.</p>
<p>The
parameter is an expression of the form (*ICULOC value). The allowed values
are:</p>
<ul><li>*NONE. No locale name is associated with the field data. This is the default. <p>The
default locale of the presentation system is used to guide the text layout
of the data.</p>
</li>
<li>locale_constant_string is a quoted string from 2 to 96 bytes long <p>The
locale name must adhere to the convention used by the ICU functions used by
the presentation system. In general, an ICU locale consists of one, two, or
three ordered codes separated by an underscore. The first is a two- or three-letter
lowercase language code from the ISO-639 standard. The locale can be further
qualified by a two- or three-letter uppercase region code from the ISO-3166
standard. For each of these codes, the two-character value is used if one
is defined. The third qualifier, the variant code, is an arbitrary string
that is application specific.</p>
<p>Because the quoted string value can contain
lowercase characters, its encoding must be considered in order to be correctly
interpreted. If the user provides a constant string as input, the DDS compiler
verifies that the source member is tagged with a (non-*HEX) CCSID.</p>
</li>
</ul>
<p>The locale name can be provided in a program-to-system field. The
field must be found in the same record format as the UNISCRIPT keyword, and
have a data type of A (character) with a length of from 2 to 96.</p>
<p>When
the Host Print Transform function is used to print the document, the locale
name specified must be one of those provided with ICU provided in i5/OS Option
39. The system-supplied locales and recommended CCSIDs topic has a list of
locales included in <span class="keyword"><font color="Purple">i5/OS</font></span>.
If the specified locale is not found, a substitute locale is found based on
the class hierarchy for defined locales.</p>
<p>Use the paragraph_direction
parameter, *PARDIR, to specify how the overriding paragraph direction is determined.
This value is used as input when the bidirectional algorithm is applied to
the data. It will also be used to determine whether to place the text at the
current or alternate inline position, if an alternate position is specified.
This parameter can be specified as a special value or as a program-to-system
field.</p>
<p>The parameter is an expression of the form (*PARDIR value). The
supported special values and their definitions are listed as follows:</p>
<ul><li>*CALC. The paragraph direction is determined by the complex text run based
on the first strong directional character that is encountered. If no such
characters are found in the string, the default paragraph direction of left-to-right
is used. This is the default value.</li>
<li>*RL. The paragraph direction is set to right-to-left.</li>
<li>*LR. The paragraph direction is set to left-to-right.</li>
<li>*PREV. The paragraph direction is determined by the previous complex text
run. If the field is the first complex text run for the page, the paragraph
direction is determined by the text data based on the first strong directional
character that is encountered. If no such characters are found in the string,
the default paragraph direction of left-to-right is used.</li>
</ul>
<p>If the parameter value is a program-to-system field, the field must
be found in the same record format as the UNISCRIPT keyword and have a data
type of A (character) with a length of 5.</p>
<p>Use the alternate-inline-position
parameter, *ALTIPOS, to specify an alternate position on the current line
to be used in place of the current inline (across) position for text runs
of different paragraph directions. This allows fields with a right-to-left
paragraph direction to be right-aligned and those with a left-to-right paragraph
direction to be left-aligned. The determination of which position is used
as the starting point for a given paragraph direction is based on the relationship
between the current inline direction and the paragraph direction. See the
following examples for a discussion of how this parameter is used.</p>
<p>The
alternate-inline-position value is applied relative to the margins specified
on the FRONTMGN or BACKMGN parameter on the CRTPRTF command. Valid values
are 0 to 57.790 cm (0 to 22.750 in). The UOM parameter on the CRTPRTF command
determines the units of measure for the alternate-inline-position parameter
value. If the value specified is outside the valid range, it is flagged when
the spooled file is created.</p>
<p>The parameter is an expression of the form
(*ALTIPOS value). The value can be provided in a program-to-system field.
The field must be found in the same record format as the UNISCRIPT keyword,
and have a data type of S (numeric) with a length of 5, and 3 decimal positions.
If the alternate-inline-position parameter is not provided, no additional
positioning action is done; this is the default.</p>
<p>Specify DEVTYPE(*AFPDS)
on the CRTPRTF command when UNISCRIPT is specified in the file. If DEVTYPE
is changed to anything other than *AFPDS, the keyword is ignored and a warning
message is issued at print time.</p>
<p>When the UNISCRIPT keyword is used
on a field, the following considerations also apply. The field must have a <tt>G</tt> data
type and it must use the CCSID keyword with a UCS-2 or UTF-16 CCSID and the
*NOCONVERT parameter. Because the keyword offers no benefit unless a TrueType
font is also applied to the data, the FONTNAME keyword (without code page
parameters) is also required.</p>
<p>Option indicators are valid for this keyword.</p>
</div>
<div class="section"><h4 class="sectiontitle">Examples</h4><p>In the following examples, case is used
to indicate different implicit character types for those unfamiliar with right-to-left
letters. Uppercase letters stand for right-to-left characters (such as Arabic
or Hebrew), and lowercase letters stand for left-to-right characters (such
as English or Russian). In storage, Unicode characters are stored in logical
order. For these examples, consider the following text string: <samp class="codeph">"TEXT
text"</samp>.</p>
<p>If *RL or *CALC is specified for the
paragraph direction parameter, this string is rendered in the following way:</p>
<pre>text TXET</pre>
<p>If *LR is specified, it is rendered as:</p>
<pre>TXET text</pre>
<p>When
alternate-inline-position is omitted, the field will be placed at the normal
position and laid out in the current inline direction, regardless of the specified
or calculated paragraph direction. By default, *AFPDS printer files use a
left-to-right (L-to-R) inline direction. A right-to-left (R-to-L) inline direction
can be achieved by specifying a value of 180 degrees for the *ROTATION parameter
of the FONTNAME keyword and for the TXTRTT keyword. Assuming that the current
inline position is P1 and the paragraph direction is R-to-L, then:</p>
<ul><li>If the inline direction is L-to-R, the string is rendered as <pre>(P1)text TXET</pre>
</li>
<li>If the inline direction is R-to-L, the string is rendered as <pre>text TXET(P1)</pre>
</li>
</ul>
<p>The alternate-inline-position parameter allows applications to position
L-to-R and R-to-L text correctly without having to change the inline direction.
It is used in the following way:</p>
<ul><li>If the inline direction is L-to-R (0 degree character rotation), the alternate_inline_position
(P2) is used for a field with a R-to-L paragraph direction. The normal inline
position (P1) is used if the paragraph direction is L-to-R.</li>
<li>If the inline direction is R-to-L (180 degree character rotation), the
alternate inline position (P2) is used for paragraphs with a L-to-R direction.
The normal inline position (P1) is used if the paragraph direction is R-to-L.</li>
</ul>
<p>When an alternate-inline-position (P2) is specified, our example string
is positioned in the following manner:</p>
<ul><li>If the current inline direction is L-to-R and the paragraph direction
is R-to-L, the string is rendered as <pre>(P1) text TXET(P2)</pre>
</li>
<li>If the current inline direction is L-to-R and the paragraph direction
is L-to-R, the string is rendered as <pre>(P1)TXET text (P2)</pre>
</li>
<li>If the current inline direction is R-to-L and the paragraph direction
is L-to-R, the string is rendered as <pre>(P1) (P2)TXET text </pre>
</li>
<li>If the current inline direction is R-to-L and the paragraph direction
is R-to-L, the string is rendered as <pre>text TXET(P1) (P2)</pre>
</li>
</ul>
<p>If alternate positions are used throughout a document to produce a
significantly different report layout for R-to-L scripts, it is very important
that all fields are interpreted with the same paragraph direction. The special
value of *PREV is provided for the *PARDIR parameter for this purpose. A program-to-system
field can also be used to achieve this goal.</p>
<p>Note that Unicode bidirectional
processing is not supported for either of the vertical inline directions represented
by character rotation values of 90 and 270 degrees, and the alternate-inline-position
is ignored.</p>
<p>The following example shows how to specify the UNISCRIPT
keyword.</p>
<div class="note"><span class="notetitle">Note:</span> By using the code examples, you agree to the terms of the <a href="codedisclaimer.htm">Code license and disclaimer information</a>.</div>
<pre>|...+....1....+....2....+....3....+....4....+....5....+....6....+....7....+....8
A*
A R REC1
A F1 10G 3 8UNISCRIPT
A CCSID(13488 *NOCONVERT)
A FONTNAME('Monotype Sans WT' +
A (*POINTSIZE 10.0))
A*
A R REC2 CCSID(1200 *NOCONVERT)
A FONTNAME('Monotype Sans WT' +
A (*POINTSIZE 10.0))
A F2 10G 4 8UNISCRIPT(*NORMALIZE +
A (*ICULOC 'zh_HK') +
A (*PARDIR *RL) +
A (*ALTIPOS 5.77))
A F3 10G 5 8UNISCRIPT(*PRECHK +
A (*ICULOC &amp;ICULOC) +
A (*PARDIR &amp;PARDIR) +
A (*ALTIPOS &amp;ALTPOS))
A ICULOC 20A P
A PARDIR 5A P
A ALTPOS 5S 3P
A </pre>
<div class="note"><span class="notetitle">Note:</span> The UOM
parameter on the CRTPRTF command determines the units of measure for the parameter
value of the alternate-inline-position parameter.</div>
<p>Field F1 in record
REC1 uses the default values of the UNISCRIPT keyword. The text in F1 is not
pre-checked to determine whether complex text layout is required. The data
in the field will not be normalized by the presentation device. The ICU locale
name is provided by the presentation system. The paragraph direction is determined
by the first strong directional character that is found in the text in F1.
The alternate-inline-position parameter is not provided, so no additional
positioning processing is done. The CCSID keyword with a UCS-2 or UTF-16 CCSID
and the *NOCONVERT parameter is required. The FONTNAME keyword is also required.</p>
<p>Record
REC2 uses the CCSID and FONTNAME keywords at the record level. These keywords
are applied to each <tt>G</tt> data type field in the format. The result is
that any <tt>G</tt> field with the UNISCRIPT keyword will also have the required
CCSID and FONTNAME keywords.</p>
<p>Field F2 in REC2 uses the
UNISCRIPT keyword with all the parameter values provided. The text will be
normalized by the presentation device. The ICU locale for <tt>Hong Kong S.A.R.
of PRC</tt> is requested. The paragraph direction is set to right-to-left.
The text is positioned at 5.77 units across from the margins specified on
the FRONTMGN or BACKMGN parameter on the CRTPRTF command.</p>
<p>Field
F3 in REC2 provides some of the values for the UNISCRIPT parameters in program-to-system
fields. Note that *PRECHK and *NORMALIZE do not support a program-to-system
field parameter. Because the *NORMALIZE parameter is omitted in this example,
the text is not normalized by the presentation device (the default). Because
the *PRECHK parameter is specified, the text in the field is prechecked for
complex text.</p>
</div>
</div>
<div>
<div class="familylinks">
<div class="parentlink"><strong>Parent topic:</strong> <a href="rzakdmstprkey.htm" title="See the valid keyword entries for defining printer files in this topic.">Keyword entries for printer files (positions 45 through 80)</a></div>
</div>
<div class="relref"><strong>Related reference</strong><br />
<div><a href="../nls/rbagssyssuplocalesourcedef.htm">System-supplied locales and recommended CCSIDs</a></div>
</div>
<div class="relinfo"><strong>Related information</strong><br />
<div><a href="http://www.unicode.org/unicode/reports/tr15/" target="_blank">Unicode Normalization Forms</a></div>
<div><a href="http://www-306.ibm.com/software/globalization/icu/index.jsp" target="_blank">ICU locales</a></div>
</div>
</div>
</body>
</html>
Reference in New Issue View Git Blame Copy Permalink