~ubuntu-branches/ubuntu/lucid/libx11/lucid

« back to all changes in this revision

Viewing changes to specs/libX11/glossary

  • Committer: Bazaar Package Importer
  • Author(s): Timo Aaltonen
  • Date: 2009-12-04 11:43:54 UTC
  • mfrom: (1.1.10 upstream) (2.1.5 sid)
  • Revision ID: james.westby@ubuntu.com-20091204114354-0lik4mbb1bv1a8nw
Tags: 2:1.3.2-1ubuntu1
* Merge from Debian unstable, remaining changes:
  - Add 100_latin_locale_alias.diff (LP 379785)

Show diffs side-by-side

added added

removed removed

Lines of Context:
 
1
\&
 
2
.sp 1
 
3
.ce 1
 
4
\s+1\fBGlossary\fP\s-1
 
5
.sp 2
 
6
.na
 
7
.LP
 
8
.XS
 
9
Glossary
 
10
.XE
 
11
.KS
 
12
\fBAccess control list\fP
 
13
.IN "Access control list" "" "@DEF@"
 
14
.IP
 
15
X maintains a list of hosts from which client programs can be run.  
 
16
By default, 
 
17
only programs on the local host and hosts specified in an initial list read
 
18
by the server can use the display.
 
19
This access control list can be changed by clients on the local host.  
 
20
Some server implementations can also implement other authorization mechanisms
 
21
in addition to or in place of this mechanism.
 
22
The action of this mechanism can be conditional based on the authorization 
 
23
protocol name and data received by the server at connection setup. 
 
24
.KE
 
25
.LP
 
26
.KS
 
27
\fBActive grab\fP
 
28
.IN "Active grab" "" "@DEF@"
 
29
.IP
 
30
A grab is active when the pointer or keyboard is actually owned by the 
 
31
single grabbing client.
 
32
.KE
 
33
.LP
 
34
.KS
 
35
\fBAncestors\fP
 
36
.IN "Ancestors" "" "@DEF@"
 
37
.IP
 
38
If W is an inferior of A, then A is an ancestor of W.
 
39
.KE
 
40
.LP
 
41
.KS
 
42
\fBAtom\fP
 
43
.IN "Atom" "" "@DEF@"
 
44
.IP
 
45
An atom is a unique ID corresponding to a string name.
 
46
Atoms are used to identify properties, types, and selections.
 
47
.KE
 
48
.LP
 
49
.KS
 
50
\fBBackground\fP
 
51
.IN "Background" "" "@DEF@"
 
52
.IP
 
53
An
 
54
.PN InputOutput
 
55
window can have a background, which is defined as a pixmap.
 
56
When regions of the window have their contents lost 
 
57
or invalidated,
 
58
the server automatically tiles those regions with the background.
 
59
.KE
 
60
.LP
 
61
.KS
 
62
\fBBacking store\fP
 
63
.IN "Backing store" "" "@DEF@"
 
64
.IP
 
65
When a server maintains the contents of a window, 
 
66
the pixels saved off-screen are known as a backing store.
 
67
.KE
 
68
.LP
 
69
.KS
 
70
\fBBase font name\fP
 
71
.IN "Base font name" "" "@DEF@"
 
72
.IP
 
73
A font name used to select a family of fonts whose members may be encoded 
 
74
in various charsets.
 
75
The
 
76
.PN CharSetRegistry
 
77
and 
 
78
.PN CharSetEncoding
 
79
fields of an XLFD name identify the charset of the font.
 
80
A base font name may be a full XLFD name, with all fourteen '-' delimiters, 
 
81
or an abbreviated XLFD name containing only the first 12 fields of an XLFD name,
 
82
up to but not including 
 
83
.PN CharSetRegistry ,
 
84
with or without the thirteenth '-', or a non-XLFD name.
 
85
Any XLFD fields may contain wild cards.
 
86
.IP
 
87
When creating an 
 
88
.PN XFontSet ,
 
89
Xlib accepts from the client a list of one or more base font names 
 
90
which select one or more font families.
 
91
They are combined with charset names obtained from the encoding of the locale
 
92
to load the fonts required to render text.
 
93
.KE
 
94
.LP
 
95
.KS
 
96
\fBBit gravity\fP
 
97
.IN "Bit" "gravity" "@DEF@"
 
98
.IP
 
99
When a window is resized, 
 
100
the contents of the window are not necessarily discarded.  
 
101
It is possible to request that the server relocate the previous contents 
 
102
to some region of the window (though no guarantees are made).
 
103
This attraction of window contents for some location of
 
104
a window is known as bit gravity.
 
105
.KE
 
106
.LP
 
107
.KS
 
108
\fBBit plane\fP
 
109
.IN "Bit" "plane" "@DEF@"
 
110
.IP
 
111
When a pixmap or window is thought of as a stack of bitmaps,
 
112
each bitmap is called a bit plane or plane.
 
113
.KE
 
114
.LP
 
115
.KS
 
116
\fBBitmap\fP
 
117
.IN "Bitmap" "" "@DEF@"
 
118
.IP
 
119
A bitmap is a pixmap of depth one.
 
120
.KE
 
121
.LP
 
122
.KS
 
123
\fBBorder\fP
 
124
.IN "Border" "" "@DEF@"
 
125
.IP
 
126
An
 
127
.PN InputOutput
 
128
window can have a border of equal thickness on all four sides of the window.
 
129
The contents of the border are defined by a pixmap,
 
130
and the server automatically maintains the contents of the border.
 
131
Exposure events are never generated for border regions.
 
132
.KE
 
133
.LP
 
134
.KS
 
135
\fBButton grabbing\fP
 
136
.IN "Button" "grabbing" "@DEF@"
 
137
.IP
 
138
Buttons on the pointer can be passively grabbed by a client.
 
139
When the button is pressed, 
 
140
the pointer is then actively grabbed by the client.
 
141
.KE
 
142
.LP
 
143
.KS
 
144
\fBByte order\fP
 
145
.IN "Byte" "order" "@DEF@"
 
146
.IP
 
147
For image (pixmap/bitmap) data, 
 
148
the server defines the byte order,
 
149
and clients with different native byte ordering must swap bytes as
 
150
necessary.  
 
151
For all other parts of the protocol, 
 
152
the client defines the byte order,
 
153
and the server swaps bytes as necessary.
 
154
.KE
 
155
.LP
 
156
.KS
 
157
\fBCharacter\fP
 
158
.IN "Character" "" "@DEF@"
 
159
.IP
 
160
A member of a set of elements used for the organization,
 
161
control, or representation of text (ISO2022, as adapted by XPG3).
 
162
Note that in ISO2022 terms, a character is not bound to a coded value 
 
163
until it is identified as part of a coded character set.
 
164
.KE
 
165
.LP
 
166
.KS
 
167
\fBCharacter glyph\fP
 
168
.IN "Character glyph" "" "@DEF@"
 
169
.IP
 
170
The abstract graphical symbol for a character.
 
171
Character glyphs may or may not map one-to-one to font glyphs,
 
172
and may be context-dependent, varying with the adjacent characters.
 
173
Multiple characters may map to a single character glyph.
 
174
.KE
 
175
.LP
 
176
.KS
 
177
\fBCharacter set\fP
 
178
.IN "Character set" "" "@DEF@"
 
179
.IP
 
180
A collection of characters.
 
181
.KE
 
182
.LP
 
183
.KS
 
184
\fBCharset\fP
 
185
.IN "Charset" "" "@DEF@"
 
186
.IP
 
187
An encoding with a uniform, state-independent mapping from characters 
 
188
to codepoints.
 
189
A coded character set.
 
190
.IP
 
191
For display in X,
 
192
there can be a direct mapping from a charset to one font,
 
193
if the width of all characters in the charset is either one or two bytes.
 
194
A text string encoded in an encoding such as Shift-JIS cannot be passed
 
195
directly to the X server, because the text imaging requests accept only
 
196
single-width charsets (either 8 or 16 bits).
 
197
Charsets which meet these restrictions can serve as ``font charsets''.
 
198
Font charsets strictly speaking map font indices to font glyphs,
 
199
not characters to character glyphs.
 
200
.IP
 
201
Note that a single font charset is sometimes used as the encoding of a locale,
 
202
for example, ISO8859-1.
 
203
.KE
 
204
.LP
 
205
.KS
 
206
\fBChildren\fP
 
207
.IN "Children" "" "@DEF@"
 
208
.IP
 
209
The children of a window are its first-level subwindows.
 
210
.KE
 
211
.LP
 
212
.KS
 
213
\fBClass\fP
 
214
.IN "Class" "" "@DEF@"
 
215
.IP
 
216
Windows can be of different classes or types.
 
217
See the entries for
 
218
.PN InputOnly
 
219
and
 
220
.PN InputOutput
 
221
windows for further information about valid window types.
 
222
.KE
 
223
.LP
 
224
.KS
 
225
\fBClient\fP
 
226
.IN "Client" "" "@DEF@"
 
227
.IP
 
228
An application program connects to the window system server by some
 
229
interprocess communication (IPC) path, such as a TCP connection or a
 
230
shared memory buffer.  
 
231
This program is referred to as a client of the window system server.  
 
232
More precisely, 
 
233
the client is the IPC path itself. 
 
234
A program with multiple paths open to the server is viewed as
 
235
multiple clients by the protocol.  
 
236
Resource lifetimes are controlled by
 
237
connection lifetimes, not by program lifetimes.
 
238
.KE
 
239
.LP
 
240
.KS
 
241
\fBClipping region\fP
 
242
.IN "Clipping region" "" "@DEF@"
 
243
.IP
 
244
In a graphics context, 
 
245
a bitmap or list of rectangles can be specified
 
246
to restrict output to a particular region of the window.  
 
247
The image defined by the bitmap or rectangles is called a clipping region.
 
248
.KE
 
249
.LP
 
250
.KS
 
251
\fBCoded character\fP
 
252
.IN "Coded character" "" "@DEF@"
 
253
.IP
 
254
A character bound to a codepoint.
 
255
.KE
 
256
.LP
 
257
.KS
 
258
\fBCoded character set\fP
 
259
.IN "Coded character set" "" "@DEF@"
 
260
.IP
 
261
A set of unambiguous rules that establishes a character set 
 
262
and the one-to-one relationship between each character of the set 
 
263
and its bit representation.
 
264
(ISO2022, as adapted by XPG3)
 
265
A definition of a one-to-one mapping of a set of characters to a set of
 
266
codepoints.
 
267
.KE
 
268
.LP
 
269
.KS
 
270
\fBCodepoint\fP
 
271
.IN "Codepoint" "" "@DEF@"
 
272
.IP
 
273
The coded representation of a single character in a coded character set.
 
274
.KE
 
275
.LP
 
276
.KS
 
277
\fBColormap\fP
 
278
.IN "Colormap" "" "@DEF@"
 
279
.IP
 
280
A colormap consists of a set of entries defining color values.
 
281
The colormap associated with a window is used to display the contents of
 
282
the window; each pixel value indexes the colormap to produce an RGB value
 
283
that drives the guns of a monitor.
 
284
Depending on hardware limitations, 
 
285
one or more colormaps can be installed at one time so
 
286
that windows associated with those maps display with true colors.
 
287
.KE
 
288
.LP
 
289
.KS
 
290
\fBConnection\fP
 
291
.IN "Connection" "" "@DEF@"
 
292
.IP
 
293
The IPC path between the server and client program is known as a connection.
 
294
A client program typically (but not necessarily) has one
 
295
connection to the server over which requests and events are sent.
 
296
.KE
 
297
.LP
 
298
.KS
 
299
\fBContainment\fP
 
300
.IN "Containment" "" "@DEF@"
 
301
.IP
 
302
A window contains the pointer if the window is viewable and the
 
303
hotspot of the cursor is within a visible region of the window or a
 
304
visible region of one of its inferiors.  
 
305
The border of the window is included as part of the window for containment.  
 
306
The pointer is in a window if the window contains the pointer
 
307
but no inferior contains the pointer.
 
308
.KE
 
309
.LP
 
310
.KS
 
311
\fBCoordinate system\fP
 
312
.IN "Coordinate system" "" "@DEF@"
 
313
.IP
 
314
The coordinate system has X horizontal and Y vertical, 
 
315
with the origin [0, 0] at the upper left.  
 
316
Coordinates are integral and coincide with pixel centers.
 
317
Each window and pixmap has its own coordinate system.  
 
318
For a window, 
 
319
the origin is inside the border at the inside upper-left corner.
 
320
.KE
 
321
.LP
 
322
.KS
 
323
\fBCursor\fP
 
324
.IN "Cursor" "" "@DEF@"
 
325
.IP
 
326
A cursor is the visible shape of the pointer on a screen.  
 
327
It consists of a hotspot, a source bitmap, a shape bitmap, 
 
328
and a pair of colors.  
 
329
The cursor defined for a window controls the visible
 
330
appearance when the pointer is in that window.
 
331
.KE
 
332
.LP
 
333
.KS
 
334
\fBDepth\fP
 
335
.IN "Depth" "" "@DEF@"
 
336
.IP
 
337
The depth of a window or pixmap is the number of bits per pixel it has.
 
338
The depth of a graphics context is the depth of the drawables it can be
 
339
used in conjunction with graphics output.
 
340
.KE
 
341
.LP
 
342
.KS
 
343
\fBDevice\fP
 
344
.IN "Device" "" "@DEF@"
 
345
.IP
 
346
Keyboards, mice, tablets, track-balls, button boxes, and so on are all
 
347
collectively known as input devices.
 
348
Pointers can have one or more buttons 
 
349
(the most common number is three).
 
350
The core protocol only deals with two devices: the keyboard 
 
351
and the pointer.
 
352
.KE
 
353
.LP
 
354
.KS
 
355
\fBDirectColor\fP
 
356
.IN "DirectColor" "" "@DEF@"
 
357
.IP
 
358
.PN DirectColor
 
359
is a class of colormap in which a pixel value is decomposed into three
 
360
separate subfields for indexing.
 
361
The first subfield indexes an array to produce red intensity values. 
 
362
The second subfield indexes a second array to produce blue intensity values.
 
363
The third subfield indexes a third array to produce green intensity values.
 
364
The RGB (red, green, and blue) values in the colormap entry can be 
 
365
changed dynamically.
 
366
.KE
 
367
.LP
 
368
.KS
 
369
\fBDisplay\fP
 
370
.IN "Display" "" "@DEF@"
 
371
.IP
 
372
A server, together with its screens and input devices, is called a display.
 
373
The Xlib
 
374
.PN Display
 
375
.IN "Display" "structure"
 
376
structure contains all information about the particular display and its screens
 
377
as well as the state that Xlib needs to communicate with the display over a
 
378
particular connection.
 
379
.KE
 
380
.LP
 
381
.KS
 
382
\fBDrawable\fP
 
383
.IN "Drawable" "" "@DEF@"
 
384
.IP
 
385
Both windows and pixmaps can be used as sources and destinations 
 
386
in graphics operations.  
 
387
These windows and pixmaps are collectively known as drawables.
 
388
However, an 
 
389
.PN InputOnly 
 
390
window cannot be used as a source or destination in a
 
391
graphics operation.
 
392
.KE
 
393
.LP
 
394
.KS
 
395
\fBEncoding\fP
 
396
.IN "Encoding" "" "@DEF@"
 
397
.IP
 
398
A set of unambiguous rules that establishes a character set 
 
399
and a relationship between the characters and their representations.
 
400
The character set does not have to be fixed to a finite pre-defined set of
 
401
characters.
 
402
The representations do not have to be of uniform length.
 
403
Examples are an ISO2022 graphic set, a state-independent 
 
404
or state-dependent combination of graphic sets, possibly including control
 
405
sets, and the X Compound Text encoding.
 
406
.IP
 
407
In X, encodings are identified by a string
 
408
which appears as: the
 
409
.PN CharSetRegistry
 
410
and
 
411
.PN CharSetEncoding
 
412
components of an XLFD
 
413
name; the name of a charset of the locale for which a font could not be
 
414
found; or an atom which identifies the encoding of a text property or
 
415
which names an encoding for a text selection target type.
 
416
Encoding names should be composed of characters from the X Portable 
 
417
Character Set.
 
418
.KE
 
419
.LP
 
420
.KS
 
421
\fBEscapement\fP
 
422
.IN "Escapement" "" "@DEF@"
 
423
.IP
 
424
The escapement of a string is the distance in pixels in the
 
425
primary draw direction from the drawing origin to the origin of the next
 
426
character (that is, the one following the given string) to be drawn.
 
427
.KE
 
428
.LP
 
429
.KS
 
430
\fBEvent\fP
 
431
.IN "Event" "" "@DEF@"
 
432
.IP
 
433
Clients are informed of information asynchronously by means of events.
 
434
These events can be either asynchronously generated from devices or
 
435
generated as side effects of client requests.  
 
436
Events are grouped into types. 
 
437
The server never sends an event to a client unless the
 
438
client has specifically asked to be informed of that type of event.
 
439
However, clients can force events to be sent to other clients.  
 
440
Events are typically reported relative to a window.
 
441
.KE
 
442
.LP
 
443
.KS
 
444
\fBEvent mask\fP
 
445
.IN "Event" "mask" "@DEF@"
 
446
.IP
 
447
Events are requested relative to a window.  
 
448
The set of event types a client requests relative to a window is described 
 
449
by using an event mask.
 
450
.KE
 
451
.LP
 
452
.KS
 
453
\fBEvent propagation\fP
 
454
.IN "Event" "propagation" "@DEF@"
 
455
.IP
 
456
Device-related events propagate from the source window to ancestor
 
457
windows until some client has expressed interest in handling that type
 
458
of event or until the event is discarded explicitly.
 
459
.KE
 
460
.LP
 
461
.KS
 
462
\fBEvent source\fP
 
463
.IN "Event" "source" "@DEF@"
 
464
.IP
 
465
The deepest viewable window that the pointer is in is called
 
466
the source of a device-related event.
 
467
.KE
 
468
.LP
 
469
.KS
 
470
\fBEvent synchronization\fP
 
471
.IN "Event" "synchronization" "@DEF@"
 
472
.IP
 
473
There are certain race conditions possible when demultiplexing device
 
474
events to clients (in particular, deciding where pointer and keyboard
 
475
events should be sent when in the middle of window management
 
476
operations).  
 
477
The event synchronization mechanism allows synchronous processing of 
 
478
device events.
 
479
.KE
 
480
.LP
 
481
.KS
 
482
\fBExposure event\fP
 
483
.IN "Event" "Exposure" "@DEF@"
 
484
.IP
 
485
Servers do not guarantee to preserve the contents of windows when
 
486
windows are obscured or reconfigured.  
 
487
Exposure events are sent to clients to inform them when contents of regions
 
488
of windows have been lost.
 
489
.KE
 
490
.LP
 
491
.KS
 
492
\fBExtension\fP
 
493
.IN "Extension" "" "@DEF@"
 
494
.IP
 
495
Named extensions to the core protocol can be defined to extend the system.  
 
496
Extensions to output requests, resources, and event types are all possible
 
497
and expected.
 
498
.KE
 
499
.LP
 
500
.KS
 
501
\fBFont\fP
 
502
.IN "Font" "" "@DEF@"
 
503
.IP
 
504
A font is an array of glyphs (typically characters).  
 
505
The protocol does no translation or interpretation of character sets.  
 
506
The client simply indicates values used to index the glyph array.  
 
507
A font contains additional metric information to determine interglyph 
 
508
and interline spacing.
 
509
.KE
 
510
.LP
 
511
.KS
 
512
\fBFont glyph\fP
 
513
.IN "Font glyph" "" "@DEF@"
 
514
.IP
 
515
The abstract graphical symbol for an index into a font.
 
516
.KE
 
517
.LP
 
518
.KS
 
519
\fBFrozen events\fP
 
520
.IN "Frozen events" "" "@DEF@"
 
521
.IP
 
522
Clients can freeze event processing during keyboard and pointer grabs.
 
523
.KE
 
524
.LP
 
525
.KS
 
526
\fBGC\fP
 
527
.IN "GC" "" "@DEF@"
 
528
.IP
 
529
GC is an abbreviation for graphics context.
 
530
See \fBGraphics context\fP.
 
531
.KE
 
532
.LP
 
533
.KS
 
534
\fBGlyph\fP
 
535
.IN "Glyph" "" "@DEF@"
 
536
.IP
 
537
An identified abstract graphical symbol independent of any actual image.
 
538
(ISO/IEC/DIS 9541-1)
 
539
An abstract visual representation of a graphic character,
 
540
not bound to a codepoint.
 
541
.KE
 
542
.LP
 
543
.KS
 
544
\fBGlyph image\fP
 
545
.IN "Glyph image" "" "@DEF@"
 
546
.IP
 
547
An image of a glyph, as obtained from a glyph representation displayed 
 
548
on a presentation surface.
 
549
(ISO/IEC/DIS 9541-1)
 
550
.KE
 
551
.LP
 
552
.KS
 
553
\fBGrab\fP
 
554
.IN "Grab" "" "@DEF@"
 
555
.IP
 
556
Keyboard keys, the keyboard, pointer buttons, the pointer, 
 
557
and the server can be grabbed for exclusive use by a client.  
 
558
In general, 
 
559
these facilities are not intended to be used by normal applications
 
560
but are intended for various input and window managers to implement various
 
561
styles of user interfaces.
 
562
.KE
 
563
.LP
 
564
.KS
 
565
\fBGraphics context\fP
 
566
.IN "Graphics context" "" "@DEF@"
 
567
.IP
 
568
Various information for graphics output is stored in a graphics
 
569
context (GC), such as foreground pixel, background
 
570
pixel, line width, clipping region, and so on.
 
571
A graphics context can only
 
572
be used with drawables that have the same root and the same depth as
 
573
the graphics context. 
 
574
.KE
 
575
.LP
 
576
.KS
 
577
\fBGravity\fP
 
578
.IN "Gravity" "" "@DEF@"
 
579
.IP
 
580
The contents of windows and windows themselves have a gravity,
 
581
which determines how the contents move when a window is resized.
 
582
See \fBBit gravity\fP and \fBWindow gravity\fP.
 
583
.KE
 
584
.LP
 
585
.KS
 
586
\fBGrayScale\fP
 
587
.IN "GrayScale" "" "@DEF@"
 
588
.IP
 
589
.PN GrayScale 
 
590
can be viewed as a degenerate case of 
 
591
.PN PseudoColor , 
 
592
in which the red, green, and blue values in any given colormap entry 
 
593
are equal and thus, produce shades of gray.
 
594
The gray values can be changed dynamically.
 
595
.KE
 
596
.LP
 
597
.KS
 
598
\fBHost Portable Character Encoding\fP
 
599
.IN "Host Portable Character Encoding" "" "@DEF@"
 
600
.IP
 
601
The encoding of the X Portable Character Set on the host.
 
602
The encoding itself is not defined by this standard,
 
603
but the encoding must be the same in all locales supported by Xlib on the host.
 
604
If a string is said to be in the Host Portable Character Encoding,
 
605
then it only contains characters from the X Portable Character Set,
 
606
in the host encoding.
 
607
.KE
 
608
.LP
 
609
.KS
 
610
\fBHotspot\fP
 
611
.IN "Hotspot" "" "@DEF@"
 
612
.IP
 
613
A cursor has an associated hotspot, which defines the point in the
 
614
cursor corresponding to the coordinates reported for the pointer.
 
615
.KE
 
616
.LP
 
617
.KS
 
618
\fBIdentifier\fP
 
619
.IN "Identifier" "" "@DEF@"
 
620
.IP
 
621
An identifier is a unique value associated with a resource
 
622
that clients use to name that resource.  
 
623
The identifier can be used over any connection to name the resource.
 
624
.KE
 
625
.LP
 
626
.KS
 
627
\fBInferiors\fP
 
628
.IN "Inferiors" "" "@DEF@"
 
629
.IP
 
630
The inferiors of a window are all of the subwindows nested below it:
 
631
the children, the children's children, and so on.
 
632
.KE
 
633
.LP
 
634
.KS
 
635
\fBInput focus\fP
 
636
.IN "Input" "focus" "@DEF@"
 
637
.IP
 
638
The input focus is usually a window defining the scope for processing
 
639
of keyboard input.
 
640
If a generated keyboard event usually would be reported to this window 
 
641
or one of its inferiors,
 
642
the event is reported as usual.
 
643
Otherwise, the event is reported with respect to the focus window.
 
644
The input focus also can be set such that all keyboard events are discarded
 
645
and such that the focus window is dynamically taken to be the root window
 
646
of whatever screen the pointer is on at each keyboard event.
 
647
.KE
 
648
.LP
 
649
.KS
 
650
\fBInput manager\fP
 
651
.IN "Input" "manager" "@DEF@"
 
652
.IP
 
653
Control over keyboard input is typically provided by an input manager 
 
654
client, which usually is part of a window manager.
 
655
.KE
 
656
.LP
 
657
.KS
 
658
\fBInputOnly window\fP
 
659
.IN "Window" "InputOnly" "@DEF@"
 
660
.IP
 
661
An
 
662
.PN InputOnly
 
663
window is a window that cannot be used for graphics requests.  
 
664
.PN InputOnly 
 
665
windows are invisible and are used to control such things as cursors,
 
666
input event generation, and grabbing.
 
667
.PN InputOnly 
 
668
windows cannot have 
 
669
.PN InputOutput 
 
670
windows as inferiors.
 
671
.KE
 
672
.LP
 
673
.KS
 
674
\fBInputOutput window\fP
 
675
.IN "Window" "InputOutput" "@DEF@"
 
676
.IP
 
677
An
 
678
.PN InputOutput
 
679
window is the normal kind of window that is used for both input and output.
 
680
.PN InputOutput 
 
681
windows can have both 
 
682
.PN InputOutput 
 
683
and 
 
684
.PN InputOnly 
 
685
windows as inferiors.
 
686
.KE
 
687
.LP
 
688
.KS
 
689
\fBInternationalization\fP
 
690
.IN "Internationalization" "" "@DEF@"
 
691
.IP
 
692
The process of making software adaptable to the requirements
 
693
of different native languages, local customs, and character string encodings.
 
694
Making a computer program adaptable to different locales 
 
695
without program source modifications or recompilation.
 
696
.KE
 
697
.LP
 
698
.KS
 
699
\fBISO2022\fP
 
700
.IN "ISO2022" "" "@DEF@"
 
701
.IP
 
702
ISO standard for code extension techniques for 7-bit and 8-bit coded 
 
703
character sets.
 
704
.KE
 
705
.LP
 
706
.KS
 
707
\fBKey grabbing\fP
 
708
.IN "Key" "grabbing" "@DEF@"
 
709
.IP
 
710
Keys on the keyboard can be passively grabbed by a client.  
 
711
When the key is pressed, 
 
712
the keyboard is then actively grabbed by the client.
 
713
.KE
 
714
.LP
 
715
.KS
 
716
\fBKeyboard grabbing\fP
 
717
.IN "Keyboard" "grabbing" "@DEF@"
 
718
.IP
 
719
A client can actively grab control of the keyboard, and key events
 
720
will be sent to that client rather than the client the events would
 
721
normally have been sent to.
 
722
.KE
 
723
.LP
 
724
.KS
 
725
\fBKeysym\fP
 
726
.IN "Keysym" "" "@DEF@"
 
727
.IP
 
728
An encoding of a symbol on a keycap on a keyboard.
 
729
.KE
 
730
.LP
 
731
.KS
 
732
\fBLatin-1\fP
 
733
.IN "Latin-1" "" "@DEF@"
 
734
.IP
 
735
The coded character set defined by the ISO8859-1 standard.
 
736
.KE
 
737
.LP
 
738
.KS
 
739
\fBLatin Portable Character Encoding\fP
 
740
.IN "Latin Portable Character Encoding" "" "@DEF@"
 
741
.IP
 
742
The encoding of the X Portable Character Set using the Latin-1 codepoints
 
743
plus ASCII control characters.
 
744
If a string is said to be in the Latin Portable Character Encoding,
 
745
then it only contains characters from the X Portable Character Set,
 
746
not all of Latin-1.
 
747
.KE
 
748
.LP
 
749
.KS
 
750
\fBLocale\fP
 
751
.IN "Locale" "" "@DEF@"
 
752
.IP
 
753
The international environment of a computer program defining the ``localized''
 
754
behavior of that program at run-time.
 
755
This information can be established from one or more sets of localization data.
 
756
ANSI C defines locale-specific processing by C system library calls.
 
757
See ANSI C and the X/Open Portability Guide specifications for more details.
 
758
In this specification, on implementations that conform to the ANSI C library,
 
759
the ``current locale'' is the current setting of the LC_CTYPE
 
760
.PN setlocale
 
761
category.
 
762
Associated with each locale is a text encoding.  When text is processed
 
763
in the context of a locale, the text must be in the encoding of the locale.
 
764
The current locale affects Xlib in its:
 
765
.RS
 
766
.IP \(bu 5
 
767
Encoding and processing of input method text
 
768
.IP \(bu 5
 
769
Encoding of resource files and values
 
770
.IP \(bu 5
 
771
Encoding and imaging of text strings
 
772
.IP \(bu 5
 
773
Encoding and decoding for inter-client text communication
 
774
.RE
 
775
.KE
 
776
.LP
 
777
.KS
 
778
\fBLocale name\fP
 
779
.IN "Locale name" "" "@DEF@"
 
780
.IP
 
781
The identifier used to select the desired locale for the host C library 
 
782
and X library functions.
 
783
On ANSI C library compliant systems,
 
784
the locale argument to the
 
785
.PN setlocale
 
786
function.
 
787
.KE
 
788
.LP
 
789
.KS
 
790
\fBLocalization\fP
 
791
.IN "Localization" "" "@DEF@"
 
792
.IP
 
793
The process of establishing information within a computer system specific 
 
794
to the operation of particular native languages, local customs 
 
795
and coded character sets.
 
796
(XPG3)
 
797
.KE
 
798
.LP
 
799
.KS
 
800
\fBMapped\fP
 
801
.IN "Mapped window" "" "@DEF@"
 
802
.IP
 
803
A window is said to be mapped if a map call has been performed on it.
 
804
Unmapped windows and their inferiors are never viewable or visible.
 
805
.KE
 
806
.LP
 
807
.KS
 
808
\fBModifier keys\fP
 
809
.IN "Modifier keys" "" "@DEF@"
 
810
.IP
 
811
Shift, Control, Meta, Super, Hyper, Alt, Compose, Apple, CapsLock,
 
812
ShiftLock, and similar keys are called modifier keys.
 
813
.KE
 
814
.LP
 
815
.KS
 
816
\fBMonochrome\fP
 
817
.IN "Monochrome" "" "@DEF@"
 
818
.IP
 
819
Monochrome is a special case of 
 
820
.PN StaticGray
 
821
in which there are only two colormap entries.
 
822
.KE
 
823
.LP
 
824
.KS
 
825
\fBMultibyte\fP
 
826
.IN "Multibyte" "" "@DEF@"
 
827
.IP
 
828
A character whose codepoint is stored in more than one byte;
 
829
any encoding which can contain multibyte characters;
 
830
text in a multibyte encoding.
 
831
The ``char *'' null-terminated string datatype in ANSI C.
 
832
Note that references in this document to multibyte strings
 
833
imply only that the strings \fImay\fP contain multibyte characters.
 
834
.KE
 
835
.LP
 
836
.KS
 
837
\fBObscure\fP
 
838
.IN "Obscure" "" "@DEF@"
 
839
.IP
 
840
A window is obscured if some other window obscures it.
 
841
A window can be partially obscured and so still have visible regions.
 
842
Window A obscures window B if both are viewable 
 
843
.PN InputOutput 
 
844
windows, if A is higher in the global stacking order, 
 
845
and if the rectangle defined by the outside
 
846
edges of A intersects the rectangle defined by the outside edges of B.
 
847
Note the distinction between obscures and occludes.
 
848
Also note that window borders are included in the calculation.
 
849
.KE
 
850
.LP
 
851
.KS
 
852
\fBOcclude\fP
 
853
.IN "Occlude" "" "@DEF@"
 
854
.IP
 
855
A window is occluded if some other window occludes it.
 
856
Window A occludes window B if both are mapped, 
 
857
if A is higher in the global stacking order, 
 
858
and if the rectangle defined by the outside edges of A intersects the rectangle defined 
 
859
by the outside edges of B.  
 
860
Note the distinction between occludes and obscures.
 
861
Also note that window borders are included in the calculation
 
862
and that
 
863
.PN InputOnly
 
864
windows never obscure other windows but can occlude other windows.
 
865
.KE
 
866
.LP
 
867
.KS
 
868
\fBPadding\fP
 
869
.IN "Padding" "" "@DEF@"
 
870
.IP
 
871
Some padding bytes are inserted in the data stream to maintain
 
872
alignment of the protocol requests on natural boundaries.  
 
873
This increases ease of portability to some machine architectures.
 
874
.KE
 
875
.LP
 
876
.KS
 
877
\fBParent window\fP
 
878
.IN "Window" "parent" "@DEF@"
 
879
.IP
 
880
If C is a child of P, then P is the parent of C.
 
881
.KE
 
882
.LP
 
883
.KS
 
884
\fBPassive grab\fP
 
885
.IN "Passive grab" "" "@DEF@"
 
886
.IP
 
887
Grabbing a key or button is a passive grab.  
 
888
The grab activates when the key or button is actually pressed.
 
889
.KE
 
890
.LP
 
891
.KS
 
892
\fBPixel value\fP
 
893
.IN "Pixel value" "" "@DEF@"
 
894
.IP
 
895
A pixel is an N-bit value,
 
896
where N is the number of bit planes used in a particular window or pixmap
 
897
(that is, is the depth of the window or pixmap).  
 
898
A pixel in a window indexes a colormap to derive an actual color to be 
 
899
displayed.
 
900
.KE
 
901
.LP
 
902
.KS
 
903
\fBPixmap\fP
 
904
.IN "Pixmap" "" "@DEF@"
 
905
.EQ
 
906
delim %%
 
907
.EN
 
908
.IP
 
909
A pixmap is a three-dimensional array of bits.  
 
910
A pixmap is normally thought of as a two-dimensional array of pixels, 
 
911
where each pixel can be a value from 0 to %2 sup N %\-1, 
 
912
and where N is the depth (z axis) of the pixmap.  
 
913
A pixmap can also be thought of as a stack of N bitmaps.
 
914
A pixmap can only be used on the screen that it was created in.
 
915
.KE
 
916
.LP
 
917
.KS
 
918
\fBPlane\fP
 
919
.IN "Plane" "" "@DEF@"
 
920
.IP
 
921
When a pixmap or window is thought of as a stack of bitmaps, each
 
922
bitmap is called a plane or bit plane.
 
923
.KE
 
924
.LP
 
925
.KS
 
926
\fBPlane mask\fP
 
927
.IN "Plane" "mask" "@DEF@"
 
928
.IP
 
929
Graphics operations can be restricted to only affect a subset of bit
 
930
planes of a destination.  
 
931
A plane mask is a bit mask describing which planes are to be modified.
 
932
The plane mask is stored in a graphics context.
 
933
.KE
 
934
.LP
 
935
.KS
 
936
\fBPointer\fP
 
937
.IN "Pointer" "" "@DEF@"
 
938
.IP
 
939
The pointer is the pointing device currently attached to the cursor
 
940
and tracked on the screens.
 
941
.KE
 
942
.LP
 
943
.KS
 
944
\fBPointer grabbing\fP
 
945
.IN "Pointer" "grabbing" "@DEF@"
 
946
.IP
 
947
A client can actively grab control of the pointer. 
 
948
Then button and motion events will be sent to that client 
 
949
rather than the client the events would normally have been sent to.
 
950
.KE
 
951
.LP
 
952
.KS
 
953
\fBPointing device\fP
 
954
.IN "Pointing device"  "" "@DEF@"
 
955
.IP
 
956
A pointing device is typically a mouse, tablet, or some other
 
957
device with effective dimensional motion.  
 
958
The core protocol defines only one visible cursor,
 
959
which tracks whatever pointing device is attached as the pointer.
 
960
.KE
 
961
.LP
 
962
.KS
 
963
\fBPOSIX\fP
 
964
.IN "POSIX" "" "@DEF@"
 
965
.IP
 
966
Portable Operating System Interface, ISO/IEC 9945-1 (IEEE Std 1003.1).
 
967
.KE
 
968
.LP
 
969
.KS
 
970
\fBPOSIX Portable Filename Character Set\fP
 
971
.IN "POSIX Portable Filename Character Set" "" "@DEF@"
 
972
.IP
 
973
The set of 65 characters which can be used in naming files on a POSIX-compliant
 
974
host that are correctly processed in all locales.
 
975
The set is:
 
976
.IP
 
977
.Ds 0
 
978
a..z A..Z 0..9 ._-
 
979
.De
 
980
.KE
 
981
.LP
 
982
.KS
 
983
\fBProperty\fP
 
984
.IN "Property" "" "@DEF@"
 
985
.IP
 
986
Windows can have associated properties that consist of a name, a type,
 
987
a data format, and some data. 
 
988
The protocol places no interpretation on properties. 
 
989
They are intended as a general-purpose naming mechanism for clients.  
 
990
For example, clients might use properties to share information such as resize
 
991
hints, program names, and icon formats with a window manager.
 
992
.KE
 
993
.LP
 
994
.KS
 
995
\fBProperty list\fP
 
996
.IN "Property list" "" "@DEF@"
 
997
.IP
 
998
The property list of a window is the list of properties that have
 
999
been defined for the window.
 
1000
.KE
 
1001
.LP
 
1002
.KS
 
1003
\fBPseudoColor\fP
 
1004
.IN "PseudoColor" "" "@DEF@"
 
1005
.IP
 
1006
.PN PseudoColor
 
1007
is a class of colormap in which a pixel value indexes the colormap entry to
 
1008
produce an independent RGB value;
 
1009
that is, the colormap is viewed as an array of triples (RGB values).
 
1010
The RGB values can be changed dynamically.
 
1011
.KE
 
1012
.LP
 
1013
.KS
 
1014
\fBRectangle\fP
 
1015
.IN "Rectangle" "" "@DEF@"
 
1016
.IP
 
1017
A rectangle specified by [x,y,w,h] has an infinitely thin
 
1018
outline path with corners at [x,y], [x+w,y], [x+w,y+h], and [x, y+h].
 
1019
When a rectangle is filled,
 
1020
the lower-right edges are not drawn.
 
1021
For example,
 
1022
if w=h=0,
 
1023
nothing would be drawn.
 
1024
For w=h=1,
 
1025
a single pixel would be drawn.
 
1026
.KE
 
1027
.LP
 
1028
.KS
 
1029
\fBRedirecting control\fP
 
1030
.IN "Redirecting control" "" "@DEF@"
 
1031
.IP
 
1032
Window managers (or client programs) may enforce window layout
 
1033
policy in various ways.  
 
1034
When a client attempts to change the size or position of a window, 
 
1035
the operation may be redirected to a specified client
 
1036
rather than the operation actually being performed.
 
1037
.KE
 
1038
.LP
 
1039
.KS
 
1040
\fBReply\fP
 
1041
.IN "Reply" "" "@DEF@"
 
1042
.IP
 
1043
Information requested by a client program using the X protocol 
 
1044
is sent back to the client with a reply.
 
1045
Both events and replies are multiplexed on the same connection.  
 
1046
Most requests do not generate replies,
 
1047
but some requests generate multiple replies.
 
1048
.KE
 
1049
.LP
 
1050
.KS
 
1051
\fBRequest\fP
 
1052
.IN "Request" "" "@DEF@"
 
1053
.IP
 
1054
A command to the server is called a request.
 
1055
It is a single block of data sent over a connection.
 
1056
.KE
 
1057
.LP
 
1058
.KS
 
1059
\fBResource\fP
 
1060
.IN "Resource" "" "@DEF@"
 
1061
.IP
 
1062
Windows, pixmaps, cursors, fonts, graphics contexts, and colormaps are
 
1063
known as resources.  
 
1064
They all have unique identifiers associated with them for naming purposes.  
 
1065
The lifetime of a resource usually is bounded by the lifetime of the 
 
1066
connection over which the resource was created.
 
1067
.KE
 
1068
.LP
 
1069
.KS
 
1070
\fBRGB values\fP
 
1071
.IN "RGB values" "" "@DEF@"
 
1072
.IP
 
1073
RGB values are the red, green, and blue intensity values that are used
 
1074
to define a color.
 
1075
These values are always represented as 16-bit, unsigned numbers, with 0
 
1076
the minimum intensity and 65535 the maximum intensity.
 
1077
The X server scales these values to match the display hardware.
 
1078
.KE
 
1079
.LP
 
1080
.KS
 
1081
\fBRoot\fP
 
1082
.IN "Root" "" "@DEF@"
 
1083
.IP
 
1084
The root of a pixmap or graphics context is the same as the root 
 
1085
of whatever drawable was used when the pixmap or GC was created.  
 
1086
The root of a window is the root window under which the window was created.
 
1087
.KE
 
1088
.LP
 
1089
.KS
 
1090
\fBRoot window\fP
 
1091
.IN "Window" "root" "@DEF@"
 
1092
.IP
 
1093
Each screen has a root window covering it.
 
1094
The root window cannot be reconfigured or unmapped, 
 
1095
but otherwise it acts as a full-fledged window.
 
1096
A root window has no parent.
 
1097
.KE
 
1098
.LP
 
1099
.KS
 
1100
\fBSave set\fP
 
1101
.IN "Save set" "" "@DEF@"
 
1102
.IP
 
1103
The save set of a client is a list of other clients' windows that,
 
1104
if they are inferiors of one of the client's windows at connection
 
1105
close, should not be destroyed and that should be remapped 
 
1106
if currently unmapped.
 
1107
Save sets are typically used by window managers to avoid
 
1108
lost windows if the manager should terminate abnormally.
 
1109
.KE
 
1110
.LP
 
1111
.KS
 
1112
\fBScanline\fP
 
1113
.IN "Scanline" "" "@DEF@"
 
1114
.IP
 
1115
A scanline is a list of pixel or bit values viewed as a horizontal
 
1116
row (all values having the same y coordinate) of an image, with the
 
1117
values ordered by increasing the x coordinate.
 
1118
.KE
 
1119
.LP
 
1120
.KS
 
1121
\fBScanline order\fP
 
1122
.IN "Scanline" "order" "@DEF@"
 
1123
.IP
 
1124
An image represented in scanline order contains scanlines ordered by
 
1125
increasing the y coordinate.
 
1126
.KE
 
1127
.LP
 
1128
.KS
 
1129
\fBScreen\fP
 
1130
.IN "Screen" "" "@DEF@"
 
1131
.IP
 
1132
A server can provide several independent screens, 
 
1133
which typically have physically independent monitors.  
 
1134
This would be the expected configuration when there is only a single keyboard 
 
1135
and pointer shared among the screens.
 
1136
 
1137
.PN Screen 
 
1138
.IN "Screen" "structure"
 
1139
structure contains the information about that screen
 
1140
and is linked to the 
 
1141
.PN Display
 
1142
.IN "Display" "structure"
 
1143
structure.
 
1144
.KE
 
1145
.LP
 
1146
.KS
 
1147
\fBSelection\fP
 
1148
.IN "Selection" "" "@DEF@"
 
1149
.IP
 
1150
A selection can be thought of as an indirect property with dynamic
 
1151
type.
 
1152
That is, rather than having the property stored in the X server,
 
1153
it is maintained by some client (the owner).
 
1154
A selection is global and is thought of as belonging to the user 
 
1155
and being maintained by clients, 
 
1156
rather than being private to a particular window subhierarchy
 
1157
or a particular set of clients.
 
1158
When a client asks for the contents of
 
1159
a selection, it specifies a selection target type,
 
1160
which can be used to control the transmitted representation of the contents.
 
1161
For example, if the selection is ``the last thing the user clicked on,''
 
1162
and that is currently an image, then the target type might specify
 
1163
whether the contents of the image should be sent in XY format or
 
1164
Z format.
 
1165
.IP
 
1166
The target type can also be used to control the class of
 
1167
contents transmitted; for example, 
 
1168
asking for the ``looks'' (fonts, line
 
1169
spacing, indentation, and so forth) of a paragraph selection, rather than the
 
1170
text of the paragraph.
 
1171
The target type can also be used for other
 
1172
purposes.
 
1173
The protocol does not constrain the semantics.
 
1174
.KE
 
1175
.LP
 
1176
.KS
 
1177
\fBServer\fP
 
1178
.IN "Server" "" "@DEF@"
 
1179
.IP
 
1180
The server, which is also referred to as the X server, 
 
1181
provides the basic windowing mechanism.  
 
1182
It handles IPC connections from clients, 
 
1183
multiplexes graphics requests onto the screens, 
 
1184
and demultiplexes input back to the appropriate clients.
 
1185
.KE
 
1186
.LP
 
1187
.KS
 
1188
\fBServer grabbing\fP
 
1189
.IN "Server" "grabbing" "@DEF@"
 
1190
.IP
 
1191
The server can be grabbed by a single client for exclusive use.  
 
1192
This prevents processing of any requests from other client connections until
 
1193
the grab is completed.
 
1194
This is typically only a transient state for such things as rubber-banding,
 
1195
pop-up menus, or executing requests indivisibly.
 
1196
.KE
 
1197
.LP
 
1198
.KS
 
1199
\fBShift sequence\fP
 
1200
.IN "Shift sequence" "" "@DEF@"
 
1201
.IP
 
1202
ISO2022 defines control characters and escape sequences 
 
1203
which temporarily (single shift) or permanently (locking shift) cause a
 
1204
different character set to be in effect (``invoking'' a character set).
 
1205
.KE
 
1206
.LP
 
1207
.KS
 
1208
\fBSibling\fP
 
1209
.IN "Sibling" "" "@DEF@"
 
1210
.IP
 
1211
Children of the same parent window are known as sibling windows.
 
1212
.KE
 
1213
.LP
 
1214
.KS
 
1215
\fBStacking order\fP
 
1216
.IN "Stacking order" "" "@DEF@"
 
1217
.IP
 
1218
Sibling windows, similar to sheets of paper on a desk,
 
1219
can stack on top of each other.  
 
1220
Windows above both obscure and occlude lower windows.  
 
1221
The relationship between sibling windows is known as the stacking order.
 
1222
.KE
 
1223
.LP
 
1224
.KS
 
1225
\fBState-dependent encoding\fP
 
1226
.IN "State-dependent encoding" "" "@DEF@"
 
1227
.IP
 
1228
An encoding in which an invocation of a charset can apply to multiple
 
1229
characters in sequence.
 
1230
A state-dependent encoding begins in an ``initial state'' 
 
1231
and enters other ``shift states'' when specific ``shift sequences'' 
 
1232
are encountered in the byte sequence.
 
1233
In ISO2022 terms,
 
1234
this means use of locking shifts, not single shifts.
 
1235
.KE
 
1236
.LP
 
1237
.KS
 
1238
\fBState-independent encoding\fP
 
1239
.IN "State-independent encoding" "" "@DEF@"
 
1240
.IP
 
1241
Any encoding in which the invocations of the charsets are fixed,
 
1242
or span only a single character.
 
1243
In ISO2022 terms,
 
1244
this means use of at most single shifts, not locking shifts.
 
1245
.KE
 
1246
.LP
 
1247
.KS
 
1248
\fBStaticColor\fP
 
1249
.IN "StaticColor" "" "@DEF@"
 
1250
.IP
 
1251
.PN StaticColor 
 
1252
can be viewed as a degenerate case of 
 
1253
.PN PseudoColor
 
1254
in which the RGB values are predefined and read-only.
 
1255
.KE
 
1256
.LP
 
1257
.KS
 
1258
\fBStaticGray\fP
 
1259
.IN "StaticGray" "" "@DEF@"
 
1260
.IP
 
1261
.PN StaticGray 
 
1262
can be viewed as a degenerate case of 
 
1263
.PN GrayScale
 
1264
in which the gray values are predefined and read-only.
 
1265
The values are typically linear or near-linear increasing ramps.
 
1266
.KE
 
1267
.LP
 
1268
.KS
 
1269
\fBStatus\fP
 
1270
.IN "Status" "" "@DEF@"
 
1271
.IP
 
1272
Many Xlib functions return a success status.
 
1273
If the function does not succeed,
 
1274
however, its arguments are not disturbed.
 
1275
.KE
 
1276
.LP
 
1277
.KS
 
1278
\fBStipple\fP
 
1279
.IN "Stipple" "" "@DEF@"
 
1280
.IP
 
1281
A stipple pattern is a bitmap that is used to tile a region to serve
 
1282
as an additional clip mask for a fill operation with the foreground
 
1283
color.
 
1284
.KE
 
1285
.KS
 
1286
.LP
 
1287
.KS
 
1288
\fBSTRING encoding\fP
 
1289
.IN "STRING encoding" "" "@DEF@"
 
1290
.IP
 
1291
Latin-1, plus tab and newline.
 
1292
.KE
 
1293
.LP
 
1294
\fBString Equivalence\fP
 
1295
.IN "String Equivalence" "" "@DEF@"
 
1296
.IP
 
1297
Two ISO Latin-1 STRING8 values are considered equal if they are the same
 
1298
length and if corresponding bytes are either equal or are equivalent as
 
1299
follows:  decimal values 65 to 90 inclusive (characters ``A'' to ``Z'') are
 
1300
pairwise equivalent to decimal values 97 to 122 inclusive
 
1301
(characters ``a'' to ``z''), decimal values 192 to 214 inclusive
 
1302
(characters ``A grave'' to ``O diaeresis'') are pairwise equivalent to decimal
 
1303
values 224 to 246 inclusive (characters ``a grave'' to ``o diaeresis''),
 
1304
and decimal values 216 to 222 inclusive (characters ``O oblique'' to ``THORN'')
 
1305
are pairwise equivalent to decimal values 246 to 254 inclusive
 
1306
(characters ``o oblique'' to ``thorn'').
 
1307
.KE
 
1308
.LP
 
1309
.KS
 
1310
\fBTile\fP
 
1311
.IN "Tile" "" "@DEF@"
 
1312
.IP
 
1313
A pixmap can be replicated in two dimensions to tile a region.  
 
1314
The pixmap itself is also known as a tile.
 
1315
.KE
 
1316
.LP
 
1317
.KS
 
1318
\fBTimestamp\fP
 
1319
.IN "Timestamp" "" "@DEF@"
 
1320
.IP
 
1321
A timestamp is a time value expressed in milliseconds. 
 
1322
It is typically the time since the last server reset.
 
1323
Timestamp values wrap around (after about 49.7 days).
 
1324
The server, given its current time is represented by timestamp T, 
 
1325
always interprets timestamps from clients by treating half 
 
1326
of the timestamp space as being earlier in time than T 
 
1327
and half of the timestamp space as being later in time than T.
 
1328
One timestamp value, represented by the constant 
 
1329
.PN CurrentTime ,
 
1330
is never generated by the server. 
 
1331
This value is reserved for use in requests to represent the current server time.
 
1332
.KE
 
1333
.LP
 
1334
.KS
 
1335
\fBTrueColor\fP
 
1336
.IN "TrueColor" "" "@DEF@"
 
1337
.IP
 
1338
.PN TrueColor
 
1339
can be viewed as a degenerate case of 
 
1340
.PN DirectColor
 
1341
in which the subfields in the pixel value directly encode the corresponding RGB
 
1342
values.
 
1343
That is, the colormap has predefined read-only RGB values.
 
1344
The values are typically linear or near-linear increasing ramps.
 
1345
.KE
 
1346
.LP
 
1347
.KS
 
1348
\fBType\fP
 
1349
.IN "Type" "" "@DEF@"
 
1350
.IP
 
1351
A type is an arbitrary atom used to identify the interpretation of property 
 
1352
data.  
 
1353
Types are completely uninterpreted by the server. 
 
1354
They are solely for the benefit of clients.
 
1355
X predefines type atoms for many frequently used types,
 
1356
and clients also can define new types.
 
1357
.KE
 
1358
.LP
 
1359
.KS
 
1360
\fBViewable\fP
 
1361
.IN "Viewable" "" "@DEF@"
 
1362
.IP
 
1363
A window is viewable if it and all of its ancestors are mapped.  
 
1364
This does not imply that any portion of the window is actually visible.
 
1365
Graphics requests can be performed on a window when it is not
 
1366
viewable, but output will not be retained unless the server is maintaining
 
1367
backing store. 
 
1368
.KE
 
1369
.LP
 
1370
.KS
 
1371
\fBVisible\fP
 
1372
.IN "Visible" "" "@DEF@"
 
1373
.IP
 
1374
A region of a window is visible if someone looking at the screen can
 
1375
actually see it; that is, the window is viewable and the region is not occluded
 
1376
by any other window.
 
1377
.KE
 
1378
.LP
 
1379
.KS
 
1380
\fBWhitespace\fP
 
1381
.IN "Whitespace" "" "@DEF@"
 
1382
.IP
 
1383
Any spacing character.
 
1384
On implementations that conform to the ANSI C library,
 
1385
whitespace is any character for which
 
1386
.PN isspace
 
1387
returns true.
 
1388
.KE
 
1389
.LP
 
1390
.KS
 
1391
\fBWindow gravity\fP
 
1392
.IN "Window" "gravity" "@DEF@"
 
1393
.IP
 
1394
When windows are resized, 
 
1395
subwindows may be repositioned automatically relative to some position in the 
 
1396
window.
 
1397
This attraction of a subwindow to some part of its parent is known 
 
1398
as window gravity.
 
1399
.KE
 
1400
.LP
 
1401
.KS
 
1402
\fBWindow manager\fP
 
1403
.IN "Window" "manager" "@DEF@"
 
1404
.IP
 
1405
Manipulation of windows on the screen and much of the user interface
 
1406
(policy) is typically provided by a window manager client.
 
1407
.KE
 
1408
.LP
 
1409
.KS
 
1410
\fBX Portable Character Set\fP
 
1411
.IN "X Portable Character Set" "" "@DEF@"
 
1412
.IP
 
1413
A basic set of 97 characters which are assumed to exist in all
 
1414
locales supported by Xlib.  This set contains the following characters:
 
1415
.IP
 
1416
.Ds 0
 
1417
.EQ
 
1418
delim DD
 
1419
.EN
 
1420
a..z A..Z 0..9
 
1421
!"#$%&'()*+,-./:;<=>?@[\\]^_`{|}~
 
1422
<space>, <tab>, and <newline>
 
1423
.EQ
 
1424
delim %%
 
1425
.EN
 
1426
.De
 
1427
.IP
 
1428
This is the left/lower half (also called the G0 set)
 
1429
of the graphic character set of ISO8859-1 plus <space>, <tab>, and <newline>.
 
1430
It is also the set of graphic characters in 7-bit ASCII plus the same
 
1431
three control characters.
 
1432
The actual encoding of these characters on the host is system dependent;
 
1433
see the Host Portable Character Encoding.
 
1434
.KE
 
1435
.LP
 
1436
.KS
 
1437
\fBXLFD\fP
 
1438
.IN "XLFD" "" "@DEF@"
 
1439
.IP
 
1440
The X Logical Font Description Conventions that define a standard syntax 
 
1441
for structured font names.
 
1442
.KE
 
1443
.LP
 
1444
.KS
 
1445
\fBXY format\fP
 
1446
.IN "XY format" "" "@DEF@"
 
1447
.IP
 
1448
The data for a pixmap is said to be in XY format if it is organized as
 
1449
a set of bitmaps representing individual bit planes with the planes
 
1450
appearing from most-significant to least-significant bit order.
 
1451
.KE
 
1452
.LP
 
1453
.KS
 
1454
\fBZ format\fP
 
1455
.IN "Z format" "" "@DEF@"
 
1456
.IP
 
1457
The data for a pixmap is said to be in Z format if it is organized as
 
1458
a set of pixel values in scanline order.
 
1459
.KE
 
1460
.LP
 
1461
\fBReferences\fP
 
1462
.LP
 
1463
ANSI Programming Language - C: ANSI X3.159-1989, December 14, 1989.
 
1464
.LP
 
1465
Draft Proposed Multibyte Extension of ANSI C, Draft 1.1, November 30,
 
1466
1989, SC22/C WG/SWG IPSJ/ITSCJ Japan.
 
1467
.LP
 
1468
ISO2022: Information processing - ISO 7-bit and 8-bit coded character
 
1469
sets - Code extension techniques.
 
1470
.LP
 
1471
ISO8859-1: Information processing - 8-bit single-byte coded graphic
 
1472
character sets - Part 1: Latin alphabet No. 1.
 
1473
.LP
 
1474
POSIX: Information Technology - Portable Operating System Interface (POSIX) -
 
1475
Part 1: System Application Program Interface (API) [C Language],
 
1476
ISO/IEC 9945-1.
 
1477
.LP
 
1478
Text of ISO/IEC/DIS 9541-1, Information Processing - Font Information
 
1479
Interchange - Part 1:  Architecture.
 
1480
.LP
 
1481
X/Open Portability Guide, Issue 3, December 1988 (XPG3), X/Open Company,
 
1482
Ltd, Prentice-Hall, Inc. 1989. ISBN 0-13-685835-8.
 
1483
(See especially Volume 3:  XSI Supplementary Definitions.)
 
1484
.bp