spelling fixes (#386)

* spelling fixes

* workaround spelling correction messing up table alignment

Author: rscohn2

oneapi-doc.json

@@ -1,5 +1,5 @@
 {
-    "version": "1.1-provisional-rev-2",
+    "version": "1.1-rev-1",
     "vpl_version": "2.5.0",
-    "art_version": "0.5-rev-1"
+    "art_version": "1.0-rev-1"
 }

source/elements/oneART/source/embree-spec.rst

@@ -197,7 +197,7 @@ See Section `rtcCollide <#rtccollide>`__ for a detailed description of
 how to set up collision detection.
 
 Seen tutorial `Collision Detection <#collision-detection>`__ for a
-complete example of collsion detection being used on a simple cloth
+complete example of collision detection being used on a simple cloth
 solver.
 
 Miscellaneous
@@ -1974,7 +1974,7 @@ array of single precision ``x``, ``y``, ``z`` floating point coordinates
 from the size of that buffer. The vertex buffer can be at most 16 GB
 large.
 
-The parametrization of a triangle uses the first vertex ``p0`` as base
+The parameterization of a triangle uses the first vertex ``p0`` as base
 point, the vector ``p1 - p0`` as u-direction and the vector ``p2 - p0``
 as v-direction. Thus vertex attributes ``t0,t1,t2`` can be linearly
 interpolated over the triangle the following way:
@@ -2053,8 +2053,8 @@ buffer can be at most 16 GB large.
 A quad is internally handled as a pair of two triangles ``v0,v1,v3`` and
 ``v2,v3,v1``, with the ``u'``/``v'`` coordinates of the second triangle
 corrected by ``u = 1-u'`` and ``v = 1-v'`` to produce a quad
-parametrization where ``u`` and ``v`` are in the range 0 to 1. Thus the
-parametrization of a quad uses the first vertex ``p0`` as base point,
+parameterization where ``u`` and ``v`` are in the range 0 to 1. Thus the
+parameterization of a quad uses the first vertex ``p0`` as base point,
 and the vector ``p1 - p0`` as ``u``-direction, and ``p3 - p0`` as
 v-direction. Thus vertex attributes ``t0,t1,t2,t3`` can be bilinearly
 interpolated over the quadrilateral the following way:
@@ -2066,8 +2066,8 @@ interpolated over the quadrilateral the following way:
 Mixed triangle/quad meshes are supported by encoding a triangle as a
 quad, which can be achieved by replicating the last triangle vertex
 (``v0,v1,v2`` -> ``v0,v1,v2,v2``). This way the second triangle is a
-line (which can never get hit), and the parametrization of the first
-triangle is compatible with the standard triangle parametrization.
+line (which can never get hit), and the parameterization of the first
+triangle is compatible with the standard triangle parameterization.
 
 A quad whose vertices are laid out counter-clockwise has its geometry
 normal pointing upwards outside the front face, like illustrated in the
@@ -2297,18 +2297,18 @@ Also see tutorial `Subdivision
 Geometry <tutorials.html#subdivision-geometry>`__ for an example of how
 to create subdivision surfaces.
 
-Parametrization
-^^^^^^^^^^^^^^^
+Parameterization
+^^^^^^^^^^^^^^^^
 
-The parametrization for subdivision faces is different for
+The parameterization for subdivision faces is different for
 quadrilaterals and non-quadrilateral faces.
 
-The parametrization of a quadrilateral face uses the first vertex ``p0``
+The parameterization of a quadrilateral face uses the first vertex ``p0``
 as base point, and the vector ``p1 - p0`` as u-direction and ``p3 - p0``
 as v-direction.
 
-The parametrization for all other face types (with number of vertices
-not equal 4), have a special parametrization where the subpatch ID ``n``
+The parameterization for all other face types (with number of vertices
+not equal 4), have a special parameterization where the subpatch ID ``n``
 (of the ``n``-th quadrilateral that would be obtained by a single
 subdivision step) and the local hit location inside this quadrilateral
 are encoded in the UV coordinates. The following code extracts the
@@ -2515,14 +2515,14 @@ the index buffer (left segment exists if segment(id-1)+1 == segment(id)
 and right segment exists if segment(id+1)-1 == segment(id)).
 
 A left neighbor segment is assumed to end at the start vertex of the
-current segement, and to start at the previous vertex in the vertex
+current segment, and to start at the previous vertex in the vertex
 buffer. Similarly, the right neighbor segment is assumed to start at the
 end vertex of the current segment, and to end at the next vertex in the
 vertex buffer.
 
 Only when the left and right bits are properly specified the current
 segment can properly attach to the left and/or right neighbor, otherwise
-the touching area may not get rendererd properly.
+the touching area may not get rendered properly.
 
 Bézier Basis
 ''''''''''''
@@ -2545,7 +2545,7 @@ through any of the control points directly. A big advantage of this
 basis is that 3 control points can be shared for two continuous
 neighboring curve segments, e.g. the curves (p0,p1,p2,p3) and
 (p1,p2,p3,p4) are C1 continuous. This feature make this basis a good
-choise to construct continuous multi-segment curves, as memory
+choice to construct continuous multi-segment curves, as memory
 consumption can be kept minimal.
 
 Hermite Basis
@@ -2559,7 +2559,7 @@ go through the first and second control point, and the first order
 derivative at the begin and end matches exactly the value specified in
 the tangent buffer. When connecting two segments continuously, the end
 point and tangent of the previous segment can be shared. Different
-versions of Catmull-Rom splines can be easily constructed usig the
+versions of Catmull-Rom splines can be easily constructed using the
 Hermite basis, by calculating a proper tangent buffer from the control
 points.
 
@@ -3776,7 +3776,7 @@ buffers, e.g. ``RTC_FORMAT_UINT3`` for triangle meshes.
 
 The ``RTC_FORMAT_FLOAT/2/3/4...`` format are used to specify that data
 buffers store single precision floating point values, or vectors there
-of (size 2,3,4, etc.). This format is typcally used to specify to format
+of (size 2,3,4, etc.). This format is typically used to specify to format
 of vertex buffers, e.g. the ``RTC_FORMAT_FLOAT3`` type for vertex
 buffers of triangle meshes.
 
@@ -4846,17 +4846,17 @@ be transformed into instance space which can be more efficient. If there
 is no instance transform, the similarity scale is 1.
 
 The callback function will potentially be called for primitives outside
-the query domain for two resons: First, the callback is invoked for all
+the query domain for two reasons: First, the callback is invoked for all
 primitives inside a BVH leaf node since no geometry data of primitives
 is determined internally and therefore individual primitives are not
 culled (only their (aggregated) bounding boxes). Second, in case non
 similarity transformations are used, the resulting ellipsoidal query
 domain (in instance space) is approximated by its axis aligned bounding
 box internally and therefore inner nodes that do not intersect the
 original domain might intersect the approximative bounding box which
-results in unneccessary callbacks. In any case, the callbacks are
+results in unnecessary callbacks. In any case, the callbacks are
 conservative, i.e. if a primitive is inside the query domain a callback
-will be invoked but the reverse is not neccessarily true.
+will be invoked but the reverse is not necessarily true.
 
 For efficiency, the radius of the ``query`` object can be decreased (in
 world space) inside the callback function to improve culling of geometry
@@ -5039,7 +5039,7 @@ For correct results, the transformation matrices for all time steps must
 be set either using ``rtcSetGeometryTransform`` or
 ``rtcSetGeometryTransformQuaternion``. Mixing both representations is
 not allowed. Spherical linear interpolation will be used, iff the
-transformation matizes are set with
+transformation matrices are set with
 ``rtcSetGeometryTransformQuaternion``.
 
 For an example of this feature see the tutorial `Quaternion Motion
@@ -6884,7 +6884,7 @@ For ``rtcIntersect4`` the ray packet must be aligned to 16 bytes, for
 The ``rtcIntersect4``, ``rtcIntersect8`` and ``rtcIntersect16``
 functions may change the ray packet size and ray order when calling back
 into intersect filter functions or user geometry callbacks. Under some
-conditions the application can assume packets to stay intakt, which can
+conditions the application can assume packets to stay intact, which can
 determined by querying the
 ``RTC_DEVICE_PROPERTY_NATIVE_RAY4_SUPPORTED``,
 ``RTC_DEVICE_PROPERTY_NATIVE_RAY8_SUPPORTED``,
@@ -7646,7 +7646,7 @@ reference implementation of point queries with user defined instancing).
 
 The context is an necessary argument to
 `rtcPointQuery <#rtcpointquery>`__ and Embree internally uses the
-topmost instance tranformation of the stack to transform the point query
+topmost instance transformation of the stack to transform the point query
 into instance space.
 
 EXIT STATUS
@@ -7753,7 +7753,7 @@ has to be taken when the instance transformation contains anisotropic
 scaling or sheering. In these cases distance computations have to be
 performed in world space to ensure correctness and the ellipsoidal query
 domain (in instance space) will be approximated with its axis aligned
-bounding box interally. Therefore, the callback function might be
+bounding box internally. Therefore, the callback function might be
 invoked even for primitives in inner BVH nodes that do not intersect the
 query domain. See
 `rtcSetGeometryPointQueryFunction <#rtcsetgeometrypointqueryfunction>`__
@@ -7764,7 +7764,7 @@ The point query structure must be aligned to 16 bytes.
 SUPPORTED PRIMITIVES
 ^^^^^^^^^^^^^^^^^^^^
 
-Currenly, all primitive types are supported by the point query API
+Currently, all primitive types are supported by the point query API
 except of points (see
 `RTC_GEOMETRY_TYPE_POINT <#rtc_geometry_type_point>`__), curves (see
 `RTC_GEOMETRY_TYPE_CURVE <#rtc_geometry_type_curve>`__) and sudivision

source/elements/oneART/source/ispc.rst

@@ -18,7 +18,7 @@ the hardware.
 ISPC compiles a C-based SPMD programming language to run on the 
 SIMD units of CPUs and GPUs; it frequently provides a 3x or more 
 speedup on architectures with 4-wide vector SSE units and 5x-6x on 
-archituctures with 8-wide AVX vector units, without any of the difficulty 
+architectures with 8-wide AVX vector units, without any of the difficulty 
 of writing intrinsics code. Parallelization across multiple cores is 
 also supported by ispc, making it possible to write programs that 
 achieve performance improvement that scales by both number of 

source/elements/oneART/source/oidn-spec.rst

@@ -500,7 +500,7 @@ The albedo image is the feature image that usually provides the biggest quality
 
 [Example albedo image obtained using the first diffuse or glossy (non-delta) hit. Note that the albedos of perfect specular (delta) transparent surfaces are computed as the Fresnel blend of the reflected and transmitted albedos.][imgMazdaAlbedoNonDeltaHit]
 
-For simple matte surfaces this means using the diffuse color/texture as the albedo. For other, more complex surfaces it is not always obvious what is the best way to compute the albedo, but the denoising filter is flexibile to a certain extent and works well with differently computed albedos. Thus it is not necessary to compute the strict, exact albedo values but must be always between 0 and 1.
+For simple matte surfaces this means using the diffuse color/texture as the albedo. For other, more complex surfaces it is not always obvious what is the best way to compute the albedo, but the denoising filter is flexible to a certain extent and works well with differently computed albedos. Thus it is not necessary to compute the strict, exact albedo values but must be always between 0 and 1.
 
 For metallic surfaces the albedo should be either the reflectivity at normal incidence (e.g. from the artist friendly metallic Fresnel model) or the average reflectivity; or if these are constant (not textured) or unknown, the albedo can be simply 1 as well.
 

source/elements/oneART/source/openvkl-spec.rst

@@ -710,7 +710,7 @@ VDB volume objects support the following observers:
    +-----------+-------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
    | Name      | Buffer Type | Description                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                        |
    +===========+=============+====================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================+
-   | InnerNode | float[]     | Return an array of bounding boxes, along with value ranges, of inner nodes in the data structure. The bounding box is given in object space. For a volume with M attributes, the entries in this array are (6+2*M)-tuples ``(minX, minY, minZ, maxX, maxY, maxZ, lower_0, upper_0, lower_1, upper_1, ...)``. This is in effect a low resolution representation of the volume. The InnerNode observer can be parametrized using ``int maxDepth`` to control the depth at which inner nodes are returned. Note that the observer will also return leaf nodes or tiles at lower levels if they exist. |
+   | InnerNode | float[]     | Return an array of bounding boxes along with value ranges, of inner nodes in the data structure. The bounding box is given in object space. For a volume with M attributes, the entries in this array are (6+2*M)-tuples ``(minX, minY, minZ, maxX, maxY, maxZ, lower_0, upper_0, lower_1, upper_1, ...)``. This is in effect a low resolution representation of the volume. The InnerNode observer can be parameterized using ``int maxDepth`` to control the depth at which inner nodes are returned. Note that the observer will also return leaf nodes or tiles at lower levels if they exist. |
    +-----------+-------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
 
 VDB sampler objects support the following observers:

source/elements/oneART/source/ospray-spec.rst

@@ -1154,7 +1154,7 @@ The emission side is determined by the cross product of ``edge1``\ ×\ ``edge2``
 Cylinder Light
 ~~~~~~~~~~~~~~
 
-The cylinder light is a cylinderical, procedural area light source emitting uniformly outwardly into the space beyond the boundary. It is created by passing the type string “``cylinder``” to ``ospNewLight``. The cylinder light supports ``OSP_INTENSITY_QUANTITY_POWER``, ``OSP_INTENSITY_QUANTITY_INTENSITY`` and ``OSP_INTENSITY_QUANTITY_RADIANCE`` (default) as ``intensityQuantity`` parameter. In addition to the `general parameters <#lights>`__ understood by all lights the cylinder light supports the following special parameters:
+The cylinder light is a cylindrical, procedural area light source emitting uniformly outwardly into the space beyond the boundary. It is created by passing the type string “``cylinder``” to ``ospNewLight``. The cylinder light supports ``OSP_INTENSITY_QUANTITY_POWER``, ``OSP_INTENSITY_QUANTITY_INTENSITY`` and ``OSP_INTENSITY_QUANTITY_RADIANCE`` (default) as ``intensityQuantity`` parameter. In addition to the `general parameters <#lights>`__ understood by all lights the cylinder light supports the following special parameters:
 
 .. table:: Special parameters accepted by the cylinder light.
 

source/elements/oneVPL/include/vpl/mfxsurfacepool.h

@@ -37,7 +37,7 @@ typedef struct {
     */
     mfxU32                    DeltaToAllocateOnTheFly;  
     union {
-        mfxVPPPoolType            VPPPoolType; /*!< Defines what VPP pool is targeted - input or ouput. Ignored for other components. */
+        mfxVPPPoolType            VPPPoolType; /*!< Defines what VPP pool is targeted - input or output. Ignored for other components. */
         mfxU32                    reserved;
     };
     mfxU32                    Wait; /*!< Time in milliseconds for GetSurfaceForXXX() and DecodeFrameAsync functions to wait until surface will be available. */

source/elements/oneVPL/source/API_ref/VPL_disp_api_def.rst

@@ -27,7 +27,7 @@ MFX_STRFIELD_LEN
 .. doxygendefine:: MFX_STRFIELD_LEN
    :project: oneVPL
 
-Helper macro defintions to add property with single value.
+Helper macro definitions to add property with single value.
 
 MFX_ADD_PROPERTY_U32
 --------------------
@@ -44,7 +44,7 @@ MFX_ADD_PROPERTY_PTR
 .. doxygendefine:: MFX_ADD_PROPERTY_PTR
    :project: oneVPL
 
-Helper macro defintions to update existing property.
+Helper macro definitions to update existing property.
 
 MFX_UPDATE_PROPERTY_U32
 -----------------------
@@ -59,4 +59,4 @@ MFX_UPDATE_PROPERTY_U16
 MFX_UPDATE_PROPERTY_PTR
 -----------------------
 .. doxygendefine:: MFX_UPDATE_PROPERTY_PTR
-   :project: oneVPL
+   :project: oneVPL

source/elements/oneVPL/source/programming_guide/VPL_prg_decoding.rst

@@ -78,7 +78,7 @@ release working surface after :cpp:func:`MFXVideoDECODE_DecodeFrameAsync` call.
                  reference counter of working surface returned by 
                  :cpp:func:`MFXMemory_GetSurfaceForDecode`.
                  After :cpp:func:`MFXVideoCORE_SyncOperation` to decrease
-                 reference counter of ouput surface returned by 
+                 reference counter of output surface returned by 
                  :cpp:func:`MFXVideoDECODE_DecodeFrameAsync`.
 
 .. literalinclude:: ../snippets/prg_decoding.c