Vulkan-Docs/style/misc.txt

116 lines
4.8 KiB
Plaintext
Raw Normal View History

Change log for March 16, 2018 Vulkan 1.1.71 spec update: * First public update for Vulkan 1.1. Github Issues: * Refer to standard sparse image block shape format tables explicitly in the <<sparsememory-standard-shapes, Standard Sparse Image Block Shapes>> section (public issue 93). * Add the missing definition of the code:LocalInvocationIndex decoration in the <<interfaces-builtin-variables, Built-In Variables>> section (public issue 532). * Clarify dynamic state definition in the introduction to the <<pipelines, Pipelines>> section and the new <<pipelines-dynamic-state, Dynamic State>> subsection (public issue 620). * Clarified deprecation statement in the `VK_AMD_negative_viewport_height` appendix (public issue 674). * Fix parameter descriptions for flink:vkCreateIndirectCommandsLayoutNVX (public issue 677). Internal Issues: * Remove description of <<primsrast-points, rasterization point size>> being taken from the tessellation control shader, since there are no circumstances under which you can have TCS without TES (internal issue 522). * Define <<copies-images-format-size-compatibility, _size-compatible_ image formats>> for flink:vkCmdCopyImage, add it to the glossary, and use that definition for slink:VkImageViewCreateInfo (internal issue 771). * Change brief descriptions of enumerant names, and of parameters which are enumerants, from "`enum *indicates*`" to "`enum *specifies*`" for consistency, and add a markup style guide rule (internal issue 862). * Clarify how execution dependencies interact with <<synchronization-submission-order, submission order>> at numerous places in the <<renderpass, Render Pass>> and <<synchronization, Synchronization>> chapters (internal issue 1062). * Clarify statement in the <<interfaces-resources-setandbinding, DescriptorSet and Binding Assignment>> section that only interface variables statically used by the entry point used in a pipeline must be present in the descriptor set layout (internal issue 1172). * Flip sparse image diagrams with partially full mip levels vertically, to match graph origins of other image diagrams (internal issue 1176). * Update new SVG diagrams to have consistent style and base font size, increase consistency of primitive topology diagrams, and add a section to the style guide on creating and editing images in a consistent style (internal issue 1177). * Resolve problems with valid usage statement extraction by fixing existing VUID tags for interfaces promoted to version 1.1 and fixing conditional directives around VUID-VkMemoryDedicatedAllocateInfo-image-01797 (internal issue 1184). * Strip `KHR` suffixes from a few interfaces promoted to Vulkan 1.1 that were missed previously (internal issue 1185). * Restrict code:OpImageQuerySizeLod and code:OpImageQueryLevels to only work on code:Image operands with their code:Sampled operand set to 1. In other words, these operations are not defined to work with storage images (internal issue 1193). * Recycle extension slot for extension #82 in `vk.xml`. This extension was never published (internal issue 1195). * Add an issue to the `VK_KHR_maintenance1` appendix noting that zero height viewports are allowed when this extension is enabled (internal issue 1202). * Fix slink:VkDescriptorSetLayoutBinding description so that shader stages always use descriptor bindings, not the other way around (internal issue 1206). * Fix field name for slink:VkInputAttachmentAspectReference::pname:inputAttachmentIndex (internal issue 1210). Other Issues: * Fix a few broken links in the <<versions-1.1, Version 1.1>> appendix. * Replace a few old refBegin/refEnd tags with open block markup around interfaces, and remove old KHX VUID tags that were breaking the valid usage statement extraction. * Fix error codes accidentally tagged as success codes in `vk.xml` for flink:vkGetSwapchainCounterEXT. * Added valid usage statements for ftext:vkBind*Memory2 input structures stext:VkBind*MemoryInfo, and fix a pname:image -> pname:buffer typo in a couple of places. * Fix swapped descriptions of elink:VkDescriptorType enums ename:VK_DESCRIPTOR_TYPE_SAMPLED_IMAGE and ename:VK_DESCRIPTOR_TYPE_STORAGE_IMAGE (reported via tweet). New Extensions: * `VK_ANDROID_external_memory_android_hardware_buffer`
2018-03-17 11:04:05 +00:00
// Copyright (c) 2015-2018 Khronos Group. This work is licensed under a
// Creative Commons Attribution 4.0 International License; see
// http://creativecommons.org/licenses/by/4.0/
[[miscellaneous]]
= Image Authoring, Formats, and Style
Images used in the Vulkan documents must be kept in the directory `images/`
in SVG format.
Images should be authored in the open-source
https://inkscape.org/[`Inkscape`] tool, downloadable from its website or
packaged as an optional install for most Linux distributions.
This allows other people to easily edit your images in the future.
Also, while SVG is in principle a portable image format, some proprietary
image editors have been observed to produce images incompatible with the PDF
image pipeline used by the Specification.
Images must be authored at their actual image size in the HTML and PDF
output documents, and must not be scaled with asciidoctor options.
In most cases, images are included as standalone figures and should occupy
the full width of the document - don't leave unnecessary whitespace on
either side of the image.
The PDF output has an available width of just over 660px (at the default
96dpi), and a height somewhere around 1000px (which diagrams should really
go nowhere near anyway).
The html output is wider (800 pixels) and with practically unlimited height.
As the PDF dimensions are more restrictive, images should not exceed these
limits.
[NOTE]
.Note
====
According to the documentation available, the PDF output *should* have
dimensions of roughly 184mm x 271mm - or equivalently 697px x 1026px (A4
size [asciidoctor default] with a 0.5in margin [prawn-pdf default] on each
side).
However for reasons currently unknown, at least the available width before
images are scaled down lies is about 30-something pixels lower than that;
the height where this happens hasn't been measured, but is likely to
similarly be lower than it should be for reasons currently unknown.
====
Dimensions of elements in the SVG file should be authored in pixels (`px`)
such that lines/strokes are not unnecessarily anti-aliased (e.g. usually
stick to integer pixel widths for lines).
In many cases it is useful to also set the background grid to px, but it not
necessary; Inkscape has reliable conversions between px and mm using a
default dpi of 96 (which matches the PDF output), so the output dimension is
mostly irrelevant.
Text in images should usually appear at 12 point type so as to match that in
the body of the specification, though 10 point text can be used sparingly
where necessary (however this is often indicative of the diagram being too
cramped, so authors should consider scaling or reworking the diagram
instead).
Text should use the built-in generic sans serif font so as to ensure the
font in the output document matches whatever sans serif font is used for
that document.
Note that the character set is currently <<character-sets-in-svg,restricted
to Windows-1252>>.
The font and color scheme used for existing images (black, red, and 50%
gray) should be used for changes and new images whenever reasonable to do
so, to preserve a consistent look and feel.
Whilst a white background is typically assumed, explicitly adding white as a
color should be avoided - instead leave elements transparent so the diagrams
can be used in other documents.
Many other elements are consistent throughout the set of diagrams which
should be maintained in new diagrams where possible.
Examples include:
* Lines are usually either fully solid, or use a consistent, and
relatively spacious, dash style.
* Lines are capped with a consistent arrow shape where relevant.
* Small solid circles representing points are a consistently sized circle.
Whenever reasonable, it is advised to copy an existing similar diagram and
edit it rather than creating one from scratch in order to re-use elements
and maintain consistency.
[[character-sets-in-svg]]
== Character sets in SVG files
At the moment, the PDF conversion path only supports the Windows-1252
character set, as we are currently using the standard fonts built into every
PDF viewer - such that we don't have to embed a different font.
Unfortunately these only support Windows-1252, which is a highly limited
character set.
As such, characters not in that set will not display properly when present
in an SVG, and will fire a warning when building the PDF.
Luckily, Inkscape has an "Object to path" function built in, which will
convert text to a raw path, allowing these characters to be supported.
Please ensure that you build the PDF before submitting any new images,
particularly with non-standard characters, in order to catch such errors.
ifdef::editing-notes[]
[NOTE]
.editing-note
====
*Other Stuff Which May Be Described In This Chapter Eventually*
* Something about Image formats
* Something about validation scripts
* Glossary lists
* New param/enum macros
====
endif::editing-notes[]