fdo-mirrors/xorg-libx11
1
0
Fork 0
mirror of https://gitlab.freedesktop.org/xorg/lib/libx11.git synced 2026-05-07 21:28:04 +02:00
Code Issues Projects Releases Packages Wiki Activity Actions

specs/libX11: Mark a number of <acronym>s

Browse source 
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
This commit is contained in:
Alan Coopersmith 2010-07-08 20:42:50 -07:00
parent d5bbb12f55
commit d66d2134df
14 changed files with 339 additions and 339 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

4
specs/libX11/AppC.xml
View file

@ -1427,7 +1427,7 @@ structure and so can be cast to a type larger than an
to obtain additional values set by using
<function>XESetWireToError .</function>
The underlying type of the fp argument is system dependent;
on a POSIX-compliant system, fp should be cast to type FILE*.
on a <acronym>POSIX</acronym>-compliant system, fp should be cast to type FILE*.
<indexterm significance="preferred"><primary>XESetFlushGC</primary></indexterm>
<!-- .sM -->
<funcsynopsis>
@ -3226,7 +3226,7 @@ Portability Considerations
<para>
<!-- .LP -->
Many machine architectures,
including many of the more recent RISC architectures,
including many of the more recent <acronym>RISC</acronym> architectures,
do not correctly access data at unaligned locations;
their compilers pad out structures to preserve this characteristic.
Many other machines capable of unaligned references pad inside of structures

2
specs/libX11/AppD.xml
View file

@ -1145,7 +1145,7 @@ uses resources from the RESOURCE_MANAGER property on the root
window of screen zero.
If no such property exists,
a resource file in the user's home directory is used.
On a POSIX-conformant system,
On a <acronym>POSIX</acronym>-conformant system,
this file is
<function>"$HOME/.Xdefaults" .</function>
<indexterm><primary>Files</primary><secondary>$HOME/.Xdefaults</secondary></indexterm>

4
specs/libX11/CH01.xml
View file

@ -735,13 +735,13 @@ Latin-1, plus tab and newline.
</listitem>
<listitem>
<para>
POSIX Portable Filename Character Set
<acronym>POSIX</acronym> Portable Filename Character Set
</para>
</listitem>
<listitem>
<para>
The set of 65 characters,
which can be used in naming files on a POSIX-compliant host,
which can be used in naming files on a <acronym>POSIX</acronym>-compliant host,
that are correctly processed in all locales.
The set is:
</para>

24
specs/libX11/CH02.xml
View file

@ -83,7 +83,7 @@ XAllPlanes
<para>
Specifies the hardware display name, which determines the display
and communications domain to be used.
On a POSIX-conformant system, if the display_name is NULL,
On a <acronym>POSIX</acronym>-conformant system, if the display_name is NULL,
it defaults to the value of the DISPLAY environment variable.
<indexterm><primary>Environment</primary><secondary>DISPLAY</secondary></indexterm>
</para>
@ -97,7 +97,7 @@ The encoding and interpretation of the display name are
implementation-dependent.
Strings in the Host Portable Character Encoding are supported;
support for other characters is implementation-dependent.
On POSIX-conformant systems,
On <acronym>POSIX</acronym>-conformant systems,
the display name or DISPLAY environment variable can be a string in the format:
</para>
<!-- .LP -->
@ -141,7 +141,7 @@ You follow the hostname with either a single colon (:) or a double colon (::).
<para>
Specifies the number of the display server on that host machine.
You may optionally follow this display number with a period (.).
A single CPU can have more than one display.
A single <acronym>CPU</acronym> can have more than one display.
Multiple displays are usually numbered starting with zero.
<indexterm><primary>Screen</primary></indexterm>
</para>
@ -187,18 +187,18 @@ structure that serves as the
connection to the X server and that contains all the information
about that X server.
<function>XOpenDisplay</function>
connects your application to the X server through TCP
connects your application to the X server through <acronym>TCP</acronym>
or DECnet communications protocols,
or through some local inter-process communication protocol.
<indexterm><primary>Protocol</primary><secondary>TCP</secondary></indexterm>
<indexterm><primary>Protocol</primary><secondary><acronym>TCP</acronym></secondary></indexterm>
<indexterm><primary>Protocol</primary><secondary>DECnet</secondary></indexterm>
If the protocol is specified as "tcp", "inet", or "inet6", or
if no protocol is specified and the hostname is a host machine name and a single colon (:)
separates the hostname and display number,
<function>XOpenDisplay</function>
connects using TCP streams. (If the protocol is specified as "inet", TCP over
IPv4 is used. If the protocol is specified as "inet6", TCP over IPv6 is used.
Otherwise, the implementation determines which IP version is used.)
connects using <acronym>TCP</acronym> streams. (If the protocol is specified as "inet", <acronym>TCP</acronym> over
IPv4 is used. If the protocol is specified as "inet6", <acronym>TCP</acronym> over IPv6 is used.
Otherwise, the implementation determines which <acronym>IP</acronym> version is used.)
If the hostname and protocol are both not specified,
Xlib uses whatever it believes is the fastest transport.
If the hostname is a host machine name and a double colon (::)
@ -347,7 +347,7 @@ and
can be used in implementing a monochrome application.
These pixel values are for permanently allocated entries in the default
colormap.
The actual RGB (red, green, and blue) values are settable on some screens
The actual <acronym>RGB</acronym> (red, green, and blue) values are settable on some screens
and, in any case, may not actually be black or white.
The names are intended to convey the expected relative intensity of the colors.
<!-- .sM -->
@ -471,7 +471,7 @@ Specifies the connection to the X server.
<indexterm significance="preferred"><primary>ConnectionNumber</primary></indexterm>
<indexterm significance="preferred"><primary>XConnectionNumber</primary></indexterm>
Both return a connection number for the specified display.
On a POSIX-conformant system,
On a <acronym>POSIX</acronym>-conformant system,
this is the file descriptor of the connection.
</para>
<para>
@ -1014,10 +1014,10 @@ Specifies the connection to the X server.
Both return the string that was passed to
<function>XOpenDisplay</function>
when the current display was opened.
On POSIX-conformant systems,
On <acronym>POSIX</acronym>-conformant systems,
if the passed string was NULL, these return the value of
the DISPLAY environment variable when the current display was opened.
<indexterm><primary>POSIX System Call</primary><secondary>fork</secondary></indexterm>
<indexterm><primary><acronym>POSIX</acronym> System Call</primary><secondary>fork</secondary></indexterm>
These are useful to applications that invoke the
<function>fork</function>
system call and want to open a new connection to the same display from the

20
specs/libX11/CH03.xml
View file

@ -56,7 +56,7 @@ visual types clearer.
The screen can be color or grayscale,
can have a colormap that is writable or read-only,
and can also have a colormap whose indices are decomposed into separate
RGB pieces, provided one is not on a grayscale screen.
<acronym>RGB</acronym> pieces, provided one is not on a grayscale screen.
This leads to the following diagram:
</para>
@ -80,7 +80,7 @@ it goes through a look-up stage by indexing into a colormap.
Colormaps can be manipulated arbitrarily on some hardware,
in limited ways on other hardware, and not at all on other hardware.
The visual types affect the colormap and
the RGB values in the following ways:
the <acronym>RGB</acronym> values in the following ways:
</para>
<para>
<!-- .LP -->
@ -91,7 +91,7 @@ the RGB values in the following ways:
For
<function>PseudoColor , </function>
a pixel value indexes a colormap to produce
independent RGB values, and the RGB values can be changed dynamically.
independent <acronym>RGB</acronym> values, and the <acronym>RGB</acronym> values can be changed dynamically.
</para>
</listitem>
<listitem>
@ -108,9 +108,9 @@ same value for red, green, and blue in the colormaps.
<para>
For
<function>DirectColor ,</function>
a pixel value is decomposed into separate RGB subfields, and each
a pixel value is decomposed into separate <acronym>RGB</acronym> subfields, and each
subfield separately indexes the colormap for the corresponding value.
The RGB values can be changed dynamically.
The <acronym>RGB</acronym> values can be changed dynamically.
</para>
</listitem>
<listitem>
@ -118,8 +118,8 @@ The RGB values can be changed dynamically.
<function>TrueColor</function>
is treated the same way as
<function>DirectColor </function>
except that the colormap has predefined, read-only RGB values.
These RGB values are server dependent but provide linear or near-linear
except that the colormap has predefined, read-only <acronym>RGB</acronym> values.
These <acronym>RGB</acronym> values are server dependent but provide linear or near-linear
ramps in each primary.
</para>
</listitem>
@ -129,7 +129,7 @@ ramps in each primary.
is treated the same way as
<function>PseudoColor </function>
except that the colormap has predefined,
read-only, server-dependent RGB values.
read-only, server-dependent <acronym>RGB</acronym> values.
</para>
</listitem>
<listitem>
@ -137,7 +137,7 @@ read-only, server-dependent RGB values.
<function>StaticGray </function>
is treated the same way as
<function>StaticColor </function>
except that the RGB values are equal for any single pixel
except that the <acronym>RGB</acronym> values are equal for any single pixel
value, thus resulting in shades of gray.
<function>StaticGray </function>
with a two-entry
@ -155,7 +155,7 @@ Each has one contiguous set of bits with no
intersections.
The bits_per_rgb member specifies the log base 2 of the
number of distinct color values (individually) of red, green, and blue.
Actual RGB values are unsigned 16-bit numbers.
Actual <acronym>RGB</acronym> values are unsigned 16-bit numbers.
The colormap_size member defines the number of available colormap entries
in a newly created colormap.
For

16
specs/libX11/CH05.xml
View file

@ -361,7 +361,7 @@ Specifies the glyph character for the mask.
</term>
<listitem>
<para>
Specifies the RGB values for the foreground of the source.
Specifies the <acronym>RGB</acronym> values for the foreground of the source.
</para>
</listitem>
</varlistentry>
@ -371,7 +371,7 @@ Specifies the RGB values for the foreground of the source.
</term>
<listitem>
<para>
Specifies the RGB values for the background of the source.
Specifies the <acronym>RGB</acronym> values for the background of the source.
</para>
</listitem>
</varlistentry>
@ -482,7 +482,7 @@ Specifies the cursor's source bits to be displayed or
</term>
<listitem>
<para>
Specifies the RGB values for the foreground of the source.
Specifies the <acronym>RGB</acronym> values for the foreground of the source.
</para>
</listitem>
</varlistentry>
@ -492,7 +492,7 @@ Specifies the RGB values for the foreground of the source.
</term>
<listitem>
<para>
Specifies the RGB values for the background of the source.
Specifies the <acronym>RGB</acronym> values for the background of the source.
<!-- .ds Xy , which indicate the hotspot relative to the source's origin -->
</para>
</listitem>
@ -526,7 +526,7 @@ Specify the x and y coordinates(Xy.
The
<function>XCreatePixmapCursor</function>
function creates a cursor and returns the cursor ID associated with it.
The foreground and background RGB values must be specified using
The foreground and background <acronym>RGB</acronym> values must be specified using
foreground_color and background_color,
even if the X server only has a
<function>StaticGray</function>
@ -719,7 +719,7 @@ Specifies the cursor.
</term>
<listitem>
<para>
Specifies the RGB values for the foreground of the source.
Specifies the <acronym>RGB</acronym> values for the foreground of the source.
</para>
</listitem>
</varlistentry>
@ -729,7 +729,7 @@ Specifies the RGB values for the foreground of the source.
</term>
<listitem>
<para>
Specifies the RGB values for the background of the source.
Specifies the <acronym>RGB</acronym> values for the background of the source.
</para>
</listitem>
</varlistentry>
@ -745,7 +745,7 @@ if the cursor is being displayed on a screen,
the change is visible immediately.
The pixel members of the
<function>XColor</function>
structures are ignored; only the RGB values are used.
structures are ignored; only the <acronym>RGB</acronym> values are used.
</para>
<para>
<!-- .LP -->

268
specs/libX11/CH06.xml
View file

@ -16,15 +16,15 @@ Each X window always has an associated colormap that
provides a level of indirection between pixel values and colors displayed
on the screen.
Xlib provides functions that you can use to manipulate a colormap.
The X protocol defines colors using values in the RGB color space.
The RGB color space is device dependent;
rendering an RGB value on differing output devices typically results
The X protocol defines colors using values in the <acronym>RGB</acronym> color space.
The <acronym>RGB</acronym> color space is device dependent;
rendering an <acronym>RGB</acronym> value on differing output devices typically results
in different colors.
Xlib also provides a means for clients to specify color using
device-independent color spaces for consistent results across devices.
Xlib supports device-independent color spaces derivable from the CIE XYZ
Xlib supports device-independent color spaces derivable from the <acronym>CIE</acronym> XYZ
color space.
This includes the CIE XYZ, xyY, L*u*v*, and L*a*b* color spaces as well as
This includes the <acronym>CIE</acronym> XYZ, xyY, L*u*v*, and L*a*b* color spaces as well as
the TekHVC color space.
</para>
<para>
@ -90,12 +90,12 @@ there is a color cell in the colormap.
For example,
if a window is 4 bits deep, pixel values 0 through 15 are defined.
A colormap is a collection of color cells.
A color cell consists of a triple of red, green, and blue (RGB) values.
A color cell consists of a triple of red, green, and blue (<acronym>RGB</acronym>) values.
The hardware imposes limits on the number of significant
bits in these values.
As each pixel is read out of display memory, the pixel
is looked up in a colormap.
The RGB value of the cell determines what color is displayed on the screen.
The <acronym>RGB</acronym> value of the cell determines what color is displayed on the screen.
On a grayscale display with a black-and-white monitor,
the values are combined to determine the brightness on the screen.
</para>
@ -106,11 +106,11 @@ to obtain the desired colors.
The client can allocate read-only cells.
In which case,
the pixel values for these colors can be shared among multiple applications,
and the RGB value of the cell cannot be changed.
and the <acronym>RGB</acronym> value of the cell cannot be changed.
If the client allocates read/write cells,
they are exclusively owned by the client,
and the color associated with the pixel value can be changed at will.
Cells must be allocated (and, if read/write, initialized with an RGB value)
Cells must be allocated (and, if read/write, initialized with an <acronym>RGB</acronym> value)
by a client to obtain desired colors.
The use of pixel value for an
unallocated cell results in an undefined color.
@ -172,7 +172,7 @@ or
<!-- .XE -->
<para>
<!-- .LP -->
Functions that operate only on RGB color space values use an
Functions that operate only on <acronym>RGB</acronym> color space values use an
<function>XColor</function>
structure, which contains:
</para>
@ -430,7 +430,7 @@ The device-dependent formats provided allow color specification in:
<itemizedlist>
<listitem>
<para>
RGB Intensity
<acronym>RGB</acronym> Intensity
<function>( XcmsRGBi )</function>
</para>
</listitem>
@ -443,7 +443,7 @@ where 1.0 indicates full intensity, 0.5 half intensity, and so on.
</listitem>
<listitem>
<para>
RGB Device
<acronym>RGB</acronym> Device
<function>( XcmsRGB )</function>
</para>
</listitem>
@ -461,14 +461,14 @@ structure.
</itemizedlist>
<para>
<!-- .LP -->
It is important to note that RGB Intensity values are not gamma corrected
It is important to note that <acronym>RGB</acronym> Intensity values are not gamma corrected
values.
In contrast,
RGB Device values generated as a result of converting color specifications
<acronym>RGB</acronym> Device values generated as a result of converting color specifications
are always gamma corrected, and
RGB Device values acquired as a result of querying a colormap
<acronym>RGB</acronym> Device values acquired as a result of querying a colormap
or passed in by the client are assumed by Xlib to be gamma corrected.
The term <emphasis remap='I'>RGB value</emphasis> in this manual always refers to an RGB Device value.
The term <emphasis remap='I'><acronym>RGB</acronym> value</emphasis> in this manual always refers to an <acronym>RGB</acronym> Device value.
</para>
</sect1>
<sect1 id="Color_Strings">
@ -561,13 +561,13 @@ The syntax and semantics of numerical specifications are given
for each standard color space in the following sections.
</para>
<sect2 id="RGB_Device_String_Specification">
<title>RGB Device String Specification</title>
<title><acronym>RGB</acronym> Device String Specification</title>
<!-- .XS -->
<!-- (SN RGB Device String Specification -->
<!-- (SN <acronym>RGB</acronym> Device String Specification -->
<!-- .XE -->
<para>
<!-- .LP -->
An RGB Device specification is identified by
An <acronym>RGB</acronym> Device specification is identified by
the prefix ``rgb:'' and conforms to the following syntax:
</para>
<para>
@ -597,7 +597,7 @@ are also allowed.
</para>
<para>
<!-- .LP -->
For backward compatibility, an older syntax for RGB Device is
For backward compatibility, an older syntax for <acronym>RGB</acronym> Device is
supported, but its continued use is not encouraged.
The syntax is an initial sharp sign character followed by
a numeric specification, in one of the following formats:
@ -625,13 +625,13 @@ For example, the string ``#3a7'' is the same as ``#3000a0007000''.
</para>
</sect2>
<sect2 id="RGB_Intensity_String_Specification">
<title>RGB Intensity String Specification</title>
<title><acronym>RGB</acronym> Intensity String Specification</title>
<!-- .XS -->
<!-- (SN RGB Intensity String Specification -->
<!-- .XE -->
<para>
<!-- .LP -->
An RGB intensity specification is identified
An <acronym>RGB</acronym> intensity specification is identified
by the prefix ``rgbi:'' and conforms to the following syntax:
</para>
<para>
@ -1104,7 +1104,7 @@ error.
<para>
<!-- .LP -->
<!-- .sp -->
To map a color name to an RGB value, use
To map a color name to an <acronym>RGB</acronym> value, use
<function>XLookupColor .</function>
<indexterm><primary>Color</primary><secondary>naming</secondary></indexterm>
<indexterm significance="preferred"><primary>XLookupColor</primary></indexterm>
@ -1158,7 +1158,7 @@ definition structure you want returned.
</term>
<listitem>
<para>
Returns the exact RGB values.
Returns the exact <acronym>RGB</acronym> values.
</para>
</listitem>
</varlistentry>
@ -1168,7 +1168,7 @@ Returns the exact RGB values.
</term>
<listitem>
<para>
Returns the closest RGB values provided by the hardware.
Returns the closest <acronym>RGB</acronym> values provided by the hardware.
</para>
</listitem>
</varlistentry>
@ -1201,7 +1201,7 @@ error.
<para>
<!-- .LP -->
<!-- .sp -->
To map a color name to the exact RGB value, use
To map a color name to the exact <acronym>RGB</acronym> value, use
<function>XParseColor .</function>
</para>
<indexterm><primary>Color</primary><secondary>naming</secondary></indexterm>
@ -1425,7 +1425,7 @@ explicitly as read-only entries, one pixel value at a time,
or read/write,
where you can allocate a number of color cells and planes simultaneously.
<indexterm><primary>Read-only colormap cells</primary></indexterm>
A read-only cell has its RGB value set by the server.
A read-only cell has its <acronym>RGB</acronym> value set by the server.
<indexterm><primary>Read/write colormap cells</primary></indexterm>
Read/write cells do not have defined colors initially;
functions described in the next section must be used to store values into them.
@ -1445,7 +1445,7 @@ times, the server counts each such allocation, not just the first one.
<para>
<!-- .LP -->
<!-- .sp -->
To allocate a read-only color cell with an RGB value, use
To allocate a read-only color cell with an <acronym>RGB</acronym> value, use
<function>XAllocColor .</function>
</para>
<indexterm><primary>Allocation</primary><secondary>read-only colormap cells</secondary></indexterm>
@ -1501,11 +1501,11 @@ Specifies and returns the values actually used in the colormap.
The
<function>XAllocColor</function>
function allocates a read-only colormap entry corresponding to the closest
RGB value supported by the hardware.
<acronym>RGB</acronym> value supported by the hardware.
<function>XAllocColor</function>
returns the pixel value of the color closest to the specified
RGB elements supported by the hardware
and returns the RGB value actually used.
<acronym>RGB</acronym> elements supported by the hardware
and returns the <acronym>RGB</acronym> value actually used.
The corresponding colormap cell is read-only.
In addition,
<function>XAllocColor</function>
@ -1514,7 +1514,7 @@ returns nonzero if it succeeded or zero if it failed.
<indexterm><primary>Color</primary><secondary>allocation</secondary></indexterm>
<indexterm><primary>Allocation</primary><secondary>colormap</secondary></indexterm>
<indexterm><primary>read-only colormap cells</primary></indexterm>
Multiple clients that request the same effective RGB value can be assigned
Multiple clients that request the same effective <acronym>RGB</acronym> value can be assigned
the same read-only entry, thus allowing entries to be shared.
When the last client deallocates a shared cell, it is deallocated.
<function>XAllocColor</function>
@ -1611,12 +1611,12 @@ function ultimately calls
to allocate a read-only color cell (colormap entry) with the specified color.
<function>XcmsAllocColor</function>
first converts the color specified
to an RGB value and then passes this to
to an <acronym>RGB</acronym> value and then passes this to
<function>XAllocColor .</function>
<function>XcmsAllocColor</function>
returns the pixel value of the color cell and the color specification
actually allocated.
This returned color specification is the result of converting the RGB value
This returned color specification is the result of converting the <acronym>RGB</acronym> value
returned by
<function>XAllocColor </function>
into the format specified with the result_format argument.
@ -1639,7 +1639,7 @@ error.
<!-- .LP -->
<!-- .sp -->
To allocate a read-only color cell using a color name and return the closest
color supported by the hardware in RGB format, use
color supported by the hardware in <acronym>RGB</acronym> format, use
<function>XAllocNamedColor .</function>
</para>
<indexterm><primary>Allocation</primary><secondary>read-only colormap cells</secondary></indexterm>
@ -1696,7 +1696,7 @@ definition structure you want returned.
</term>
<listitem>
<para>
Returns the closest RGB values provided by the hardware.
Returns the closest <acronym>RGB</acronym> values provided by the hardware.
</para>
</listitem>
</varlistentry>
@ -1706,7 +1706,7 @@ Returns the closest RGB values provided by the hardware.
</term>
<listitem>
<para>
Returns the exact RGB values.
Returns the exact <acronym>RGB</acronym> values.
</para>
</listitem>
</varlistentry>
@ -1860,7 +1860,7 @@ The color string is parsed into an
structure (see
<function>XcmsLookupColor ),</function>
converted
to an RGB value, and finally passed to
to an <acronym>RGB</acronym> value, and finally passed to
<function>XAllocColor .</function>
If the color name is not in the Host Portable Character Encoding,
the result is implementation-dependent.
@ -1871,7 +1871,7 @@ Use of uppercase or lowercase does not matter.
This function returns both the color specification as a result
of parsing (exact specification) and the actual color specification
stored (screen specification).
This screen specification is the result of converting the RGB value
This screen specification is the result of converting the <acronym>RGB</acronym> value
returned by
<function>XAllocColor</function>
into the format specified in result_format.
@ -2031,7 +2031,7 @@ or
and three contiguous sets of bits set to 1 (one within each
pixel subfield) for
<function>DirectColor .</function>
The RGB values of the allocated
The <acronym>RGB</acronym> values of the allocated
entries are undefined.
<function>XAllocColorCells</function>
returns nonzero if it succeeded or zero if it failed.
@ -2393,7 +2393,7 @@ errors.
<para>
<!-- .LP -->
<!-- .sp -->
To store an RGB value in a single colormap cell, use
To store an <acronym>RGB</acronym> value in a single colormap cell, use
<function>XStoreColor .</function>
</para>
<indexterm><primary>Color</primary><secondary>storing</secondary></indexterm>
@ -2435,7 +2435,7 @@ Specifies the colormap.
</term>
<listitem>
<para>
Specifies the pixel and RGB values.
Specifies the pixel and <acronym>RGB</acronym> values.
</para>
</listitem>
</varlistentry>
@ -2485,7 +2485,7 @@ errors.
<para>
<!-- .LP -->
<!-- .sp -->
To store multiple RGB values in multiple colormap cells, use
To store multiple <acronym>RGB</acronym> values in multiple colormap cells, use
<function>XStoreColors .</function>
</para>
<indexterm><primary>Color</primary><secondary>storing</secondary></indexterm>
@ -2649,8 +2649,8 @@ The
<function>XcmsStoreColor</function>
function converts the color specified in the
<function>XcmsColor</function>
structure into RGB values.
It then uses this RGB specification in an
structure into <acronym>RGB</acronym> values.
It then uses this <acronym>RGB</acronym> specification in an
<function>XColor</function>
structure, whose three flags
<function>( DoRed , </function>
@ -2680,7 +2680,7 @@ Note that
has no return value; therefore, an
<function>XcmsSuccess</function>
return value from this function indicates that the conversion
to RGB succeeded and the call to
to <acronym>RGB</acronym> succeeded and the call to
<function>XStoreColor</function>
was made.
To obtain the actual color stored, use
@ -2792,7 +2792,7 @@ The
<function>XcmsStoreColors</function>
function converts the colors specified in the array of
<function>XcmsColor</function>
structures into RGB values and then uses these RGB specifications in
structures into <acronym>RGB</acronym> values and then uses these <acronym>RGB</acronym> specifications in
<function>XColor</function>
structures, whose three flags
<function>( DoRed , </function>
@ -2824,7 +2824,7 @@ Note that
has no return value; therefore, an
<function>XcmsSuccess</function>
return value from this function indicates that conversions
to RGB succeeded and the call to
to <acronym>RGB</acronym> succeeded and the call to
<function>XStoreColors</function>
was made.
To obtain the actual colors stored, use
@ -2962,7 +2962,7 @@ and
<function>XQueryColors</function>
functions take pixel values in the pixel member of
<function>XColor</function>
structures and store in the structures the RGB values for those
structures and store in the structures the <acronym>RGB</acronym> values for those
pixels from the specified colormap.
The values returned for an unallocated entry are undefined.
These functions also set the flags member in the
@ -2977,7 +2977,7 @@ the one that gets reported is arbitrary.
<para>
<!-- .LP -->
<!-- .sp -->
To query the RGB value of a single colormap cell, use
To query the <acronym>RGB</acronym> value of a single colormap cell, use
<function>XQueryColor .</function>
</para>
<indexterm><primary>Color</primary><secondary>querying</secondary></indexterm>
@ -3019,7 +3019,7 @@ Specifies the colormap.
</term>
<listitem>
<para>
Specifies and returns the RGB values for the pixel specified in the structure.
Specifies and returns the <acronym>RGB</acronym> values for the pixel specified in the structure.
</para>
</listitem>
</varlistentry>
@ -3030,7 +3030,7 @@ Specifies and returns the RGB values for the pixel specified in the structure.
<!-- .eM -->
The
<function>XQueryColor</function>
function returns the current RGB value for the pixel in the
function returns the current <acronym>RGB</acronym> value for the pixel in the
<function>XColor</function>
structure and sets the
<function>DoRed ,</function>
@ -3051,7 +3051,7 @@ errors.
<para>
<!-- .LP -->
<!-- .sp -->
To query the RGB values of multiple colormap cells, use
To query the <acronym>RGB</acronym> values of multiple colormap cells, use
<function>XQueryColors .</function>
</para>
<indexterm><primary>Color</primary><secondary>querying</secondary></indexterm>
@ -3119,7 +3119,7 @@ structures in the color definition array.
<!-- .eM -->
The
<function>XQueryColors</function>
function returns the RGB value for each pixel in each
function returns the <acronym>RGB</acronym> value for each pixel in each
<function>XColor</function>
structure and sets the
<function>DoRed ,</function>
@ -3208,7 +3208,7 @@ Specifies the color format for the returned color specification.
<!-- .eM -->
The
<function>XcmsQueryColor</function>
function obtains the RGB value
function obtains the <acronym>RGB</acronym> value
for the pixel value in the pixel member of the specified
<function>XcmsColor</function>
structure and then
@ -3310,7 +3310,7 @@ Specifies the color format for the returned color specification.
<!-- .eM -->
The
<function>XcmsQueryColors</function>
function obtains the RGB values
function obtains the <acronym>RGB</acronym> values
for pixel values in the pixel members of
<function>XcmsColor</function>
structures and then
@ -4270,13 +4270,13 @@ the contents of the color specification array are left unchanged.
<para>
<!-- .LP -->
The array may contain a mixture of color specification formats
(for example, 3 CIE XYZ, 2 CIE Luv, and so on).
(for example, 3 <acronym>CIE</acronym> XYZ, 2 <acronym>CIE</acronym> Luv, and so on).
When the array contains both device-independent and
device-dependent color specifications and the target_format argument specifies
a device-dependent format (for example,
<function>XcmsRGBiFormat ,</function>
<function>XcmsRGBFormat ),</function>
all specifications are converted to CIE XYZ format and then to the target
all specifications are converted to <acronym>CIE</acronym> XYZ format and then to the target
device-dependent format.
</para>
</sect1>
@ -4501,12 +4501,12 @@ The gamut compression callback procedures provided by Xlib are as follows:
<listitem>
<para>
This brings the encountered out-of-gamut color specification into the
screen's color gamut by reducing or increasing CIE metric lightness (L*)
in the CIE L*a*b* color space until the color is within the gamut.
screen's color gamut by reducing or increasing <acronym>CIE</acronym> metric lightness (L*)
in the <acronym>CIE</acronym> L*a*b* color space until the color is within the gamut.
If the Psychometric Chroma of the color specification
is beyond maximum for the Psychometric Hue Angle,
then while maintaining the same Psychometric Hue Angle,
the color will be clipped to the CIE L*a*b* coordinates of maximum
the color will be clipped to the <acronym>CIE</acronym> L*a*b* coordinates of maximum
Psychometric Chroma.
See
<function>XcmsCIELabQueryMaxC .</function>
@ -4535,7 +4535,7 @@ No client data is necessary.
<listitem>
<para>
This brings the encountered out-of-gamut color specification into the
screen's color gamut by replacing it with CIE L*a*b* coordinates
screen's color gamut by replacing it with <acronym>CIE</acronym> L*a*b* coordinates
that fall within the color gamut while maintaining the original
Psychometric Hue
Angle and whose vector to the original coordinates is the shortest attainable.
@ -4550,12 +4550,12 @@ No client data is necessary.
<listitem>
<para>
This brings the encountered out-of-gamut color specification into the
screen's color gamut by reducing or increasing CIE metric lightness (L*)
in the CIE L*u*v* color space until the color is within the gamut.
screen's color gamut by reducing or increasing <acronym>CIE</acronym> metric lightness (L*)
in the <acronym>CIE</acronym> L*u*v* color space until the color is within the gamut.
If the Psychometric Chroma of the color specification
is beyond maximum for the Psychometric Hue Angle,
then, while maintaining the same Psychometric Hue Angle,
the color will be clipped to the CIE L*u*v* coordinates of maximum
the color will be clipped to the <acronym>CIE</acronym> L*u*v* coordinates of maximum
Psychometric Chroma.
See
<function>XcmsCIELuvQueryMaxC .</function>
@ -4584,7 +4584,7 @@ No client data is necessary.
<listitem>
<para>
This brings the encountered out-of-gamut color specification into the
screen's color gamut by replacing it with CIE L*u*v* coordinates
screen's color gamut by replacing it with <acronym>CIE</acronym> L*u*v* coordinates
that fall within the color gamut while maintaining the original
Psychometric Hue
Angle and whose vector to the original coordinates is the shortest attainable.
@ -4764,7 +4764,7 @@ White point adjustment procedures provided by Xlib are as follows:
</listitem>
<listitem>
<para>
This uses the CIE L*a*b* color space for adjusting the chromatic character
This uses the <acronym>CIE</acronym> L*a*b* color space for adjusting the chromatic character
of colors to compensate for the chromatic differences between the source
and destination white points.
This procedure simply converts the color specifications to
@ -4781,7 +4781,7 @@ No client data is necessary.
</listitem>
<listitem>
<para>
This uses the CIE L*u*v* color space for adjusting the chromatic character
This uses the <acronym>CIE</acronym> L*u*v* color space for adjusting the chromatic character
of colors to compensate for the chromatic differences between the source
and destination white points.
This procedure simply converts the color specifications to
@ -4816,7 +4816,7 @@ No client data is necessary.
From an implementation point of view,
these white point adjustment procedures convert the color specifications
to a device-independent but white-point-dependent color space
(for example, CIE L*u*v*, CIE L*a*b*, TekHVC) using one white point
(for example, <acronym>CIE</acronym> L*u*v*, <acronym>CIE</acronym> L*a*b*, TekHVC) using one white point
and then converting those specifications to the target color space
using another white point.
In other words,
@ -4824,8 +4824,8 @@ the specification goes in the color space with one white point
but comes out with another white point,
resulting in a chromatic shift based on the chromatic displacement
between the initial white point and target white point.
The CIE color spaces that are assumed to be white-point-independent
are CIE u'v'Y, CIE XYZ, and CIE xyY.
The <acronym>CIE</acronym> color spaces that are assumed to be white-point-independent
are <acronym>CIE</acronym> u'v'Y, <acronym>CIE</acronym> XYZ, and <acronym>CIE</acronym> xyY.
When developing a custom white point adjustment procedure that uses a
device-independent color space not initially accessible for use in the
color management system, use
@ -4893,7 +4893,7 @@ From
<function>XcmsCIEuvY</function>
to
<function>XcmsCIEXYZ</function>
(CIE u'v'Y and XYZ are white-point-independent color spaces)
(<acronym>CIE</acronym> u'v'Y and XYZ are white-point-independent color spaces)
</para>
</listitem>
<listitem>
@ -4915,9 +4915,9 @@ to
</itemizedlist>
<para>
<!-- .LP -->
The resulting RGB specification is passed to
The resulting <acronym>RGB</acronym> specification is passed to
<function>XAllocColor ,</function>
and the RGB
and the <acronym>RGB</acronym>
specification returned by
<function>XAllocColor</function>
is converted back to
@ -4935,7 +4935,7 @@ by reversing the color conversion sequence.
<!-- .LP -->
This section describes the gamut querying functions that Xlib provides.
These functions allow the client to query the boundary
of the screen's color gamut in terms of the CIE L*a*b*, CIE L*u*v*,
of the screen's color gamut in terms of the <acronym>CIE</acronym> L*a*b*, <acronym>CIE</acronym> L*u*v*,
and TekHVC color spaces.
<indexterm><primary>Gamut querying</primary></indexterm>
Functions are also provided that allow you to query
@ -5348,7 +5348,7 @@ delim %%
<para>
<!-- .LP -->
<indexterm><primary>Psychometric Hue Angle</primary></indexterm>
<indexterm><primary>CIE metric lightness</primary></indexterm>
<indexterm><primary><acronym>CIE</acronym> metric lightness</primary></indexterm>
<indexterm><primary>Psychometric Chroma</primary></indexterm>
<indexterm><primary>Psychometric Chroma</primary><secondary>maximum</secondary></indexterm>
<literallayout class="monospaced">
@ -5357,8 +5357,8 @@ delim %%
%CIELab~Psychometric~Hue ~=~ tan sup -1 left [ b_star over a_star right ]%
</literallayout>
<!-- .sp -->
To obtain the CIE L*a*b* coordinates of maximum Psychometric Chroma
for a given Psychometric Hue Angle and CIE metric lightness (L*), use
To obtain the <acronym>CIE</acronym> L*a*b* coordinates of maximum Psychometric Chroma
for a given Psychometric Hue Angle and <acronym>CIE</acronym> metric lightness (L*), use
<function>XcmsCIELabQueryMaxC .</function>
</para>
<indexterm significance="preferred"><primary>XcmsCIELabQueryMaxC</primary></indexterm>
@ -5416,7 +5416,7 @@ Specifies the lightness (L*) at which to find (Ls.
</term>
<listitem>
<para>
Returns the CIE L*a*b* coordinates of (Lc
Returns the <acronym>CIE</acronym> L*a*b* coordinates of (Lc
displayable by the screen for the given (lC.
The white point associated with the returned
color specification is the Screen White Point.
@ -5433,18 +5433,18 @@ The
<function>XcmsCIELabQueryMaxC</function>
function, given a hue angle and lightness,
finds the point of maximum chroma displayable by the screen.
It returns this point in CIE L*a*b* coordinates.
It returns this point in <acronym>CIE</acronym> L*a*b* coordinates.
</para>
<para>
<!-- .LP -->
<!-- .sp -->
To obtain the CIE L*a*b* coordinates of maximum CIE metric lightness (L*)
To obtain the <acronym>CIE</acronym> L*a*b* coordinates of maximum <acronym>CIE</acronym> metric lightness (L*)
for a given Psychometric Hue Angle and Psychometric Chroma, use
<function>XcmsCIELabQueryMaxL .</function>
</para>
<indexterm><primary>Psychometric Hue Angle</primary></indexterm>
<indexterm><primary>CIE metric lightness</primary></indexterm>
<indexterm><primary>CIE metric lightness</primary><secondary>maximum</secondary></indexterm>
<indexterm><primary><acronym>CIE</acronym> metric lightness</primary></indexterm>
<indexterm><primary><acronym>CIE</acronym> metric lightness</primary><secondary>maximum</secondary></indexterm>
<indexterm significance="preferred"><primary>XcmsCIELabQueryMaxL</primary></indexterm>
<!-- .sM -->
<funcsynopsis>
@ -5500,7 +5500,7 @@ Specifies the chroma at which to find (Ch.
</term>
<listitem>
<para>
Returns the CIE L*a*b* coordinates of (Lc
Returns the <acronym>CIE</acronym> L*a*b* coordinates of (Lc
displayable by the screen for the given (lC.
The white point associated with the returned
color specification is the Screen White Point.
@ -5516,9 +5516,9 @@ The value returned in the pixel member is undefined.
The
<function>XcmsCIELabQueryMaxL</function>
function, given a hue angle and chroma,
finds the point in CIE L*a*b* color space of maximum
finds the point in <acronym>CIE</acronym> L*a*b* color space of maximum
lightness (L*) displayable by the screen.
It returns this point in CIE L*a*b* coordinates.
It returns this point in <acronym>CIE</acronym> L*a*b* coordinates.
An
<function>XcmsFailure</function>
return value usually indicates that the given chroma
@ -5527,15 +5527,15 @@ is beyond maximum for the given hue angle.
</para>
<para>
<!-- .LP -->
To obtain the CIE L*a*b* coordinates of maximum Psychometric Chroma
To obtain the <acronym>CIE</acronym> L*a*b* coordinates of maximum Psychometric Chroma
for a given Psychometric Hue Angle, use
<function>XcmsCIELabQueryMaxLC .</function>
</para>
<indexterm><primary>Psychometric Hue Angle</primary></indexterm>
<indexterm><primary>Psychometric Chroma</primary></indexterm>
<indexterm><primary>CIE metric lightness</primary></indexterm>
<indexterm><primary><acronym>CIE</acronym> metric lightness</primary></indexterm>
<indexterm><primary>Psychometric Chroma</primary><secondary>maximum</secondary></indexterm>
<indexterm><primary>CIE metric lightness</primary><secondary>maximum</secondary></indexterm>
<indexterm><primary><acronym>CIE</acronym> metric lightness</primary><secondary>maximum</secondary></indexterm>
<indexterm significance="preferred"><primary>XcmsCIELabQueryMaxLC</primary></indexterm>
<!-- .sM -->
<funcsynopsis>
@ -5579,7 +5579,7 @@ Specifies the hue angle (in degrees) at which to find (Ha.
</term>
<listitem>
<para>
Returns the CIE L*a*b* coordinates of (Lc
Returns the <acronym>CIE</acronym> L*a*b* coordinates of (Lc
displayable by the screen for the given (lC.
The white point associated with the returned
color specification is the Screen White Point.
@ -5596,18 +5596,18 @@ The
<function>XcmsCIELabQueryMaxLC</function>
function, given a hue angle,
finds the point of maximum chroma displayable by the screen.
It returns this point in CIE L*a*b* coordinates.
It returns this point in <acronym>CIE</acronym> L*a*b* coordinates.
<!-- .sp -->
</para>
<para>
<!-- .LP -->
To obtain the CIE L*a*b* coordinates of minimum CIE metric lightness (L*)
To obtain the <acronym>CIE</acronym> L*a*b* coordinates of minimum <acronym>CIE</acronym> metric lightness (L*)
for a given Psychometric Hue Angle and Psychometric Chroma, use
<function>XcmsCIELabQueryMinL .</function>
</para>
<indexterm><primary>Psychometric Hue Angle</primary></indexterm>
<indexterm><primary>CIE metric lightness</primary></indexterm>
<indexterm><primary>CIE metric lightness</primary><secondary>minimum</secondary></indexterm>
<indexterm><primary><acronym>CIE</acronym> metric lightness</primary></indexterm>
<indexterm><primary><acronym>CIE</acronym> metric lightness</primary><secondary>minimum</secondary></indexterm>
<indexterm significance="preferred"><primary>XcmsCIELabQueryMinL</primary></indexterm>
<!-- .sM -->
<funcsynopsis>
@ -5663,7 +5663,7 @@ Specifies the chroma at which to find (Ch.
</term>
<listitem>
<para>
Returns the CIE L*a*b* coordinates of (Lc
Returns the <acronym>CIE</acronym> L*a*b* coordinates of (Lc
displayable by the screen for the given (lC.
The white point associated with the returned
color specification is the Screen White Point.
@ -5680,7 +5680,7 @@ The
<function>XcmsCIELabQueryMinL</function>
function, given a hue angle and chroma,
finds the point of minimum lightness (L*) displayable by the screen.
It returns this point in CIE L*a*b* coordinates.
It returns this point in <acronym>CIE</acronym> L*a*b* coordinates.
An
<function>XcmsFailure</function>
return value usually indicates that the given chroma
@ -5702,7 +5702,7 @@ delim %%
<para>
<!-- .LP -->
<indexterm><primary>Psychometric Hue Angle</primary></indexterm>
<indexterm><primary>CIE metric lightness</primary></indexterm>
<indexterm><primary><acronym>CIE</acronym> metric lightness</primary></indexterm>
<indexterm><primary>Psychometric Chroma</primary></indexterm>
<indexterm><primary>Psychometric Chroma</primary><secondary>maximum</secondary></indexterm>
<literallayout class="monospaced">
@ -5714,8 +5714,8 @@ delim %%
</para>
<para>
<!-- .LP -->
To obtain the CIE L*u*v* coordinates of maximum Psychometric Chroma
for a given Psychometric Hue Angle and CIE metric lightness (L*), use
To obtain the <acronym>CIE</acronym> L*u*v* coordinates of maximum Psychometric Chroma
for a given Psychometric Hue Angle and <acronym>CIE</acronym> metric lightness (L*), use
<function>XcmsCIELuvQueryMaxC .</function>
</para>
<indexterm significance="preferred"><primary>XcmsCIELuvQueryMaxC</primary></indexterm>
@ -5773,7 +5773,7 @@ Specifies the lightness (L*) at which to find (Ls.
</term>
<listitem>
<para>
Returns the CIE L*u*v* coordinates of (Lc
Returns the <acronym>CIE</acronym> L*u*v* coordinates of (Lc
displayable by the screen for the given (lC.
The white point associated with the returned
color specification is the Screen White Point.
@ -5790,18 +5790,18 @@ The
<function>XcmsCIELuvQueryMaxC</function>
function, given a hue angle and lightness,
finds the point of maximum chroma displayable by the screen.
It returns this point in CIE L*u*v* coordinates.
It returns this point in <acronym>CIE</acronym> L*u*v* coordinates.
<!-- .sp -->
</para>
<para>
<!-- .LP -->
To obtain the CIE L*u*v* coordinates of maximum CIE metric lightness (L*)
To obtain the <acronym>CIE</acronym> L*u*v* coordinates of maximum <acronym>CIE</acronym> metric lightness (L*)
for a given Psychometric Hue Angle and Psychometric Chroma, use
<function>XcmsCIELuvQueryMaxL .</function>
</para>
<indexterm><primary>Psychometric Hue Angle</primary></indexterm>
<indexterm><primary>CIE metric lightness</primary></indexterm>
<indexterm><primary>CIE metric lightness</primary><secondary>maximum</secondary></indexterm>
<indexterm><primary><acronym>CIE</acronym> metric lightness</primary></indexterm>
<indexterm><primary><acronym>CIE</acronym> metric lightness</primary><secondary>maximum</secondary></indexterm>
<indexterm significance="preferred"><primary>XcmsCIELuvQueryMaxL</primary></indexterm>
<!-- .sM -->
<funcsynopsis>
@ -5857,7 +5857,7 @@ Specifies the lightness (L*) at which to find (Ls.
</term>
<listitem>
<para>
Returns the CIE L*u*v* coordinates of (Lc
Returns the <acronym>CIE</acronym> L*u*v* coordinates of (Lc
displayable by the screen for the given (lC.
The white point associated with the returned
color specification is the Screen White Point.
@ -5873,9 +5873,9 @@ The value returned in the pixel member is undefined.
The
<function>XcmsCIELuvQueryMaxL</function>
function, given a hue angle and chroma,
finds the point in CIE L*u*v* color space of maximum
finds the point in <acronym>CIE</acronym> L*u*v* color space of maximum
lightness (L*) displayable by the screen.
It returns this point in CIE L*u*v* coordinates.
It returns this point in <acronym>CIE</acronym> L*u*v* coordinates.
An
<function>XcmsFailure</function>
return value usually indicates that the given chroma
@ -5884,15 +5884,15 @@ is beyond maximum for the given hue angle.
</para>
<para>
<!-- .LP -->
To obtain the CIE L*u*v* coordinates of maximum Psychometric Chroma
To obtain the <acronym>CIE</acronym> L*u*v* coordinates of maximum Psychometric Chroma
for a given Psychometric Hue Angle, use
<function>XcmsCIELuvQueryMaxLC .</function>
</para>
<indexterm><primary>Psychometric Hue Angle</primary></indexterm>
<indexterm><primary>Psychometric Chroma</primary></indexterm>
<indexterm><primary>CIE metric lightness</primary></indexterm>
<indexterm><primary><acronym>CIE</acronym> metric lightness</primary></indexterm>
<indexterm><primary>Psychometric Chroma</primary><secondary>maximum</secondary></indexterm>
<indexterm><primary>CIE metric lightness</primary><secondary>maximum</secondary></indexterm>
<indexterm><primary><acronym>CIE</acronym> metric lightness</primary><secondary>maximum</secondary></indexterm>
<indexterm significance="preferred"><primary>XcmsCIELuvQueryMaxLC</primary></indexterm>
<!-- .sM -->
<funcsynopsis>
@ -5936,7 +5936,7 @@ Specifies the hue angle (in degrees) at which to find (Ha.
</term>
<listitem>
<para>
Returns the CIE L*u*v* coordinates of (Lc
Returns the <acronym>CIE</acronym> L*u*v* coordinates of (Lc
displayable by the screen for the given (lC.
The white point associated with the returned
color specification is the Screen White Point.
@ -5953,18 +5953,18 @@ The
<function>XcmsCIELuvQueryMaxLC</function>
function, given a hue angle,
finds the point of maximum chroma displayable by the screen.
It returns this point in CIE L*u*v* coordinates.
It returns this point in <acronym>CIE</acronym> L*u*v* coordinates.
<!-- .sp -->
</para>
<para>
<!-- .LP -->
To obtain the CIE L*u*v* coordinates of minimum CIE metric lightness (L*)
To obtain the <acronym>CIE</acronym> L*u*v* coordinates of minimum <acronym>CIE</acronym> metric lightness (L*)
for a given Psychometric Hue Angle and Psychometric Chroma, use
<function>XcmsCIELuvQueryMinL .</function>
</para>
<indexterm><primary>Psychometric Hue Angle</primary></indexterm>
<indexterm><primary>CIE metric lightness</primary></indexterm>
<indexterm><primary>CIE metric lightness</primary><secondary>minimum</secondary></indexterm>
<indexterm><primary><acronym>CIE</acronym> metric lightness</primary></indexterm>
<indexterm><primary><acronym>CIE</acronym> metric lightness</primary><secondary>minimum</secondary></indexterm>
<indexterm significance="preferred"><primary>XcmsCIELuvQueryMinL</primary></indexterm>
<!-- .sM -->
<funcsynopsis>
@ -6020,7 +6020,7 @@ Specifies the chroma at which to find (Ch.
</term>
<listitem>
<para>
Returns the CIE L*u*v* coordinates of (Lc
Returns the <acronym>CIE</acronym> L*u*v* coordinates of (Lc
displayable by the screen for the given (lC.
The white point associated with the returned
color specification is the Screen White Point.
@ -6037,7 +6037,7 @@ The
<function>XcmsCIELuvQueryMinL</function>
function, given a hue angle and chroma,
finds the point of minimum lightness (L*) displayable by the screen.
It returns this point in CIE L*u*v* coordinates.
It returns this point in <acronym>CIE</acronym> L*u*v* coordinates.
An
<function>XcmsFailure</function>
return value usually indicates that the given chroma
@ -6479,7 +6479,7 @@ Device-Independent Color Spaces
</listitem>
<listitem>
<para>
Device-independent color spaces that are derivable to CIE XYZ
Device-independent color spaces that are derivable to <acronym>CIE</acronym> XYZ
space can be added using the
<function>XcmsAddColorSpace</function>
function.
@ -6494,7 +6494,7 @@ Color Characterization Function Set
<para>
A Color Characterization Function Set consists of
device-dependent color spaces and their functions that
convert between these color spaces and the CIE XYZ
convert between these color spaces and the <acronym>CIE</acronym> XYZ
color space, bundled together for a specific class of output devices.
A function set can be added using the
<function>XcmsAddFunctionSet</function>
@ -6509,17 +6509,17 @@ function.
<!-- .XE -->
<para>
<!-- .LP -->
The CIE XYZ color space serves as the hub for all
The <acronym>CIE</acronym> XYZ color space serves as the hub for all
conversions between device-independent and device-dependent color spaces.
Therefore, the knowledge to convert an
<function>XcmsColor</function>
structure to and from CIE XYZ format is associated with each color space.
For example, conversion from CIE L*u*v* to RGB requires the knowledge
to convert from CIE L*u*v* to CIE XYZ and from CIE XYZ to RGB.
structure to and from <acronym>CIE</acronym> XYZ format is associated with each color space.
For example, conversion from <acronym>CIE</acronym> L*u*v* to <acronym>RGB</acronym> requires the knowledge
to convert from <acronym>CIE</acronym> L*u*v* to <acronym>CIE</acronym> XYZ and from <acronym>CIE</acronym> XYZ to <acronym>RGB</acronym>.
This knowledge is stored as an array of functions that,
when applied in series, will convert the
<function>XcmsColor</function>
structure to or from CIE XYZ format.
structure to or from <acronym>CIE</acronym> XYZ format.
This color specification conversion mechanism facilitates
the addition of color spaces.
</para>
@ -6528,9 +6528,9 @@ the addition of color spaces.
Of course, when converting between only device-independent color spaces
or only device-dependent color spaces,
shortcuts are taken whenever possible.
For example, conversion from TekHVC to CIE L*u*v* is performed
by intermediate conversion to CIE u*v*Y and then to CIE L*u*v*,
thus bypassing conversion between CIE u*v*Y and CIE XYZ.
For example, conversion from TekHVC to <acronym>CIE</acronym> L*u*v* is performed
by intermediate conversion to <acronym>CIE</acronym> u*v*Y and then to <acronym>CIE</acronym> L*u*v*,
thus bypassing conversion between <acronym>CIE</acronym> u*v*Y and <acronym>CIE</acronym> XYZ.
</para>
</sect2>
<sect2 id="Adding_Device_Independent_Color_Spaces">
@ -6745,8 +6745,8 @@ typedef struct _XcmsColorSpace {
<!-- .eM -->
The prefix member specifies the prefix that indicates a color string
is in this color space's string format.
For example, the strings ``ciexyz'' or ``CIEXYZ'' for CIE XYZ,
and ``rgb'' or ``RGB'' for RGB.
For example, the strings ``ciexyz'' or ``CIEXYZ'' for <acronym>CIE</acronym> XYZ,
and ``rgb'' or ``<acronym>RGB</acronym>'' for <acronym>RGB</acronym>.
The prefix is case insensitive.
The format member specifies the color specification format.
Formats for unregistered color spaces are assigned at run time.
@ -6761,7 +6761,7 @@ each to a NULL terminated list of function pointers.
When the list of functions is executed in series,
it will convert the color specified in an
<function>XcmsColor</function>
structure from/to the current color space format to/from the CIE XYZ format.
structure from/to the current color space format to/from the <acronym>CIE</acronym> XYZ format.
Each function returns an integer (int): nonzero if it succeeded
and zero otherwise.
The white point to be associated with the colors is specified
@ -6782,7 +6782,7 @@ for each i, such that 0 &lt;= i &lt; n
<para>
<!-- .LP -->
This allows Xlib to use the shortest conversion path,
thus bypassing CIE XYZ if possible (for example, TekHVC to CIE L*u*v*).
thus bypassing <acronym>CIE</acronym> XYZ if possible (for example, TekHVC to <acronym>CIE</acronym> L*u*v*).
</para>
</sect2>
<sect2 id="Parse_String_Callback">
@ -7084,13 +7084,13 @@ The conversion functions provided by Xlib are:
<para>
<!-- .LP -->
Functions to convert between device-dependent color spaces
and CIE XYZ may differ for different classes of output devices
and <acronym>CIE</acronym> XYZ may differ for different classes of output devices
(for example, color versus gray monitors).
Therefore, the notion of a Color Characterization Function Set
has been developed.
A function set consists of device-dependent color spaces
and the functions that convert color specifications
between these device-dependent color spaces and the CIE XYZ color space
between these device-dependent color spaces and the <acronym>CIE</acronym> XYZ color space
appropriate for a particular class of output devices.
The function set also contains a function that reads
color characterization data off root window properties.
@ -7215,7 +7215,7 @@ structures are allowed for a device-dependent color space;
however, a function set can reference only one of them.
These
<function>XcmsColorSpace</function>
structures will differ in the functions to convert to and from CIE XYZ,
structures will differ in the functions to convert to and from <acronym>CIE</acronym> XYZ,
thus tailored for the specific function set.
<!-- .sM -->
</para>

10
specs/libX11/CH09.xml
View file

@ -1404,7 +1404,7 @@ The host the window system is running on.
</listitem>
<listitem>
<para>
On POSIX-conformant systems, each host listed in the
On <acronym>POSIX</acronym>-conformant systems, each host listed in the
<function>/etc/X?.hosts </function>
file.
The ? indicates the number of the
@ -1463,7 +1463,7 @@ typedef struct {
<!-- .LP -->
<!-- .eM -->
The family member specifies which protocol address family to use
(for example, TCP/IP or DECnet) and can be
(for example, <acronym>TCP</acronym>/<acronym>IP</acronym> or DECnet) and can be
<function>FamilyInternet ,</function>
<function>FamilyInternet6 ,</function>
<function>FamilyServerInterpreted ,</function>
@ -1475,9 +1475,9 @@ The address member specifies a pointer to the address.
</para>
<para>
<!-- .LP -->
For TCP/IP, the address should be in network byte order.
For IP version 4 addresses, the family should be FamilyInternet
and the length should be 4 bytes. For IP version 6 addresses, the
For <acronym>TCP</acronym>/<acronym>IP</acronym>, the address should be in network byte order.
For <acronym>IP</acronym> version 4 addresses, the family should be FamilyInternet
and the length should be 4 bytes. For <acronym>IP</acronym> version 6 addresses, the
family should be FamilyInternet6 and the length should be 16 bytes.
</para>
<para>

2
specs/libX11/CH11.xml
View file

@ -1809,7 +1809,7 @@ The following function lets you disable or enable synchronous behavior.
Note that graphics may occur 30 or more times more slowly when
synchronization is enabled.
<indexterm><primary>_Xdebug</primary></indexterm>
On POSIX-conformant systems,
On <acronym>POSIX</acronym>-conformant systems,
there is also a global variable
<function>_Xdebug </function>
that, if set to nonzero before starting a program under a debugger, will force

6
specs/libX11/CH12.xml
View file

@ -2261,7 +2261,7 @@ error.
<para>
<!-- .LP -->
If both the led_mode and led members are specified,
the state of that LED is changed, if possible.
the state of that <acronym>LED</acronym> is changed, if possible.
The led_mode member can be set to
<function>LedModeOn</function>
or
@ -2454,8 +2454,8 @@ typedef struct {
<!-- .LP -->
<!-- .eM -->
For the LEDs,
the least significant bit of led_mask corresponds to LED one,
and each bit set to 1 in led_mask indicates an LED that is lit.
the least significant bit of led_mask corresponds to <acronym>LED</acronym> one,
and each bit set to 1 in led_mask indicates an <acronym>LED</acronym> that is lit.
The global_auto_repeat member can be set to
<function>AutoRepeatModeOn</function>
or

226
specs/libX11/CH13.xml
View file

@ -9,8 +9,8 @@ internationalization is to permit localization without program source modificat
tion.
</para>
<para>
As one of the localization mechanisms, Xlib provides an X Input Method (XIM) functional inter-
face for internationalized text input and an X Output Method (XOM) functional interface for
As one of the localization mechanisms, Xlib provides an X Input Method (<acronym>XIM</acronym>) functional inter-
face for internationalized text input and an X Output Method (<acronym>XOM</acronym>) functional interface for
internationalized text output.
</para>
<para>
@ -175,11 +175,11 @@ having zero or more concatenated ``@<emphasis remap='I'>category</emphasis>=<emp
entries, where <emphasis remap='I'>category</emphasis> is a category name
and <emphasis remap='I'>value</emphasis> is the (possibly empty) setting for that category.
The values are encoded in the current locale.
Category names are restricted to the POSIX Portable Filename Character Set.
Category names are restricted to the <acronym>POSIX</acronym> Portable Filename Character Set.
</para>
<para>
<!-- .LP -->
The local host X locale modifiers announcer (on POSIX-compliant systems,
The local host X locale modifiers announcer (on <acronym>POSIX</acronym>-compliant systems,
the XMODIFIERS environment variable) is appended to the modifier_list to
provide default values on the local host.
If a given category appears more than once in the list,
@ -377,22 +377,22 @@ the following table describes the locale (and modifiers) dependency:
<row>
<entry><function>setlocale</function></entry>
<entry><function>XOpenIM</function></entry>
<entry>XIM input method selection</entry>
<entry><acronym>XIM</acronym> input method selection</entry>
</row>
<row>
<entry></entry>
<entry><function>XRegisterIMInstantiateCallback</function></entry>
<entry>XIM selection</entry>
<entry><acronym>XIM</acronym> selection</entry>
</row>
<row>
<entry></entry>
<entry><function>XUnregisterIMInstantiateCallback</function></entry>
<entry>XIM selection</entry>
<entry><acronym>XIM</acronym> selection</entry>
</row>
<row>
<entry><function>XIM</function></entry>
<entry><function>XCreateIC</function></entry>
<entry>XIC input method configuration</entry>
<entry><acronym>XIC</acronym> input method configuration</entry>
</row>
<row>
<entry></entry>
@ -419,7 +419,7 @@ the following table describes the locale (and modifiers) dependency:
<row>
<entry><function>setlocale</function></entry>
<entry><function>XOpenOM</function></entry>
<entry>XOM output method selection</entry>
<entry><acronym>XOM</acronym> output method selection</entry>
</row>
<row>
<entry></entry>
@ -429,7 +429,7 @@ the following table describes the locale (and modifiers) dependency:
<row>
<entry><function>XOM</function></entry>
<entry><function>XCreateOC</function></entry>
<entry>XOC output method configuration</entry>
<entry><acronym>XOC</acronym> output method configuration</entry>
</row>
<row>
<entry></entry>
@ -598,7 +598,7 @@ when it is no longer needed.
<para>
<!-- .LP -->
This section provides discussions of the following X Output Method
(XOM) topics:
(<acronym>XOM</acronym>) topics:
</para>
<itemizedlist>
<listitem>
@ -896,7 +896,7 @@ To set output method attributes, use
<listitem>
<para>
Specifies the output method.
<!-- .ds Al \ to set XOM values -->
<!-- .ds Al \ to set <acronym>XOM</acronym> values -->
</para>
</listitem>
</varlistentry>
@ -1051,10 +1051,10 @@ returns the locale associated with the specified output method.
<!-- .XE -->
<para>
<!-- .LP -->
The following table describes how XOM values are interpreted by an
The following table describes how <acronym>XOM</acronym> values are interpreted by an
output method.
The first column lists the XOM values. The second column indicates
how each of the XOM values are treated by a particular output style.
The first column lists the <acronym>XOM</acronym> values. The second column indicates
how each of the <acronym>XOM</acronym> values are treated by a particular output style.
</para>
<para>
<!-- .LP -->
@ -1089,7 +1089,7 @@ The following key applies to this table.
<colspec colname='c2'/>
<thead>
<row>
<entry>XOM Value</entry>
<entry><acronym>XOM</acronym> Value</entry>
<entry>Key</entry>
</row>
</thead>
@ -1323,9 +1323,9 @@ to display that data.
There can be multiple output contexts for one output method.
The programming interfaces for creating, reading, or modifying
an output context use a variable argument list.
The name elements of the argument lists are referred to as XOC values.
It is intended that output methods be controlled by these XOC values.
As new XOC values are created,
The name elements of the argument lists are referred to as <acronym>XOC</acronym> values.
It is intended that output methods be controlled by these <acronym>XOC</acronym> values.
As new <acronym>XOC</acronym> values are created,
they should be registered with the X Consortium.
An
<function>XOC</function>
@ -1367,7 +1367,7 @@ To create an output context, use
<listitem>
<para>
Specifies the output method.
<!-- .ds Al \ to set XOC values -->
<!-- .ds Al \ to set <acronym>XOC</acronym> values -->
</para>
</listitem>
</varlistentry>
@ -1509,13 +1509,13 @@ respectively,
and
<function>XGetOCValues .</function>
Both functions have a variable-length argument list.
In that argument list, any XOC value's name must be denoted
In that argument list, any <acronym>XOC</acronym> value's name must be denoted
with a character string using the X Portable Character Set.
</para>
<para>
<!-- .LP -->
<!-- .sp -->
To set XOC values, use
To set <acronym>XOC</acronym> values, use
<function>XSetOCValues .</function>
<indexterm significance="preferred"><primary>XSetOCValues</primary></indexterm>
<!-- .sM -->
@ -1534,7 +1534,7 @@ To set XOC values, use
<listitem>
<para>
Specifies the output context.
<!-- .ds Al \ to set XOC values -->
<!-- .ds Al \ to set <acronym>XOC</acronym> values -->
</para>
</listitem>
</varlistentry>
@ -1592,7 +1592,7 @@ error.
<para>
<!-- .LP -->
<!-- .sp -->
To obtain XOC values, use
To obtain <acronym>XOC</acronym> values, use
<function>XGetOCValues .</function>
<indexterm significance="preferred"><primary>XGetOCValues</primary></indexterm>
<!-- .sM -->
@ -1662,12 +1662,12 @@ following a name must point to a location where the value is to be stored.
<!-- .XE -->
<para>
<!-- .LP -->
The following table describes how XOC values are interpreted
The following table describes how <acronym>XOC</acronym> values are interpreted
by an output method.
The first column lists the XOC values.
The first column lists the <acronym>XOC</acronym> values.
The second column indicates the alternative interfaces that function
identically and are provided for compatibility with previous releases.
The third column indicates how each of the XOC values is treated.
The third column indicates how each of the <acronym>XOC</acronym> values is treated.
</para>
<!-- .LP -->
<para>
@ -1713,7 +1713,7 @@ The following keys apply to this table.
<colspec colname='c3'/>
<thead>
<row>
<entry>XOC Value</entry>
<entry><acronym>XOC</acronym> Value</entry>
<entry>Alternative Interface</entry>
<entry>Key</entry>
</row>
@ -1784,25 +1784,25 @@ White space immediately on either side of a separating comma is ignored.
</para>
<para>
<!-- .LP -->
Use of XLFD font names permits Xlib to obtain the fonts needed for a
Use of <acronym>XLFD</acronym> font names permits Xlib to obtain the fonts needed for a
variety of locales from a single locale-independent base font name.
The single base font name should name a family of fonts whose members
are encoded in the various charsets needed by the locales of interest.
</para>
<para>
<!-- .LP -->
An XLFD base font name can explicitly name a charset needed for the locale.
An <acronym>XLFD</acronym> base font name can explicitly name a charset needed for the locale.
This allows the user to specify an exact font for use with a charset required
by a locale, fully controlling the font selection.
</para>
<para>
<!-- .LP -->
If a base font name is not an XLFD name,
Xlib will attempt to obtain an XLFD name from the font properties
If a base font name is not an <acronym>XLFD</acronym> name,
Xlib will attempt to obtain an <acronym>XLFD</acronym> name from the font properties
for the font.
If Xlib is successful, the
<function>XGetOCValues</function>
function will return this XLFD name instead of the client-supplied name.
function will return this <acronym>XLFD</acronym> name instead of the client-supplied name.
</para>
<para>
<!-- .LP -->
@ -1818,7 +1818,7 @@ returns NULL.
<!-- .LP -->
When querying for the
<function>XNBaseFontName</function>
XOC value,
<acronym>XOC</acronym> value,
<function>XGetOCValues</function>
returns a null-terminated string identifying the base font names that
Xlib used to load the fonts needed for the locale.
@ -1973,7 +1973,7 @@ the resources will not be fully specified.
</para>
<para>
<!-- .LP -->
It is not intended that values that can be set as XOM values be
It is not intended that values that can be set as <acronym>XOM</acronym> values be
set as resources.
</para>
<para>
@ -1982,7 +1982,7 @@ When querying for the
<function>XNResourceName</function>
or
<function>XNResourceClass</function>
XOC value,
<acronym>XOC</acronym> value,
<function>XGetOCValues</function>
returns a null-terminated string.
This string is owned by Xlib and should not be modified or freed by
@ -2232,25 +2232,25 @@ White space immediately on either side of a separating comma is ignored.
</para>
<para>
<!-- .LP -->
Use of XLFD font names permits Xlib to obtain the fonts needed for a
Use of <acronym>XLFD</acronym> font names permits Xlib to obtain the fonts needed for a
variety of locales from a single locale-independent base font name.
The single base font name should name a family of fonts whose members
are encoded in the various charsets needed by the locales of interest.
</para>
<para>
<!-- .LP -->
An XLFD base font name can explicitly name a charset needed for the locale.
An <acronym>XLFD</acronym> base font name can explicitly name a charset needed for the locale.
This allows the user to specify an exact font for use with a charset required
by a locale, fully controlling the font selection.
</para>
<para>
<!-- .LP -->
If a base font name is not an XLFD name,
Xlib will attempt to obtain an XLFD name from the font properties
If a base font name is not an <acronym>XLFD</acronym> name,
Xlib will attempt to obtain an <acronym>XLFD</acronym> name from the font properties
for the font.
If this action is successful in obtaining an XLFD name, the
If this action is successful in obtaining an <acronym>XLFD</acronym> name, the
<function>XBaseFontNameListOfFontSet</function>
function will return this XLFD name instead of the client-supplied name.
function will return this <acronym>XLFD</acronym> name instead of the client-supplied name.
</para>
<para>
<!-- .LP -->
@ -2267,7 +2267,7 @@ of the following cases that names a set of fonts that exist at the server:
<itemizedlist>
<listitem>
<para>
The first XLFD-conforming base font name that specifies the required
The first <acronym>XLFD</acronym>-conforming base font name that specifies the required
charset or a superset of the required charset in its
<function>CharSetRegistry</function>
and
@ -2280,7 +2280,7 @@ an ISO8859-1 font for an ASCII charset.
</listitem>
<listitem>
<para>
The first set of one or more XLFD-conforming base font names
The first set of one or more <acronym>XLFD</acronym>-conforming base font names
that specify one or more charsets that can be remapped to support the
required charset.
The Xlib implementation may recognize various mappings
@ -2294,13 +2294,13 @@ if a JIS Roman font is not available.
</listitem>
<listitem>
<para>
The first XLFD-conforming font name or the first non-XLFD font name
for which an XLFD font name can be obtained, combined with the
The first <acronym>XLFD</acronym>-conforming font name or the first non-<acronym>XLFD</acronym> font name
for which an <acronym>XLFD</acronym> font name can be obtained, combined with the
required charset (replacing the
<function>CharSetRegistry</function>
and
<function>CharSetEncoding</function>
fields in the XLFD font name).
fields in the <acronym>XLFD</acronym> font name).
As in case 1,
the implementation may use a charset that is a superset
of the required charset.
@ -2361,7 +2361,7 @@ For example:
<!-- .LP -->
Alternatively, the user could simply supply a single base font name
that allows Xlib to select from all available fonts
that meet certain minimum XLFD property requirements.
that meet certain minimum <acronym>XLFD</acronym> property requirements.
For example:
</para>
<para>
@ -2621,10 +2621,10 @@ White space may appear immediately on either side of separating commas.
<!-- .LP -->
If
<function>XCreateFontSet</function>
obtained an XLFD name from the font properties for the font specified
by a non-XLFD base name, the
obtained an <acronym>XLFD</acronym> name from the font properties for the font specified
by a non-<acronym>XLFD</acronym> base name, the
<function>XBaseFontNameListOfFontSet</function>
function will return the XLFD name instead of the non-XLFD base name.
function will return the <acronym>XLFD</acronym> name instead of the non-<acronym>XLFD</acronym> base name.
</para>
<para>
<!-- .LP -->
@ -4032,7 +4032,7 @@ The behavior for an invalid codepoint is undefined.
<para>
<!-- .LP -->
This section provides discussions of the following X Input Method
(XIM) topics:
(<acronym>XIM</acronym>) topics:
</para>
<itemizedlist>
<listitem>
@ -4640,7 +4640,7 @@ Otherwise, it will set one of the values.
</listitem>
<listitem>
<para>
The client will get the XIC value
The client will get the <acronym>XIC</acronym> value
<function>XNAreaNeeded .</function>
The input method will return its suggested size in this value.
The input method should pay attention to any constraints suggested
@ -4649,7 +4649,7 @@ by the client.
</listitem>
<listitem>
<para>
The client sets the XIC value
The client sets the <acronym>XIC</acronym> value
<function>XNArea</function>
to inform the input method of the geometry of its window.
The client should try to honor the geometry requested by the input method.
@ -4660,7 +4660,7 @@ The input method must accept this geometry.
<para>
<!-- .LP -->
Clients doing geometry management must be aware that setting other
XIC values may affect the geometry desired by an input method.
<acronym>XIC</acronym> values may affect the geometry desired by an input method.
For example,
<function>XNFontSet</function>
and
@ -4669,7 +4669,7 @@ may change the geometry desired by the input method.
</para>
<para>
<!-- .LP -->
The table of XIC values (see section 13.5.6)
The table of <acronym>XIC</acronym> values (see section 13.5.6)
indicates the values that can cause the desired geometry to change
when they are set.
It is the responsibility of the client to renegotiate the geometry
@ -4728,7 +4728,7 @@ to translations such as those the X Toolkit Intrinsics library provides.
</itemizedlist>
<para>
<!-- .LP -->
Clients are expected to get the XIC value
Clients are expected to get the <acronym>XIC</acronym> value
<function>XNFilterEvents</function>
and augment the event mask for the client window with that event mask.
This mask may be zero.
@ -4821,7 +4821,7 @@ This provides the basics for input methods.
In addition to preediting based on key events, a general framework
is provided to give a client that desires it more advanced preediting based
on the text within the client. This framework is called
<emphasis remap='I'>string conversion</emphasis> and is provided using XIC values.
<emphasis remap='I'>string conversion</emphasis> and is provided using <acronym>XIC</acronym> values.
The fundamental concept of string conversion
is to allow the input method to manipulate the client's
text independent of any user preediting operation.
@ -4922,10 +4922,10 @@ String conversion support is dependent on the availability of the
<function>XNStringConversion</function>
or
<function>XNStringConversionCallback </function>
XIC values.
<acronym>XIC</acronym> values.
Because the input method may not support string conversions,
clients have to query the availability of string conversion
operations by checking the supported XIC values list by calling
operations by checking the supported <acronym>XIC</acronym> values list by calling
<function>XGetIMValues</function>
with the
<function>XNQueryICValuesList</function>
@ -4937,7 +4937,7 @@ The difference between these two values is whether the
conversion is invoked by the client or the input method.
The
<function>XNStringConversion</function>
XIC value is used by clients to request
<acronym>XIC</acronym> value is used by clients to request
a string conversion from the input method. The client
is responsible for determining which events are used
to trigger the string conversion and whether the string to be
@ -4953,7 +4953,7 @@ only set one of these values.
<!-- .LP -->
The
<function>XNStringConversionCallback</function>
XIC value is used by the client to notify the input method that
<acronym>XIC</acronym> value is used by the client to notify the input method that
it will accept requests from the input method for string conversion.
If this value is set,
it is the input method's responsibility to determine which
@ -5049,7 +5049,7 @@ functions are provided:
</row>
<row>
<entry><function>XSetIMValue</function>, <function>XSetICValue</function></entry>
<entry>These functions use the XIM and XIC values,
<entry>These functions use the <acronym>XIM</acronym> and <acronym>XIC</acronym> values,
<function>XNDestroyCallback ,</function>
to allow a client
to register a callback procedure to be called when Xlib detects that
@ -5112,7 +5112,7 @@ The HotKey mechanism allows clients
to specify a set of keys for this purpose. However, the input
method might not allow clients to specify hot keys.
Therefore, clients have to query support of hot keys by checking the
supported XIC values list by calling
supported <acronym>XIC</acronym> values list by calling
<function>XGetIMValues</function>
with the
<function>XNQueryICValuesList</function>
@ -5143,14 +5143,14 @@ One method is to query the state by calling
<function>XGetICValues</function>
with the
<function>XNPreeditState</function>
XIC value.
<acronym>XIC</acronym> value.
Another method is to receive notification whenever
the preedit state is changed. To receive such notification,
an application needs to register a callback by calling
<function>XSetICValues</function>
with the
<function>XNPreeditStateNotifyCallback</function>
XIC value.
<acronym>XIC</acronym> value.
In order to change the preedit state programmatically, an application
needs to call
<function>XSetICValues</function>
@ -5163,7 +5163,7 @@ Availability of the preedit state is input method dependent. The input
method may not provide the ability to set the state or to
retrieve the state programmatically. Therefore, clients have to
query availability of preedit state operations by checking the
supported XIC values list by calling
supported <acronym>XIC</acronym> values list by calling
<function>XGetIMValues</function>
with the
<function>XNQueryICValuesList</function>
@ -5352,7 +5352,7 @@ To set input method attributes, use
<listitem>
<para>
Specifies the input method.
<!-- .ds Al \ to set XIM values -->
<!-- .ds Al \ to set <acronym>XIM</acronym> values -->
</para>
</listitem>
</varlistentry>
@ -5434,9 +5434,9 @@ it returns the name of the first argument that could not be obtained.
</para>
<para>
<!-- .LP -->
Each XIM value argument (following a name) must point to
a location where the XIM value is to be stored.
That is, if the XIM value is of type T,
Each <acronym>XIM</acronym> value argument (following a name) must point to
a location where the <acronym>XIM</acronym> value is to be stored.
That is, if the <acronym>XIM</acronym> value is of type T,
the argument must be of type T*.
If T itself is a pointer type,
then
@ -5761,10 +5761,10 @@ if it succeeds; otherwise, it returns
<!-- .XE -->
<para>
<!-- .LP -->
The following table describes how XIM values are interpreted
The following table describes how <acronym>XIM</acronym> values are interpreted
by an input method.
The first column lists the XIM values.
The second column indicates how each of the XIM values
The first column lists the <acronym>XIM</acronym> values.
The second column indicates how each of the <acronym>XIM</acronym> values
are treated by that input style.
</para>
<para>
@ -5811,7 +5811,7 @@ The following keys apply to this table.
<colspec colname='c2'/>
<thead>
<row>
<entry>XIM Value</entry>
<entry><acronym>XIM</acronym> Value</entry>
<entry>Key</entry>
</row>
</thead>
@ -5969,7 +5969,7 @@ by the input method for preedit information.
<entry>If chosen,
the input method would require the client to provide some area values
for it to do its preediting.
Refer to XIC values
Refer to <acronym>XIC</acronym> values
<function>XNArea</function>
and
<function>XNAreaNeeded .</function></entry>
@ -5978,7 +5978,7 @@ by the input method for preedit information.
<entry><function>XIMPreeditPosition</function></entry>
<entry>If chosen,
the input method would require the client to provide positional values.
Refer to XIC values
Refer to <acronym>XIC</acronym> values
<function>XNSpotLocation</function>
and
<function>XNFocusWindow .</function></entry>
@ -5987,7 +5987,7 @@ by the input method for preedit information.
<entry><function>XIMPreeditCallbacks</function></entry>
<entry>If chosen,
the input method would require the client to define the set of preedit callbacks.
Refer to XIC values
Refer to <acronym>XIC</acronym> values
<function>XNPreeditStartCallback ,</function>
<function>XNPreeditDoneCallback , </function>
<function>XNPreeditDrawCallback ,</function>
@ -6074,7 +6074,7 @@ the resources will not be fully specified.
</para>
<para>
<!-- .LP -->
It is not intended that values that can be set as XIM values be
It is not intended that values that can be set as <acronym>XIM</acronym> values be
set as resources.
</para>
<para>
@ -6167,7 +6167,7 @@ A DestroyCallback is always called with a NULL call_data argument.
<function>XNQueryIMValuesList</function>
and
<function>XNQueryICValuesList</function>
are used to query about XIM and XIC values supported by the input method.
are used to query about <acronym>XIM</acronym> and <acronym>XIC</acronym> values supported by the input method.
</para>
<para>
<!-- .LP -->
@ -6231,7 +6231,7 @@ otherwise, the input method does not use the masks.
</para>
<para>
<!-- .LP -->
Because this XIM value is optional, a client should call
Because this <acronym>XIM</acronym> value is optional, a client should call
<function>XGetIMValues</function>
with argument
<function>XNQueryIMValues</function>
@ -6301,7 +6301,7 @@ must be set to
</para>
<para>
<!-- .LP -->
Because this XIM value is optional, a client should call
Because this <acronym>XIM</acronym> value is optional, a client should call
<function>XGetIMValues</function>
with argument
<function>XNQueryIMValues</function>
@ -6330,9 +6330,9 @@ to display that data.
There may be multiple input contexts for one input method.
The programming interfaces for creating, reading, or modifying
an input context use a variable argument list.
The name elements of the argument lists are referred to as XIC values.
It is intended that input methods be controlled by these XIC values.
As new XIC values are created,
The name elements of the argument lists are referred to as <acronym>XIC</acronym> values.
It is intended that input methods be controlled by these <acronym>XIC</acronym> values.
As new <acronym>XIC</acronym> values are created,
they should be registered with the X Consortium.
</para>
<para>
@ -6357,7 +6357,7 @@ To create an input context, use
<listitem>
<para>
Specifies the input method.
<!-- .ds Al \ to set XIC values -->
<!-- .ds Al \ to set <acronym>XIC</acronym> values -->
</para>
</listitem>
</varlistentry>
@ -6667,18 +6667,18 @@ function returns the input method associated with the specified input context.
<para>
<!-- .LP -->
<!-- .sp -->
Xlib provides two functions for setting and reading XIC values, respectively,
Xlib provides two functions for setting and reading <acronym>XIC</acronym> values, respectively,
<function>XSetICValues</function>
and
<function>XGetICValues .</function>
Both functions have a variable-length argument list.
In that argument list, any XIC value's name must be denoted
In that argument list, any <acronym>XIC</acronym> value's name must be denoted
with a character string using the X Portable Character Set.
</para>
<para>
<!-- .LP -->
<!-- .sp -->
To set XIC values, use
To set <acronym>XIC</acronym> values, use
<function>XSetICValues .</function>
<indexterm significance="preferred"><primary>XSetICValues</primary></indexterm>
<!-- .sM -->
@ -6697,7 +6697,7 @@ To set XIC values, use
<listitem>
<para>
Specifies the input context.
<!-- .ds Al \ to set XIC values -->
<!-- .ds Al \ to set <acronym>XIC</acronym> values -->
</para>
</listitem>
</varlistentry>
@ -6761,7 +6761,7 @@ errors.
<para>
<!-- .LP -->
<!-- .sp -->
To obtain XIC values, use
To obtain <acronym>XIC</acronym> values, use
<function>XGetICValues .</function>
<indexterm significance="preferred"><primary>XGetICValues</primary></indexterm>
<!-- .sM -->
@ -6846,18 +6846,18 @@ applies to each element of the nested list.
<!-- .XE -->
<para>
<!-- .LP -->
The following tables describe how XIC values are interpreted
The following tables describe how <acronym>XIC</acronym> values are interpreted
by an input method depending on the input style chosen by the
user.
</para>
<para>
<!-- .LP -->
The first column lists the XIC values.
The first column lists the <acronym>XIC</acronym> values.
The second column indicates which values are involved in affecting,
negotiating, and setting the geometry of the input method windows.
The subentries under the third column indicate the different
input styles that are supported.
Each of these columns indicates how each of the XIC values
Each of these columns indicates how each of the <acronym>XIC</acronym> values
are treated by that input style.
</para>
<para>
@ -6937,7 +6937,7 @@ The following keys apply to these tables.
<colspec colname='c7'/>
<tbody>
<row>
<entry>XIC Value</entry>
<entry><acronym>XIC</acronym> Value</entry>
<entry>Geometry Mangement</entry>
<entry>Preedit Callback</entry>
<entry>Preedit Position</entry>
@ -7197,7 +7197,7 @@ The following keys apply to these tables.
<colspec colname='c6'/>
<thead>
<row>
<entry>XIC Value</entry>
<entry><acronym>XIC</acronym> Value</entry>
<entry>Geomentry Management</entry>
<entry>Status Callback</entry>
<entry>Status Area</entry>
@ -7462,7 +7462,7 @@ error can be generated when this value is used by the input method.
</para>
<para>
<!-- .LP -->
When this XIC value is left unspecified,
When this <acronym>XIC</acronym> value is left unspecified,
the input method will use the client window as the default focus window.
</para>
</sect3>
@ -7488,7 +7488,7 @@ the resources will not be fully specified.
</para>
<para>
<!-- .LP -->
It is not intended that values that can be set as XIC values be
It is not intended that values that can be set as <acronym>XIC</acronym> values be
set as resources.
</para>
</sect3>
@ -7598,7 +7598,7 @@ will filter any events that it uses to initiate the conversion.
</para>
<para>
<!-- .LP -->
Because this XIC value is optional, a client should call
Because this <acronym>XIC</acronym> value is optional, a client should call
<function>XGetIMValues</function>
with argument
<function>XNQueryICValuesList</function>
@ -7638,7 +7638,7 @@ reconversion, or transliteration conversion on it.
</para>
<para>
<!-- .LP -->
Because this XIC value is optional, a client should call
Because this <acronym>XIC</acronym> value is optional, a client should call
<function>XGetIMValues</function>
with argument
<function>XNQueryICValuesList</function>
@ -7697,7 +7697,7 @@ or
</para>
<para>
<!-- .LP -->
The XIC state may be set to its initial state, as specified by the
The <acronym>XIC</acronym> state may be set to its initial state, as specified by the
<function>XNPreeditState</function>
value when
<function>XCreateIC</function>
@ -7734,7 +7734,7 @@ and
<function>XwcResetIC</function>
will return to the initial
<function>XNPreeditState</function>
state of the XIC.
state of the <acronym>XIC</acronym>.
</para>
<para>
<!-- .LP -->
@ -7744,7 +7744,7 @@ is set, then
<function>XmbResetIC</function>
and
<function>XwcResetIC</function>
will preserve the current state of the XIC.
will preserve the current state of the <acronym>XIC</acronym>.
</para>
<para>
<!-- .LP -->
@ -7761,7 +7761,7 @@ values other than those specified above will default to
</para>
<para>
<!-- .LP -->
Because this XIC value is optional, a client should call
Because this <acronym>XIC</acronym> value is optional, a client should call
<function>XGetIMValues</function>
with argument
<function>XNQueryICValuesList</function>
@ -7780,7 +7780,7 @@ before using this argument.
<!-- .LP -->
The
<function>XNHotKey</function>
argument specifies the hot key list to the XIC.
argument specifies the hot key list to the <acronym>XIC</acronym>.
The hot key list is a pointer to the structure of type
<function>XIMHotKeyTriggers ,</function>
which specifies the key events that must be received
@ -7793,7 +7793,7 @@ to
</para>
<para>
<!-- .LP -->
Because this XIC value is optional, a client should call
Because this <acronym>XIC</acronym> value is optional, a client should call
<function>XGetIMValues</function>
with argument
<function>XNQueryICValuesList</function>
@ -8052,7 +8052,7 @@ set to
<function>XIMPreeditPosition .</function>
When specified to any input method other than
<function>XIMPreeditPosition ,</function>
this XIC value is ignored.
this <acronym>XIC</acronym> value is ignored.
</para>
<para>
<!-- .LP -->
@ -8295,7 +8295,7 @@ and
</para>
<para>
<!-- .LP -->
Because this XIC value is optional, a client should call
Because this <acronym>XIC</acronym> value is optional, a client should call
<function>XGetIMValues</function>
with argument
<function>XNQueryICValuesList</function>
@ -8385,7 +8385,7 @@ typedef struct _XIMPreeditStateNotifyCallbackStruct {
</para>
<para>
<!-- .LP -->
Because this XIC value is optional, a client should call
Because this <acronym>XIC</acronym> value is optional, a client should call
<function>XGetIMValues</function>
with argument
<function>XNQueryICValuesList</function>
@ -8510,7 +8510,7 @@ may cause unexpected results.
<!-- .XE -->
<para>
<!-- .LP -->
XIM callbacks are procedures defined by clients or text drawing packages
<acronym>XIM</acronym> callbacks are procedures defined by clients or text drawing packages
that are to be called from the input method when selected events occur.
Most clients will use a text editing package or a toolkit
and, hence, will not need to define such callbacks.
@ -9173,7 +9173,7 @@ says to replace 3 characters beginning at character position 1 with the
string in the
<function>XIMText</function>
structure.
Hence, BCD would be replaced by the value in the structure.
Hence, <acronym>BCD</acronym> would be replaced by the value in the structure.
</para>
</listitem>
<listitem>
@ -9503,8 +9503,8 @@ structure is defined as follows:
<!-- .ta .5i 2.5i -->
typedef enum {
XIMIsInvisible, /* Disable caret feedback */
XIMIsPrimary, /* UI defined caret feedback */
XIMIsSecondary, /* UI defined caret feedback */
XIMIsPrimary, /* <acronym>UI</acronym> defined caret feedback */
XIMIsSecondary, /* <acronym>UI</acronym> defined caret feedback */
} XIMCaretStyle;
</literallayout>
</para>

36
specs/libX11/CH14.xml
View file

@ -1,14 +1,14 @@
<chapter id="inter_client_communication_functions">
<title>Inter-Client Communication Functions</title>
<para>
The Inter-Client Communication Conventions Manual, hereafter referred to as the ICCCM,
The Inter-Client Communication Conventions Manual, hereafter referred to as the <acronym>ICCCM</acronym>,
details the X Consortium approved conventions that govern inter-client communications. These
conventions ensure peer-to-peer client cooperation in the use of selections, cut buffers, and shared
resources as well as client cooperation with window and session managers. For further informa-
tion, see the Inter-Client Communication Conventions Manual.
</para>
<para>
Xlib provides a number of standard properties and programming interfaces that are ICCCM com-
Xlib provides a number of standard properties and programming interfaces that are <acronym>ICCCM</acronym> com-
pliant. The predefined atoms for some of these properties are defined in the &lt;X11/Xatom.h&gt;
header file, where to avoid name conflicts with user symbols their #define name has an XA_ pre-
fix. For further information about atoms and properties, see section 4.3.
@ -2259,7 +2259,7 @@ header file.
The size of the
<function>XSizeHints</function>
structure may grow in future releases, as new components are
added to support new ICCCM features.
added to support new <acronym>ICCCM</acronym> features.
Passing statically allocated instances of this structure into
Xlib may result in memory corruption when running against a
future release of the library.
@ -2511,7 +2511,7 @@ The
function returns the size hints stored in the WM_NORMAL_HINTS property
on the specified window.
If the property is of type WM_SIZE_HINTS, is of format 32,
and is long enough to contain either an old (pre-ICCCM)
and is long enough to contain either an old (pre-<acronym>ICCCM</acronym>)
or new size hints structure,
<function>XGetWMNormalHints</function>
sets the various fields of the
@ -2525,7 +2525,7 @@ Otherwise, it returns a zero status.
<!-- .LP -->
If
<function>XGetWMNormalHints</function>
returns successfully and a pre-ICCCM size hints property is read,
returns successfully and a pre-<acronym>ICCCM</acronym> size hints property is read,
the supplied_return argument will contain the following bits:
</para>
<para>
@ -2724,7 +2724,7 @@ The
function returns the size hints stored in the specified property
on the named window.
If the property is of type WM_SIZE_HINTS, is of format 32,
and is long enough to contain either an old (pre-ICCCM)
and is long enough to contain either an old (pre-<acronym>ICCCM</acronym>)
or new size hints structure,
<function>XGetWMSizeHints</function>
sets the various fields of the
@ -2743,7 +2743,7 @@ function.
<!-- .LP -->
If
<function>XGetWMSizeHints</function>
returns successfully and a pre-ICCCM size hints property is read,
returns successfully and a pre-<acronym>ICCCM</acronym> size hints property is read,
the supplied_return argument will contain the following bits:
</para>
<para>
@ -3953,7 +3953,7 @@ is substituted for res_name.
It is assumed that the supplied class_hints.res_name and argv,
the RESOURCE_NAME environment variable, and the hostname of the machine
are in the encoding of the locale announced for the LC_CTYPE category
(on POSIX-compliant systems, the LC_CTYPE, else LANG environment variable).
(on <acronym>POSIX</acronym>-compliant systems, the LC_CTYPE, else LANG environment variable).
The corresponding WM_CLASS, WM_COMMAND, and WM_CLIENT_MACHINE properties
are typed according to the local host locale announcer.
No encoding conversion is performed prior to storage in the properties.
@ -4519,12 +4519,12 @@ to draw a smoothly shaded sphere.
At each pixel in the image of the sphere,
the program computes the intensity and color of light
reflected back to the viewer.
The result of each computation is a triple of red, green, and blue (RGB)
The result of each computation is a triple of red, green, and blue (<acronym>RGB</acronym>)
coefficients in the range 0.0 to 1.0.
To draw the sphere, the program needs a colormap that provides a
large range of uniformly distributed colors.
The colormap should be arranged so that the program can
convert its RGB triples into pixel values very quickly,
convert its <acronym>RGB</acronym> triples into pixel values very quickly,
because drawing the entire sphere requires many such
conversions.
</para>
@ -4788,11 +4788,11 @@ This atom names a property.
The value of the property is an array of
<function>XStandardColormap</function>
structures.
Each entry in the array describes an RGB subset of the default color
Each entry in the array describes an <acronym>RGB</acronym> subset of the default color
map for the Visual specified by visual_id.
</para>
<para>
Some applications only need a few RGB colors and
Some applications only need a few <acronym>RGB</acronym> colors and
may be able to allocate them from the system default colormap.
This is the ideal situation because the fewer colormaps that are
active in the system the more applications are displayed
@ -4816,7 +4816,7 @@ This atom names a property. The value of the property is an
<function>XStandardColormap .</function>
</para>
<para>
The property defines the best RGB colormap available on
The property defines the best <acronym>RGB</acronym> colormap available on
the screen.
(Of course, this is a subjective evaluation.)
Many image processing and three-dimensional applications need to
@ -4974,14 +4974,14 @@ Specifies the property name.
<!-- .eM -->
The
<function>XSetRGBColormaps </function>
function replaces the RGB colormap definition in the specified property
function replaces the <acronym>RGB</acronym> colormap definition in the specified property
on the named window.
If the property does not already exist,
<function>XSetRGBColormaps</function>
sets the RGB colormap definition in the specified property
sets the <acronym>RGB</acronym> colormap definition in the specified property
on the named window.
The property is stored with a type of RGB_COLOR_MAP and a format of 32.
Note that it is the caller's responsibility to honor the ICCCM
Note that it is the caller's responsibility to honor the <acronym>ICCCM</acronym>
restriction that only RGB_DEFAULT_MAP contain more than one definition.
</para>
<para>
@ -5154,7 +5154,7 @@ Specifies the property name.
<!-- .eM -->
The
<function>XGetRGBColormaps</function>
function returns the RGB colormap definitions stored
function returns the <acronym>RGB</acronym> colormap definitions stored
in the specified property on the named window.
If the property exists, is of type RGB_COLOR_MAP, is of format 32,
and is long enough to contain a colormap definition,
@ -5171,7 +5171,7 @@ Otherwise,
none of the fields are set, and
<function>XGetRGBColormaps</function>
returns a zero status.
Note that it is the caller's responsibility to honor the ICCCM
Note that it is the caller's responsibility to honor the <acronym>ICCCM</acronym>
restriction that only RGB_DEFAULT_MAP contain more than one definition.
</para>
<para>

2
specs/libX11/credits.xml
View file

@ -99,7 +99,7 @@ Release 4
<para>
Our thanks go to Jim Fulton (MIT X Consortium) for designing and
specifying the new Xlib functions for Inter-Client Communication
Conventions (ICCCM) support.
Conventions (<acronym>ICCCM</acronym>) support.
</para>
<para>
We also thank Al Mento of Digital for his continued effort in

58
specs/libX11/glossary.xml
View file

@ -87,13 +87,13 @@ The
<function>CharSetRegistry</function>
and
<function>CharSetEncoding</function>
fields of an XLFD name identify the charset of the font.
A base font name may be a full XLFD name, with all fourteen '-' delimiters,
or an abbreviated XLFD name containing only the first 12 fields of an XLFD name,
fields of an <acronym>XLFD</acronym> name identify the charset of the font.
A base font name may be a full <acronym>XLFD</acronym> name, with all fourteen '-' delimiters,
or an abbreviated <acronym>XLFD</acronym> name containing only the first 12 fields of an <acronym>XLFD</acronym> name,
up to but not including
<function>CharSetRegistry ,</function>
with or without the thirteenth '-', or a non-XLFD name.
Any XLFD fields may contain wild cards.
with or without the thirteenth '-', or a non-<acronym>XLFD</acronym> name.
Any <acronym>XLFD</acronym> fields may contain wild cards.
</para>
<para>
When creating an
@ -279,11 +279,11 @@ windows for further information about valid window types.
<indexterm significance="preferred"><primary>Client</primary></indexterm>
<para>
An application program connects to the window system server by some
interprocess communication (IPC) path, such as a TCP connection or a
interprocess communication (<acronym>IPC</acronym>) path, such as a <acronym>TCP</acronym> connection or a
shared memory buffer.
This program is referred to as a client of the window system server.
More precisely,
the client is the IPC path itself.
the client is the <acronym>IPC</acronym> path itself.
A program with multiple paths open to the server is viewed as
multiple clients by the protocol.
Resource lifetimes are controlled by
@ -347,7 +347,7 @@ The coded representation of a single character in a coded character set.
<para>
A colormap consists of a set of entries defining color values.
The colormap associated with a window is used to display the contents of
the window; each pixel value indexes the colormap to produce an RGB value
the window; each pixel value indexes the colormap to produce an <acronym>RGB</acronym> value
that drives the guns of a monitor.
Depending on hardware limitations,
one or more colormaps can be installed at one time so
@ -361,7 +361,7 @@ that windows associated with those maps display with true colors.
<glossdef>
<indexterm significance="preferred"><primary>Connection</primary></indexterm>
<para>
The IPC path between the server and client program is known as a connection.
The <acronym>IPC</acronym> path between the server and client program is known as a connection.
A client program typically (but not necessarily) has one
connection to the server over which requests and events are sent.
<!-- .KE -->
@ -450,7 +450,7 @@ separate subfields for indexing.
The first subfield indexes an array to produce red intensity values.
The second subfield indexes a second array to produce blue intensity values.
The third subfield indexes a third array to produce green intensity values.
The RGB (red, green, and blue) values in the colormap entry can be
The <acronym>RGB</acronym> (red, green, and blue) values in the colormap entry can be
changed dynamically.
<!-- .KE -->
</para>
@ -508,7 +508,7 @@ which appears as: the
<function>CharSetRegistry</function>
and
<function>CharSetEncoding</function>
components of an XLFD
components of an <acronym>XLFD</acronym>
name; the name of a charset of the locale for which a font could not be
found; or an atom which identifies the encoding of a text property or
which names an encoding for a text selection target type.
@ -1220,9 +1220,9 @@ which tracks whatever pointing device is attached as the pointer.
</glossdef>
</glossentry>
<glossentry>
<glossterm>POSIX</glossterm>
<glossterm><acronym>POSIX</acronym></glossterm>
<glossdef>
<indexterm significance="preferred"><primary>POSIX</primary></indexterm>
<indexterm significance="preferred"><primary><acronym>POSIX</acronym></primary></indexterm>
<para>
Portable Operating System Interface, ISO/IEC 9945-1 (IEEE Std 1003.1).
<!-- .KE -->
@ -1230,11 +1230,11 @@ Portable Operating System Interface, ISO/IEC 9945-1 (IEEE Std 1003.1).
</glossdef>
</glossentry>
<glossentry>
<glossterm>POSIX Portable Filename Character Set</glossterm>
<glossterm><acronym>POSIX</acronym> Portable Filename Character Set</glossterm>
<glossdef>
<indexterm significance="preferred"><primary>POSIX Portable Filename Character Set</primary></indexterm>
<indexterm significance="preferred"><primary><acronym>POSIX</acronym> Portable Filename Character Set</primary></indexterm>
<para>
The set of 65 characters which can be used in naming files on a POSIX-compliant
The set of 65 characters which can be used in naming files on a <acronym>POSIX</acronym>-compliant
host that are correctly processed in all locales.
The set is:
</para>
@ -1279,9 +1279,9 @@ been defined for the window.
<para>
<function>PseudoColor</function>
is a class of colormap in which a pixel value indexes the colormap entry to
produce an independent RGB value;
that is, the colormap is viewed as an array of triples (RGB values).
The RGB values can be changed dynamically.
produce an independent <acronym>RGB</acronym> value;
that is, the colormap is viewed as an array of triples (<acronym>RGB</acronym> values).
The <acronym>RGB</acronym> values can be changed dynamically.
<!-- .KE -->
</para>
</glossdef>
@ -1358,11 +1358,11 @@ connection over which the resource was created.
</glossdef>
</glossentry>
<glossentry>
<glossterm>RGB values</glossterm>
<glossterm><acronym>RGB</acronym> values</glossterm>
<glossdef>
<indexterm significance="preferred"><primary>RGB values</primary></indexterm>
<indexterm significance="preferred"><primary><acronym>RGB</acronym> values</primary></indexterm>
<para>
RGB values are the red, green, and blue intensity values that are used
<acronym>RGB</acronym> values are the red, green, and blue intensity values that are used
to define a color.
These values are always represented as 16-bit, unsigned numbers, with 0
the minimum intensity and 65535 the maximum intensity.
@ -1496,7 +1496,7 @@ The protocol does not constrain the semantics.
<para>
The server, which is also referred to as the X server,
provides the basic windowing mechanism.
It handles IPC connections from clients,
It handles <acronym>IPC</acronym> connections from clients,
multiplexes graphics requests onto the screens,
and demultiplexes input back to the appropriate clients.
<!-- .KE -->
@ -1589,7 +1589,7 @@ this means use of at most single shifts, not locking shifts.
<function>StaticColor </function>
can be viewed as a degenerate case of
<function>PseudoColor</function>
in which the RGB values are predefined and read-only.
in which the <acronym>RGB</acronym> values are predefined and read-only.
<!-- .KE -->
</para>
</glossdef>
@ -1698,9 +1698,9 @@ This value is reserved for use in requests to represent the current server time.
<function>TrueColor</function>
can be viewed as a degenerate case of
<function>DirectColor</function>
in which the subfields in the pixel value directly encode the corresponding RGB
in which the subfields in the pixel value directly encode the corresponding <acronym>RGB</acronym>
values.
That is, the colormap has predefined read-only RGB values.
That is, the colormap has predefined read-only <acronym>RGB</acronym> values.
The values are typically linear or near-linear increasing ramps.
<!-- .KE -->
</para>
@ -1819,9 +1819,9 @@ see the Host Portable Character Encoding.
</glossdef>
</glossentry>
<glossentry>
<glossterm>XLFD</glossterm>
<glossterm><acronym>XLFD</acronym></glossterm>
<glossdef>
<indexterm significance="preferred"><primary>XLFD</primary></indexterm>
<indexterm significance="preferred"><primary><acronym>XLFD</acronym></primary></indexterm>
<para>
The X Logical Font Description Conventions that define a standard syntax
for structured font names.
@ -1876,7 +1876,7 @@ character sets - Part 1: Latin alphabet No. 1.
<biblioentry>
<title>
POSIX: Information Technology - Portable Operating System Interface (POSIX) -
<acronym>POSIX</acronym>: Information Technology - Portable Operating System Interface (<acronym>POSIX</acronym>) -
Part 1: System Application Program Interface (API) [C Language],
ISO/IEC 9945-1.
</title>