From 0920ab5e7c8e23fa558d862e8f9d6f529cba95b0 Mon Sep 17 00:00:00 2001 From: Petr Kraus Date: Mon, 11 Dec 2017 20:02:07 +0100 Subject: [PATCH] Fix some quotes and apostrophes --- .../vulkan/appendices/VK_EXT_discard_rectangles.txt | 6 +++--- doc/specs/vulkan/appendices/VK_EXT_display_control.txt | 2 +- .../vulkan/appendices/VK_EXT_swapchain_colorspace.txt | 3 ++- doc/specs/vulkan/appendices/VK_KHR_bind_memory2.txt | 2 +- doc/specs/vulkan/appendices/VK_KHR_swapchain.txt | 2 +- .../vulkan/appendices/VK_NV_clip_space_w_scaling.txt | 4 ++-- .../appendices/VK_NV_framebuffer_mixed_samples.txt | 4 ++-- .../appendices/VK_NV_geometry_shader_passthrough.txt | 4 ++-- doc/specs/vulkan/appendices/VK_NV_viewport_swizzle.txt | 3 +-- doc/specs/vulkan/appendices/boilerplate.txt | 2 +- doc/specs/vulkan/appendices/glossary.txt | 10 +++++----- doc/specs/vulkan/chapters/VK_EXT_hdr_metadata.txt | 2 +- doc/specs/vulkan/chapters/VK_KHR_display/display.txt | 6 +++--- doc/specs/vulkan/chapters/cmdbuffers.txt | 6 +++--- doc/specs/vulkan/chapters/extensions.txt | 8 ++++---- doc/specs/vulkan/chapters/fundamentals.txt | 10 +++++----- doc/specs/vulkan/chapters/fxvertex.txt | 8 ++++---- doc/specs/vulkan/chapters/initialization.txt | 4 ++-- doc/specs/vulkan/chapters/interfaces.txt | 4 ++-- doc/specs/vulkan/chapters/introduction.txt | 2 +- doc/specs/vulkan/chapters/renderpass.txt | 6 +++--- doc/specs/vulkan/chapters/resources.txt | 2 +- doc/specs/vulkan/chapters/samplers.txt | 2 +- doc/specs/vulkan/chapters/sparsemem.txt | 2 +- doc/specs/vulkan/chapters/vertexpostproc.txt | 4 ++-- 25 files changed, 54 insertions(+), 54 deletions(-) diff --git a/doc/specs/vulkan/appendices/VK_EXT_discard_rectangles.txt b/doc/specs/vulkan/appendices/VK_EXT_discard_rectangles.txt index 67830845..ffe8a1d8 100644 --- a/doc/specs/vulkan/appendices/VK_EXT_discard_rectangles.txt +++ b/doc/specs/vulkan/appendices/VK_EXT_discard_rectangles.txt @@ -6,9 +6,9 @@ include::meta/VK_EXT_discard_rectangles.txt[] - Daniel Koch, NVIDIA - Jeff Bolz, NVIDIA -This extension provides additional orthogonally aligned "discard rectangles" -specified in framebuffer-space coordinates that restrict rasterization of -all points, lines and triangles. +This extension provides additional orthogonally aligned "`discard +rectangles`" specified in framebuffer-space coordinates that restrict +rasterization of all points, lines and triangles. From zero to an implementation-dependent limit (specified by pname:maxDiscardRectangles) number of discard rectangles can be operational diff --git a/doc/specs/vulkan/appendices/VK_EXT_display_control.txt b/doc/specs/vulkan/appendices/VK_EXT_display_control.txt index 301c7083..93cf0d61 100644 --- a/doc/specs/vulkan/appendices/VK_EXT_display_control.txt +++ b/doc/specs/vulkan/appendices/VK_EXT_display_control.txt @@ -44,7 +44,7 @@ This extension defines a set of utility functions for use with the === Issues -1) Should this extension add an explicit "WaitForVsync" API or a fence +1) Should this extension add an explicit "`WaitForVsync`" API or a fence signaled at vsync that the application can wait on? *RESOLVED*: A fence. diff --git a/doc/specs/vulkan/appendices/VK_EXT_swapchain_colorspace.txt b/doc/specs/vulkan/appendices/VK_EXT_swapchain_colorspace.txt index c22068b2..c5cea963 100644 --- a/doc/specs/vulkan/appendices/VK_EXT_swapchain_colorspace.txt +++ b/doc/specs/vulkan/appendices/VK_EXT_swapchain_colorspace.txt @@ -36,7 +36,8 @@ include::meta/VK_EXT_swapchain_colorspace.txt[] space and applies a linear OETF. ** ename:VK_COLOR_SPACE_ADOBERGB_NONLINEAR_EXT - supports the AdobeRGB color space and applies the Gamma 2.2 OETF. - ** ename:VK_COLOR_SPACE_PASS_THROUGH_EXT - color components used "as is". + ** ename:VK_COLOR_SPACE_PASS_THROUGH_EXT - color components used "`as + is`". Intended to allow application to supply data for color spaces not described here. diff --git a/doc/specs/vulkan/appendices/VK_KHR_bind_memory2.txt b/doc/specs/vulkan/appendices/VK_KHR_bind_memory2.txt index 01ef99fd..f16e95e6 100644 --- a/doc/specs/vulkan/appendices/VK_KHR_bind_memory2.txt +++ b/doc/specs/vulkan/appendices/VK_KHR_bind_memory2.txt @@ -17,7 +17,7 @@ flink:vkBindImageMemory that allow multiple bindings to be performed at once, and are extensible. This extension also introduces ename:VK_IMAGE_CREATE_ALIAS_BIT_KHR, which -allows "identical" images that alias the same memory to interpret the +allows "`identical`" images that alias the same memory to interpret the contents consistently, even across image layout changes. === New Object Types diff --git a/doc/specs/vulkan/appendices/VK_KHR_swapchain.txt b/doc/specs/vulkan/appendices/VK_KHR_swapchain.txt index 69e852a6..47c1271d 100644 --- a/doc/specs/vulkan/appendices/VK_KHR_swapchain.txt +++ b/doc/specs/vulkan/appendices/VK_KHR_swapchain.txt @@ -296,7 +296,7 @@ Since etext:MIRROR_NONE must be a bit in the bitmask rather than a bitmask with no values set, allowing more than one bit to be set in the bitmask would make it possible to describe undefined transforms such as etext:VK_MIRROR_NONE_BIT | etext:VK_MIRROR_HORIZONTAL_BIT, or a transform -that includes both "`no mirroring`" and "`horizontal mirroring +that includes both "`no mirroring`" and "`horizontal mirroring`" simultaneously. Therefore, it is desirable to allow specifying all supported mirroring transforms using only one bit. diff --git a/doc/specs/vulkan/appendices/VK_NV_clip_space_w_scaling.txt b/doc/specs/vulkan/appendices/VK_NV_clip_space_w_scaling.txt index 416d2404..dad8d7b7 100644 --- a/doc/specs/vulkan/appendices/VK_NV_clip_space_w_scaling.txt +++ b/doc/specs/vulkan/appendices/VK_NV_clip_space_w_scaling.txt @@ -7,8 +7,8 @@ include::meta/VK_NV_clip_space_w_scaling.txt[] - Kedarnath Thangudu, NVIDIA Virtual Reality (VR) applications often involve a post-processing step to -apply a "barrel" distortion to the rendered image to correct the -"pincushion" distortion introduced by the optics in a VR device. +apply a "`barrel`" distortion to the rendered image to correct the +"`pincushion`" distortion introduced by the optics in a VR device. The barrel distorted image has lower resolution along the edges compared to the center. Since the original image is rendered at high resolution, which is uniform diff --git a/doc/specs/vulkan/appendices/VK_NV_framebuffer_mixed_samples.txt b/doc/specs/vulkan/appendices/VK_NV_framebuffer_mixed_samples.txt index d93762a2..98683dd7 100644 --- a/doc/specs/vulkan/appendices/VK_NV_framebuffer_mixed_samples.txt +++ b/doc/specs/vulkan/appendices/VK_NV_framebuffer_mixed_samples.txt @@ -8,10 +8,10 @@ include::meta/VK_NV_framebuffer_mixed_samples.txt[] This extension allows multisample rendering with a raster and depth/stencil sample count that is larger than the color sample count. Rasterization and the results of the depth and stencil tests together -determine the portion of a pixel that is "covered". +determine the portion of a pixel that is "`covered`". It can be useful to evaluate coverage at a higher frequency than color samples are stored. -This coverage is then "reduced" to a collection of covered color samples, +This coverage is then "`reduced`" to a collection of covered color samples, each having an opacity value corresponding to the fraction of the color sample covered. The opacity can optionally be blended into individual color samples. diff --git a/doc/specs/vulkan/appendices/VK_NV_geometry_shader_passthrough.txt b/doc/specs/vulkan/appendices/VK_NV_geometry_shader_passthrough.txt index 74ecfb17..b4dbbe7c 100644 --- a/doc/specs/vulkan/appendices/VK_NV_geometry_shader_passthrough.txt +++ b/doc/specs/vulkan/appendices/VK_NV_geometry_shader_passthrough.txt @@ -20,7 +20,7 @@ This extension adds support for the following SPIR-V extension in Vulkan: Geometry shaders provide the ability for applications to process each primitive sent through the graphics pipeline using a programmable shader. -However, one common use case treats them largely as a "passthrough". +However, one common use case treats them largely as a "`passthrough`". In this use case, the bulk of the geometry shader code simply copies inputs from each vertex of the input primitive to corresponding outputs in the vertices of the output primitive. @@ -144,7 +144,7 @@ void main() In this shader, the inputs code:gl_Position, code:Inputs.texcoord, and code:Inputs.baseColor are simply copied from the input vertex to the corresponding output vertex. -The only "interesting" work done by the geometry shader is computing and +The only "`interesting`" work done by the geometry shader is computing and emitting a code:gl_Layer value for the primitive. The following geometry shader, using this extension, is equivalent: diff --git a/doc/specs/vulkan/appendices/VK_NV_viewport_swizzle.txt b/doc/specs/vulkan/appendices/VK_NV_viewport_swizzle.txt index 2b178aaf..35f8b971 100644 --- a/doc/specs/vulkan/appendices/VK_NV_viewport_swizzle.txt +++ b/doc/specs/vulkan/appendices/VK_NV_viewport_swizzle.txt @@ -20,11 +20,10 @@ single-pass cubemap rendering (broadcasting a primitive to multiple faces and reorienting the vertex position for each face) and voxel rasterization. The per-viewport component remapping and negation provided by the swizzle allows application code to re-orient three-dimensional geometry with a view -the "Issues" section below. along any of the *X*, *Y*, or *Z* axes. If a perspective projection and depth buffering is required, [eq]#1/W# buffering should be used, as described in the single-pass cubemap rendering -example in +example in the "`Issues`" section below. === New Object Types diff --git a/doc/specs/vulkan/appendices/boilerplate.txt b/doc/specs/vulkan/appendices/boilerplate.txt index f5350813..15f3fc65 100644 --- a/doc/specs/vulkan/appendices/boilerplate.txt +++ b/doc/specs/vulkan/appendices/boilerplate.txt @@ -328,7 +328,7 @@ This macro controls calling conventions for MSVC-style compilers. // @refBegin VKAPI_PTR Vulkan function pointer calling conventions -dname:VKAPI_PTR is a macro placed between the '(' and '*' in Vulkan API +dname:VKAPI_PTR is a macro placed between the "`(`" and "`*`" in Vulkan API function pointer declarations. This macro also controls calling conventions, and typically has the same definition as dname:VKAPI_ATTR or dname:VKAPI_CALL, depending on the diff --git a/doc/specs/vulkan/appendices/glossary.txt b/doc/specs/vulkan/appendices/glossary.txt index dcbca6e6..97b2c2ad 100644 --- a/doc/specs/vulkan/appendices/glossary.txt +++ b/doc/specs/vulkan/appendices/glossary.txt @@ -376,9 +376,9 @@ Executable State (Command Buffer):: See also Initial State and Recording State. Execution Dependency:: - A dependency that guarantees that certain pipeline stages' work for a + A dependency that guarantees that certain pipeline stages`' work for a first set of commands has completed execution before certain pipeline - stages' work for a second set of commands begins execution. + stages`' work for a second set of commands begins execution. This is accomplished via pipeline barriers, subpass dependencies, events, or implicit ordering operations. @@ -464,9 +464,9 @@ Framebuffer Attachment:: One of the image views used in a framebuffer. Framebuffer Coordinates:: - A coordinate system in which adjacent pixels' coordinates differ by 1 in - x and/or y, with [eq]#(0,0)# in the upper left corner and pixel centers - at half-integers. + A coordinate system in which adjacent pixels`' coordinates differ by 1 + in x and/or y, with [eq]#(0,0)# in the upper left corner and pixel + centers at half-integers. Framebuffer-Space:: Operating with respect to framebuffer coordinates. diff --git a/doc/specs/vulkan/chapters/VK_EXT_hdr_metadata.txt b/doc/specs/vulkan/chapters/VK_EXT_hdr_metadata.txt index 1a38a5ff..bb1b81d7 100644 --- a/doc/specs/vulkan/chapters/VK_EXT_hdr_metadata.txt +++ b/doc/specs/vulkan/chapters/VK_EXT_hdr_metadata.txt @@ -36,7 +36,7 @@ include::../validity/protos/vkSetHdrMetadataEXT.txt[] -- include::../api/structs/VkXYColorEXT.txt[] Chromaticity coordinates x and y are as specified in CIE 15:2004 -"Calculation of chromaticity coordinates" (Section 7.3) and are limited to +"`Calculation of chromaticity coordinates`" (Section 7.3) and are limited to between 0 and 1 for real colors for the mastering display. -- diff --git a/doc/specs/vulkan/chapters/VK_KHR_display/display.txt b/doc/specs/vulkan/chapters/VK_KHR_display/display.txt index bb305e0b..55376f1e 100644 --- a/doc/specs/vulkan/chapters/VK_KHR_display/display.txt +++ b/doc/specs/vulkan/chapters/VK_KHR_display/display.txt @@ -346,8 +346,8 @@ include::../../validity/structs/VkDisplayModeCreateInfoKHR.txt[] -- Applications that wish to present directly to a display must: select which -layer, or "plane" of the display they wish to target, and a mode to use with -the display. +layer, or "`plane`" of the display they wish to target, and a mode to use +with the display. Each display supports at least one plane. The capabilities of a given mode and plane combination are determined by calling: @@ -407,7 +407,7 @@ possible positions and sizes may: be used to specify the region within the presentable images that source pixels will be read from when creating a swapchain on the specified display mode and plane. -Vendors may: also support mapping the presentable images' content to a +Vendors may: also support mapping the presentable images`' content to a subset or superset of the visible region in the specified display mode. This is expressed by returning pname:minDstPosition, pname:maxDstPosition, pname:minDstExtent and pname:maxDstExtent values that indicate a range of diff --git a/doc/specs/vulkan/chapters/cmdbuffers.txt b/doc/specs/vulkan/chapters/cmdbuffers.txt index bb192b1d..8879fefa 100644 --- a/doc/specs/vulkan/chapters/cmdbuffers.txt +++ b/doc/specs/vulkan/chapters/cmdbuffers.txt @@ -247,7 +247,7 @@ accumulate. In this situation, trimming a command pool may: be useful to return unused memory back to the system, returning the total outstanding memory allocated -by the pool back to a more "average" value. +by the pool back to a more "`average`" value. Implementations utilize many internal allocation strategies that make it impossible to guarantee that all unused memory is released back to the @@ -259,13 +259,13 @@ a bulk allocation would prevent that allocation from being freed, even if only a small proportion of the bulk allocation is in use. In most cases trimming will result in a reduction in allocated but unused -memory, but it does not guarantee the "ideal" behaviour. +memory, but it does not guarantee the "`ideal`" behaviour. Trimming may: be an expensive operation, and should: not be called frequently. Trimming should: be treated as a way to relieve memory pressure after application-known points when there exists enough unused memory that the -cost of trimming is "worth" it. +cost of trimming is "`worth`" it. ==== include::../validity/protos/vkTrimCommandPoolKHR.txt[] diff --git a/doc/specs/vulkan/chapters/extensions.txt b/doc/specs/vulkan/chapters/extensions.txt index 38277afc..07280d72 100644 --- a/doc/specs/vulkan/chapters/extensions.txt +++ b/doc/specs/vulkan/chapters/extensions.txt @@ -48,8 +48,8 @@ This is generally discouraged, as it increases the probability of incompatibilities with new extensions. The validation layers wrap handles in order to track the proper use and destruction of each object. -See the <> document for additional information. +See the <> document for additional information. [open,refpage='vkEnumerateInstanceLayerProperties',desc='Returns up to requested number of global layer properties',type='protos'] -- @@ -215,8 +215,8 @@ extension authors should: add support for their extensions to the Khronos validation layers. This is especially important for new commands whose parameters have been wrapped by the validation layers. -See the <> document for additional information. +See the <> document for additional information. [open,refpage='vkEnumerateInstanceExtensionProperties',desc='Returns up to requested number of global extension properties',type='protos'] -- diff --git a/doc/specs/vulkan/chapters/fundamentals.txt b/doc/specs/vulkan/chapters/fundamentals.txt index 90164f76..8551e02e 100644 --- a/doc/specs/vulkan/chapters/fundamentals.txt +++ b/doc/specs/vulkan/chapters/fundamentals.txt @@ -458,8 +458,8 @@ defining <> appropriately in +vk_platform.h+. On platforms where Vulkan is provided as a shared library, library symbols -beginning with 'vk' and followed by a digit or uppercase letter are reserved -for use by the implementation. +beginning with "`vk`" and followed by a digit or uppercase letter are +reserved for use by the implementation. Applications which use Vulkan must: not provide definitions of these symbols. This allows the Vulkan shared library to be updated with additional symbols @@ -1108,9 +1108,9 @@ Hopefully it can: be tightened up considerably. ==== endif::editing-notes[] -We require simply that numbers' floating-point parts contain enough bits and -that their exponent fields are large enough so that individual results of -floating-point operations are accurate to about 1 part in 10^5^. +We require simply that numbers`' floating-point parts contain enough bits +and that their exponent fields are large enough so that individual results +of floating-point operations are accurate to about 1 part in 10^5^. The maximum representable magnitude for all floating-point values must: be at least 2^32^. diff --git a/doc/specs/vulkan/chapters/fxvertex.txt b/doc/specs/vulkan/chapters/fxvertex.txt index 89f7dce7..3dcbc07b 100644 --- a/doc/specs/vulkan/chapters/fxvertex.txt +++ b/doc/specs/vulkan/chapters/fxvertex.txt @@ -133,7 +133,7 @@ as described <>. | four-component vector | 0 or unspecified | (x, y, z, w) |==== -Components indicated by `o' are available for use by other input variables +Components indicated by "`o`" are available for use by other input variables which are sourced from the same attribute, and if used, are either filled with the corresponding component from the input format (if present), or the default value. @@ -165,7 +165,7 @@ The code:Component decoration must: not be used with matrix types. | mat4 | four-component vector | i, i+1, i+2, i+3 | (x, y, z, w), (x, y, z, w), (x, y, z, w), (x, y, z, w) |==== -Components indicated by `o' are available for use by other input variables +Components indicated by "`o`" are available for use by other input variables which are sourced from the same attribute, and if used, are either filled with the corresponding component from the input (if present), or the default value. @@ -226,9 +226,9 @@ component of 1 or 3. | four-component vector | i | unspecified | (x, y, z, w), (x, y, z, w) |==== -Components indicated by `o' are available for use by other input variables +Components indicated by "`o`" are available for use by other input variables which are sourced from the same attribute. -Components indicated by `-' are not available for input variables as there +Components indicated by "`-`" are not available for input variables as there are no default values provided for 64-bit data types, and there is no data provided by the input format. diff --git a/doc/specs/vulkan/chapters/initialization.txt b/doc/specs/vulkan/chapters/initialization.txt index 4aedb4ad..e0da1e83 100644 --- a/doc/specs/vulkan/chapters/initialization.txt +++ b/doc/specs/vulkan/chapters/initialization.txt @@ -33,8 +33,8 @@ commands as well; if this is done, then applications that use only the core Vulkan commands have no need to use fname:vkGetInstanceProcAddr. The table below defines the various use cases for -fname:vkGetInstanceProcAddr and expected return value ("fp" is function -pointer) for each case. +fname:vkGetInstanceProcAddr and expected return value ("`fp`" is "`function +pointer`") for each case. The returned function pointer is of type tlink:PFN_vkVoidFunction, and must be cast to the type of the command being queried. diff --git a/doc/specs/vulkan/chapters/interfaces.txt b/doc/specs/vulkan/chapters/interfaces.txt index e612807e..bcb5e5fe 100644 --- a/doc/specs/vulkan/chapters/interfaces.txt +++ b/doc/specs/vulkan/chapters/interfaces.txt @@ -752,7 +752,7 @@ resources. [[interfaces-resources-layout-std140]] *Standard Uniform Buffer Layout* -The 'base alignment' of the type of an code:OpTypeStruct member of is +The _base alignment_ of the type of an code:OpTypeStruct member of is defined recursively as follows: * A scalar of size [eq]#N# has a base alignment of [eq]#N#. @@ -771,7 +771,7 @@ defined recursively as follows: ifdef::VK_KHR_relaxed_block_layout[] -A member is defined to 'improperly straddle' if either of the following are +A member is defined to _improperly straddle_ if either of the following are true: * It is a vector with total size less than or equal to 16 bytes, and has diff --git a/doc/specs/vulkan/chapters/introduction.txt b/doc/specs/vulkan/chapters/introduction.txt index 98d67575..d8ad5df8 100644 --- a/doc/specs/vulkan/chapters/introduction.txt +++ b/doc/specs/vulkan/chapters/introduction.txt @@ -103,7 +103,7 @@ Pages`" or "`Registry`", to help us triage and assign them appropriately. Unfortunately, GitHub does not currently let users who do not have write access to the repository set GitHub labels on issues. In the meantime, they can: be added to the title line of the issue set in -brackets, e.g. ''[Specification]''. +brackets, e.g. "`[Specification]`". [[introduction-terminology]] diff --git a/doc/specs/vulkan/chapters/renderpass.txt b/doc/specs/vulkan/chapters/renderpass.txt index 2cdd3787..36a039a9 100644 --- a/doc/specs/vulkan/chapters/renderpass.txt +++ b/doc/specs/vulkan/chapters/renderpass.txt @@ -1113,9 +1113,9 @@ A view-global dependency between two multiview subpasses acts like a set of the source and destination. Thus, it is a more compact representation which also makes clear the commonality and reuse that is present between views in a subpass. -This interpretation motivates the answers to questions like "when does the -load op apply" - it is on the first use of each view of an attachment, as if -each view were a separate attachment. +This interpretation motivates the answers to questions like "`when does the +load op apply`" - it is on the first use of each view of an attachment, as +if each view were a separate attachment. ==== endif::VK_KHX_multiview[] diff --git a/doc/specs/vulkan/chapters/resources.txt b/doc/specs/vulkan/chapters/resources.txt index e1dae46d..32a6bcdd 100644 --- a/doc/specs/vulkan/chapters/resources.txt +++ b/doc/specs/vulkan/chapters/resources.txt @@ -3812,7 +3812,7 @@ report a value of one. .Note ==== Despite its name, pname:bufferImageGranularity is really a granularity -between "linear" and "non-linear" resources. +between "`linear`" and "`non-linear`" resources. ==== Given resourceA at the lower memory offset and resourceB at the higher diff --git a/doc/specs/vulkan/chapters/samplers.txt b/doc/specs/vulkan/chapters/samplers.txt index c0657eb8..1c97fa0a 100644 --- a/doc/specs/vulkan/chapters/samplers.txt +++ b/doc/specs/vulkan/chapters/samplers.txt @@ -629,7 +629,7 @@ slink:VkSamplerYcbcrConversionCreateInfoKHR::pname:components). [NOTE] .Note ==== -For example, an "YUVA" 32-bit format comprising four 8-bit channels can be +For example, an "`YUVA`" 32-bit format comprising four 8-bit channels can be implemented as ename:VK_FORMAT_R8G8B8A8_UNORM with a component mapping: * pname:components.a = ename:VK_COMPONENT_SWIZZLE_IDENTITY diff --git a/doc/specs/vulkan/chapters/sparsemem.txt b/doc/specs/vulkan/chapters/sparsemem.txt index 0441dabd..a575e965 100644 --- a/doc/specs/vulkan/chapters/sparsemem.txt +++ b/doc/specs/vulkan/chapters/sparsemem.txt @@ -524,7 +524,7 @@ ifdef::implementation-guide[] **** This section is Informative. -It is included to aid in implementors' understanding of sparse resources. +It is included to aid in implementors`' understanding of sparse resources. .Device Virtual Address diff --git a/doc/specs/vulkan/chapters/vertexpostproc.txt b/doc/specs/vulkan/chapters/vertexpostproc.txt index 8295366e..054a18a4 100644 --- a/doc/specs/vulkan/chapters/vertexpostproc.txt +++ b/doc/specs/vulkan/chapters/vertexpostproc.txt @@ -304,8 +304,8 @@ the boundary of the clip volume. This clipping produces a value, [eq]#0 {leq} t {leq} 1#, for each clipped vertex. If the coordinates of a clipped vertex are [eq]#**P**# and the original -vertices' coordinates are [eq]#**P**~1~# and [eq]#**P**~2~#, then [eq]#t# is -given by +vertices`' coordinates are [eq]#**P**~1~# and [eq]#**P**~2~#, then [eq]#t# +is given by :: [eq]#**P** = t **P**~1~ {plus} (1-t) **P**~2~#.