Strip trailing whitespace

Performed with: find * -type f | xargs perl -i -p -e 's{[ \t]+$}{}'
git diff -w & git diff -b show no diffs from this change

Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>

1 files changed, 59 insertions, 59 deletions

diff --git a/man/DBE.man b/man/DBE.man
index 7cd36b6..5ed34c2 100644
--- a/man/DBE.man
+++ b/man/DBE.man
@@ -1,26 +1,26 @@
 .\" Copyright (c) 1995  Hewlett-Packard Company
-.\" 
+.\"
 .\" Permission is hereby granted, free of charge, to any person obtaining a
-.\" copy of this software and associated documentation files (the "Software"), 
-.\" to deal in the Software without restriction, including without limitation 
-.\" the rights to use, copy, modify, merge, publish, distribute, sublicense, 
-.\" and/or sell copies of the Software, and to permit persons to whom the 
+.\" copy of this software and associated documentation files (the "Software"),
+.\" to deal in the Software without restriction, including without limitation
+.\" the rights to use, copy, modify, merge, publish, distribute, sublicense,
+.\" and/or sell copies of the Software, and to permit persons to whom the
 .\" Software furnished to do so, subject to the following conditions:
-.\" 
+.\"
 .\" The above copyright notice and this permission notice shall be included in
 .\" all copies or substantial portions of the Software.
-.\" 
+.\"
 .\" THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
 .\" IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
-.\" FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL 
-.\" HEWLETT-PACKARD COMPANY BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, 
-.\" WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF 
-.\" OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE 
+.\" FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+.\" HEWLETT-PACKARD COMPANY BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+.\" WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF
+.\" OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
 .\" SOFTWARE.
-.\" 
-.\" Except as contained in this notice, the name of the Hewlett-Packard Company shall not 
-.\" be used in advertising or otherwise to promote the sale, use or other 
-.\" dealing in this Software without prior written authorization from the 
+.\"
+.\" Except as contained in this notice, the name of the Hewlett-Packard Company shall not
+.\" be used in advertising or otherwise to promote the sale, use or other
+.\" dealing in this Software without prior written authorization from the
 .\" Hewlett-Packard Company.
 .\"
 .TH DBE __libmansuffix__ __xorgversion__ "X FUNCTIONS"
@@ -33,9 +33,9 @@ Double-buffering uses two buffers, called front and back, which hold images.
 The front buffer is visible to the user; the back buffer is not.  Successive
 frames of an animation are rendered into the back buffer while the previously
 rendered frame is displayed in the front buffer.  When a new frame is ready,
-the back and front buffers swap roles, making the new frame visible.  Ideally, 
+the back and front buffers swap roles, making the new frame visible.  Ideally,
 this exchange appears to happen instantaneously to the user, with no visual
-artifacts.  Thus, only completely rendered images are presented to the user, 
+artifacts.  Thus, only completely rendered images are presented to the user,
 and remain visible during the entire time it takes to render a new frame.  The
 result is a flicker-free animation.
 .SH DESCRIPTION
@@ -46,34 +46,34 @@ Normal windows are created using
 or
 .B XCreateSimpleWindow(),
 which allocate a set of window attributes and, for InputOutput windows, a front
-buffer, into which an image can be drawn.  The contents of this buffer will be 
+buffer, into which an image can be drawn.  The contents of this buffer will be
 displayed when the window is visible.
 
 This extension enables applications to use double-buffering with a window.
 This involves creating a second buffer, called a back buffer, and associating
 one or more back buffer names
 .I (XIDs)
-with the window, for use when referring 
+with the window, for use when referring
 to (i.e., drawing to or reading from) the window's back buffer.
 The back buffer name is a drawable of type
 .I XdbeBackBuffer.
 
 DBE provides a relative double-buffering model.  One XID, the window,
 always refers to the front buffer.  One or more other XIDs, the back buffer
-names, always refer to the back buffer.  After a buffer swap, the window 
+names, always refer to the back buffer.  After a buffer swap, the window
 continues to refer to the (new) front buffer, and the back buffer name
 continues to refer to the (new) back buffer.  Thus, applications and toolkits
 that want to just render to the back buffer always use the back buffer name
 for all drawing requests to the window.  Portions of an application that want
-to render to the front buffer always use the window XID for all drawing 
+to render to the front buffer always use the window XID for all drawing
 requests to the window.
 
 Multiple clients and toolkits can all use double-buffering on the same window.
-DBE does not provide a request for querying whether a window has 
-double-buffering support, and if so, what the back buffer name is.  Given the 
+DBE does not provide a request for querying whether a window has
+double-buffering support, and if so, what the back buffer name is.  Given the
 asynchronous nature of the X Window System, this would cause race
-conditions.  Instead, DBE allows multiple back buffer names to exist for the 
-same window; they all refer to the same physical back buffer.  The first time a 
+conditions.  Instead, DBE allows multiple back buffer names to exist for the
+same window; they all refer to the same physical back buffer.  The first time a
 back buffer name is allocated for a window, the window becomes
 double-buffered and the back buffer name is associated with the window.
 Subsequently, the window already is a double-buffered window, and nothing
@@ -82,7 +82,7 @@ that the new back buffer name is associated with the window.  The window
 remains double-buffered until either the window is destroyed, or until all of
 the back buffer names for the window are deallocated.
 
-In general, both the front and back buffers ae treated the same.  In 
+In general, both the front and back buffers ae treated the same.  In
 particular, here are some important characteristics:
 
 .RS
@@ -92,11 +92,11 @@ Both buffers associated with a window have the same visual type, depth,
 width, height, and shape as the window.
 
 Both buffers associated with a window are "visible" (or "obscured") in
-the same way.  When an Expose event is generated for a window, this 
-event is considered to apply to both buffers equally.  When a 
-double-buffered window is exposed, both buffers are tiled with the 
+the same way.  When an Expose event is generated for a window, this
+event is considered to apply to both buffers equally.  When a
+double-buffered window is exposed, both buffers are tiled with the
 window background.
-Even though the back buffer is not visible, terms such as obscure apply to the 
+Even though the back buffer is not visible, terms such as obscure apply to the
 back buffer as well as to the front buffer.
 
 It is acceptable at any time to pass an
@@ -148,14 +148,14 @@ on a back
 buffer return undefined image contents for any obscured regions of the back
 buffer that fall within the image.
 
-Drawing to a back buffer always uses the clip region that would be used to 
-draw to the front buffer with a GC subwindow-mode of ClipByChildren.  If an 
+Drawing to a back buffer always uses the clip region that would be used to
+draw to the front buffer with a GC subwindow-mode of ClipByChildren.  If an
 ancestor of a double-buffered window is drawn to with a GC having a
 subwindow-mode of IncludeInferiors, the effect on the double-buffered
 window's back buffer depends on the depth of the double-buffered window
 and the ancestor.  If the depths are the same, the contents of the back buffer
 of the double-buffered window are not changed.  If the depths are different,
-the contents of the back buffer of the double-buffered window are undefined 
+the contents of the back buffer of the double-buffered window are undefined
 for the pixels that the IncludeInferiors drawing touched.
 
 DBE adds no new events.  DBE does not extend the semantics of any existing
@@ -183,13 +183,13 @@ When a double-buffered window is destroyed,
 both buffers associated with the window are destroyed, and all back buffer
 names associated with the window are freed.
 
-If the size of a double-buffered window changes, both 
-buffers assume the new size.  If the window's size increases, the effect on the 
+If the size of a double-buffered window changes, both
+buffers assume the new size.  If the window's size increases, the effect on the
 buffers depends on whether the implementation honors bit gravity for buffers.
-If bit gravity is implemented, then the contents of both buffers are moved in 
+If bit gravity is implemented, then the contents of both buffers are moved in
 accordance with the window's bit gravity,
-and the remaining areas are tiled with the window background.  If 
-bit gravity is not implemented, then the entire unobscured region of both 
+and the remaining areas are tiled with the window background.  If
+bit gravity is not implemented, then the entire unobscured region of both
 buffers is tiled with the window background.  In either case, Expose events are
 generated for the region that is tiled with the window background.
 
@@ -203,37 +203,37 @@ If the Shape extension
 .B ShapeRectangles, ShapeMask, ShapeCombine,
 or
 .B ShapeOffset
-request is executed on a double-buffered window, both 
+request is executed on a double-buffered window, both
 buffers are reshaped to match the new window shape.  The region difference
-D = new shape - old shape is tiled with the window background in both 
+D = new shape - old shape is tiled with the window background in both
 buffers, and Expose events are generated for D.
 .RE
 
 .B Complex Swap Actions
 
 .RS
-DBE has no explicit knowledge of ancillary buffers (e.g. depth buffers or 
+DBE has no explicit knowledge of ancillary buffers (e.g. depth buffers or
 alpha buffers), and only has a limited set of defined swap actions.  Some
-applications may need a richer set of swap actions than DBE provides.  Some 
-DBE implementations have knowledge of ancillary buffers, and/or can provide 
+applications may need a richer set of swap actions than DBE provides.  Some
+DBE implementations have knowledge of ancillary buffers, and/or can provide
 a rich set of swap actions. Instead of continually extending DBE to increase
-its set of swap actions, DBE provides a flexible "idiom" mechanism.  If an 
+its set of swap actions, DBE provides a flexible "idiom" mechanism.  If an
 applications's needs are served by the defined swap actions, it should use
 them; otherwise, it should use the following method of expressing a complex
 swap action as an idiom.  Following this policy will ensure the best possible
 performance across a wide variety of implementations.
 
-As suggested by the term "idiom," a complex swap action should be expressed 
-as a group/series of requests.  Taken together, this group of requests may be 
-combined into an atomic operation by the implementation, in order to 
+As suggested by the term "idiom," a complex swap action should be expressed
+as a group/series of requests.  Taken together, this group of requests may be
+combined into an atomic operation by the implementation, in order to
 maximize performance.  The set of idioms actually recognized for optimization
-is implementation dependent.  To help with idiom expression and 
-interpretation, an idiom must be surrounded by two function calls:  
+is implementation dependent.  To help with idiom expression and
+interpretation, an idiom must be surrounded by two function calls:
 .B XdbeBeginIdiom()
 and
 .B XdbeEndIdiom().
 Unless this begin-end pair
-surrounds the idiom, it may not be recognized by a given implementation, and 
+surrounds the idiom, it may not be recognized by a given implementation, and
 performance will suffer.
 
 For example, if an application wants to swap buffers for two windows, and use
@@ -260,7 +260,7 @@ The
 and
 .B XdbeEndIdiom()
 functions do not perform any
-actions themselves.  They are treated as markers by implementations that can 
+actions themselves.  They are treated as markers by implementations that can
 combine certain groups/series of requests as idioms, and are ignored by other
 implementations or for non-recognized groups/series of requests.  If these
 function calls are made out of order, or are mismatched, no errors are sent,
@@ -271,32 +271,32 @@ need not be included in an idiom.  For
 example, if a swap action of Copied is desired, but only some of the planes
 should be copied,
 .B XCopyArea()
-may be used instead of 
+may be used instead of
 .B XdbeSwapBuffers().
 If
 .B XdbeSwapBuffers()
 is included in an idiom, it should immediately follow the
 .B XdbeBeginIdiom()
-call.  Also, when the 
+call.  Also, when the
 .B XdbeSwapBuffers()
-is included in an idiom, that request's swap action will 
-still be valid, and if the swap action might overlap with another request, then 
+is included in an idiom, that request's swap action will
+still be valid, and if the swap action might overlap with another request, then
 the final result of the idiom must be as if the separate requests were executed
-serially.  For example, if the specified swap action is Untouched, and if a 
+serially.  For example, if the specified swap action is Untouched, and if a
 .B XFillRectangle()
 using a client clip rectangle is done to the window's back
 buffer after the
 .B XdbeSwapBuffers()
-call, then the contents of the new 
+call, then the contents of the new
 back buffer (after the idiom) will be the same as if the idiom was not
 recognized by the implementation.
 
-It is highly recommended that API providers define, and application 
+It is highly recommended that API providers define, and application
 developers use, "convenience" functions that allow client applications to call
 one procedure that encapsulates common idioms.  These functions will
 generate the
 .B XdbeBeginIdiom(),
-idiom, and 
+idiom, and
 .B XdbeEndIdiom()
 calls.  Usage of these functions will ensure best possible
 performance across a wide variety of implementations.