Remove trailing space characters (unsure)

Author: aaronfranke

specification/loader/api_layer.adoc

@@ -498,7 +498,7 @@ only requirement is that the filename extension is ".json".
 		with each "version" of the API layer) must be set in the environment or else
         the implicit API layer is not loaded. This is for application environments
         (e.g. Steam) which want to enable an API layer(s) only for applications that
-        they launch, and allows for applications run outside of that 
+        they launch, and allows for applications run outside of that
         environment to not get that implicit API layer(s).
             | N/A
 | "disable_environment"
@@ -623,7 +623,7 @@ struct XrNegotiateLoaderInfo {
 
 You'll notice the structures are similar to other OpenXR structures.
 The "structType" field, in this case takes a new enum defined just for internal
-loader interfacing use. 
+loader interfacing use.
 
 The ename:XrLoaderInterfaceStructs enumeration is also defined in the
 `src/common/loader_interfaces.h` header and currently looks like:
@@ -699,7 +699,7 @@ variable of type slink:XrNegotiateLoaderInfo and initialize it in the following
    `XR_LOADER_INFO_STRUCT_VERSION`
 3. Set the structure "structSize" to the current size of the
    `XrNegotiateLoaderInfo` structure
-4. Set "minInterfaceVersion" to the minimum 
+4. Set "minInterfaceVersion" to the minimum
    <<api-layer-interface-versions,loader/API layer interface version>> that the
    loader supports
 5. Set "maxInterfaceVersion" to the current version of the

specification/loader/application.adoc

@@ -5,8 +5,8 @@
 [[application-interaction]]
 == Application Interaction ==
 
-An application requests a specific version of the OpenXR API when creating an 
-instance by writing to the "apiVersion" member of the `XrApplicationInfo` 
+An application requests a specific version of the OpenXR API when creating an
+instance by writing to the "apiVersion" member of the `XrApplicationInfo`
 structure which, in turn, is passed into the `XrInstanceCreateInfo` structure.
 If either the loader or the active runtime do not support the requested version,
 they may return an error and fail instance creation.  Refer to the
@@ -20,8 +20,8 @@ through the loader:
 
 1. Directly linking to the core OpenXR commands exposed and exported by the loader.
 2. Creating an application-managed dispatch table of OpenXR commands by querying
-the loader for function pointers via `xrGetInstanceProcAddr`. This method 
-supports core OpenXR commands, commands of (enabled) OpenXR extensions supported by the runtime, 
+the loader for function pointers via `xrGetInstanceProcAddr`. This method
+supports core OpenXR commands, commands of (enabled) OpenXR extensions supported by the runtime,
 and any commands exposed by enabled API layers.
 
 [[openxr-direct-exports]]
@@ -110,7 +110,7 @@ second call chain.
 [[openxr-indirect-linking]]
 ==== OpenXR Indirect Linking ====
 
-With loader indirect linking an application dynamically generates its own 
+With loader indirect linking an application dynamically generates its own
 dispatch table of OpenXR commands.  This method allows an application to
 fail gracefully if the loader cannot be found, or supports an older version
 of the API than the application. To do this, the application uses the
@@ -154,13 +154,13 @@ versions of OpenXR.
 === Application API Layer Usage ===
 
 Applications desiring OpenXR functionality beyond what the core API offers may
-use various API layers or extensions. An API layer cannot introduce new OpenXR 
+use various API layers or extensions. An API layer cannot introduce new OpenXR
 _core_ API commands, but may introduce new extension-specific OpenXR commands
 that can be queried through the extension interface.
 
 A common use of API layers is for validation which can be enabled by loading the
 API layer during application development, but not loading the API layer for
-application release. The overhead cost of validation is completely eliminated 
+application release. The overhead cost of validation is completely eliminated
 when the layer is not loaded.
 
 An application can discover which API layers are available to it with
@@ -169,7 +169,7 @@ that have been discovered by the loader.  The loader looks in various locations
 to find API layers on the system.  For more information see the
 <<api-layer-discovery,API Layer discovery>> section below.
 
-An API layer or layers may be enabled by an application by passing a list of 
+An API layer or layers may be enabled by an application by passing a list of
 names in the `enabledApiLayerNames` field of the `XrInstanceCreateInfo`
 at `xrCreateInstance` time.  During the `xrCreateInstance`, the loader
 constructs a <<openxr-call-chains, call chain>> that includes the application
@@ -193,12 +193,12 @@ ensure that you are using it properly.
 [[implicit-vs-explicit-api-layers]]
 ==== Implicit vs Explicit API Layers ====
 
-Explicit API layers are API layers which are enabled by an application (e.g. 
+Explicit API layers are API layers which are enabled by an application (e.g.
 with the `xrCreateInstance` function) or by setting a
-<<forced-loading-of-api-layers, loader environment variable>>. 
+<<forced-loading-of-api-layers, loader environment variable>>.
 
-Implicit API layers are API layers which are enabled simply because they exist. 
-An implicit layer found by the loader will be loaded by default, unless 
+Implicit API layers are API layers which are enabled simply because they exist.
+An implicit layer found by the loader will be loaded by default, unless
 specifically disabled.
 
 Some implicit API layer examples include:
@@ -209,7 +209,7 @@ Some implicit API layer examples include:
 * A tracing API layer designed to record API commands for future playback.
 
 Because implicit API layers are enabled automatically, they have an additional
-requirement over explicit API layers in that they must specify a 
+requirement over explicit API layers in that they must specify a
 "disable environment variable" in the API layer's
 <<api-layer-manifest-file-format, JSON manifest file>>, with key name `disable_environment`.
 This environment variable when present will disable the implicit API layer. Implicit
@@ -337,7 +337,7 @@ additional loader functionality.  Information about various extensions can be
 found in the <<openxr-spec,OpenXR API Specification>>, and `openxr.h` header
 file.
 
-To use extension functionality, the application should: call 
+To use extension functionality, the application should: call
 `xrEnumerateInstanceExtensionProperties` to determine if the extension is available.
 Then it must: enable the extension in `xrCreateInstance`.
 

specification/loader/design.adoc

@@ -128,7 +128,7 @@ The OpenXR loader is responsible with interfacing with other libraries to
 complete its tasks.  Typically, there will be some interface negotiation
 between these other libraries and the loader (see
 <<loader-api-layer-interface-negotiation, Loader/Layer Interface Negotiation>>
-or 
+or
 <<loader-runtime-interface-negotiation, Loader/Runtime Interface Negotiation>>
 for more information).   The Interface classes are responsible with using
 the contents of a ManifestFile to setup the interface.  Each Interface
@@ -677,7 +677,7 @@ const char *LoaderPlatformLibraryOpenError(
     flink:LoaderPlatformLibraryOpen.
 
 The returned C-style character string contains any available platform-specific
-error code that may have occurred. 
+error code that may have occurred.
 
 
 .Closing A Platform-Specific Library File
@@ -719,7 +719,7 @@ If the function succeeds, the returned value will be a valid function
 pointer address.  If the function fails, it will return NULL.  A NULL return
 value could imply that the function simply isn't exported by the library,
 or that an error occurred during the platform call.  To determine what
-might have happened, the loader will call the 
+might have happened, the loader will call the
 fname:LoaderPlatformLibraryGetProcAddrError function:
 
 [[LoaderPlatformLibraryGetProcAddrError]]
@@ -733,7 +733,7 @@ const char *LoaderPlatformLibraryGetProcAddrError(
     flink:LoaderPlatformLibraryGetProcAddr call.
 
 The returned C-style character string contains any available platform-specific
-error code that may have occurred. 
+error code that may have occurred.
 
 
 [[environment-variable-usage]]

specification/loader/loader.adoc

@@ -24,11 +24,11 @@ toc::[]
 
 This document contains the necessary information for understanding how
 to develop for, and interact with, the OpenXR loader.  Intended use of
-this document is as a detailed design document and a tool for learning 
+this document is as a detailed design document and a tool for learning
 general OpenXR loader behavior.
 
 In the event of any discrepancies between this document and
-the (https://www.khronos.org/registry/OpenXR[OpenXR specification]), that document is authoritative.  
+the (https://www.khronos.org/registry/OpenXR[OpenXR specification]), that document is authoritative.
 
 
 [[introduction-terminology]]

specification/loader/overview.adoc

@@ -103,9 +103,9 @@ the <<api-layer-interaction, "API Layer Interaction">> section of this document.
 [[openxr-runtimes]]
 === OpenXR Runtimes ===
 
-OpenXR works with multiple runtimes each supporting one or more devices. Each 
-OpenXR runtime controls a complete VR/AR/MR system. Multiple runtimes may be 
-installed on a system, with one being _active_ at any given time. The loader 
+OpenXR works with multiple runtimes each supporting one or more devices. Each
+OpenXR runtime controls a complete VR/AR/MR system. Multiple runtimes may be
+installed on a system, with one being _active_ at any given time. The loader
 discovers the active runtime on the system and loads it.
 When an `XrInstance` is created during `xrCreateInstance`, the active runtime
 is associated with the instance.
@@ -119,7 +119,7 @@ the <<runtime-interaction, "Runtime Interaction">> section of this document.
 OpenXR uses an object model to control the scope of a particular action or
 operation.  The object to be acted on is usually the first parameter of an
 OpenXR call.  Under the covers, this object is a unique handle to either a
-class or structure.  The contents of each class/structure vary, but each 
+class or structure.  The contents of each class/structure vary, but each
 has a means of looking up a dispatch table which is
 used to direct the functional flow through any enabled API layers and into the
 appropriate runtime.
@@ -138,10 +138,10 @@ take an object.
 === OpenXR Call Chains ===
 
 When an (optional) API layer is loaded, the loader links together a _call chain_
-that includes each function selected by the layer. At `xrCreateInstance` time the 
+that includes each function selected by the layer. At `xrCreateInstance` time the
 loader initializes all enabled API layers and creates call
-chains for each OpenXR command, with each entry of the resulting dispatch table 
-pointing to the first element of that chain. The loader builds an individual 
+chains for each OpenXR command, with each entry of the resulting dispatch table
+pointing to the first element of that chain. The loader builds an individual
 dispatch table for the `XrInstance` that is created.
 
 When an application calls an OpenXR command, this typically will first hit a

specification/loader/runtime.adoc

@@ -282,7 +282,7 @@ detail below.
 The sname:XrNegotiateLoaderInfo struct is defined in the
 `src/common/loader_interfaces.h` header.  It is used to pass information
 about the loader to a runtime during the negotiation process.  See the
-definition of slink:XrNegotiateLoaderInfo under the 
+definition of slink:XrNegotiateLoaderInfo under the
 <<loader-api-layer-interface-negotiation,layer negotiation>> section for
 more information.
 

specification/loader/source.adoc

@@ -78,7 +78,7 @@ generate the header yourself (preferred), or supply equivalent definitions:
 === Contributing to the Loader ===
 
 Khronos would be pleased if you decided to contribute to the loader
-source code.  
+source code.
 
 [[coding-standard]]
 === Coding Standard ===

src/tests/hello_xr/hello_xr.1

@@ -19,11 +19,11 @@
 .Op Fl v | Fl -verbose
 .Sh DESCRIPTION          \" Section Header - required - don't modify
 .Nm
-is a sample application written using the 
+is a sample application written using the
 .Tn OpenXR
 API.
 .Pp
-The arguments are as follows: 
+The arguments are as follows:
 .Bl -tag -width -indent
 .It Fl h | Fl -help
 Show brief usage instructions.

src/tests/list/openxr_runtime_list.1

@@ -11,7 +11,7 @@
 .Nm
 .Sh DESCRIPTION          \" Section Header - required - don't modify
 .Nm
-is a minimal, command-line application written using the 
+is a minimal, command-line application written using the
 .Tn OpenXR
 API.
 .Pp