8.2 Graphics objects
Change Table 50 as follows:
||"Table 76 — Shading operator"|
|Marked-content||MP, DP, BMC, BDC, EMC||
8.4 Graphics state
8.4.3 Details of graphics state parameters
188.8.131.52 Mitre limit
Change the first paragraph as follows:
When two line segments meet at a sharp angle and mitered joins have been specified as the line join style, it is possible for the miter to extend far beyond the thickness of the line stroking the path. The miter limit shall impose a maximum on the ratio of the miter length to the line width (see "Figure 15 — Miter length"). When the limit is exceeded, the join is converted from a miter to a bevel.
8.5 Path constructing and painting
8.5.3 Path-painting operators
Change Table 59 as follows:
Fill and then stroke the path, using the non-zero winding number rule to determine the region to fill.
184.108.40.206 ICCBased colour spaces
Change the first paragraph as follows:
ICCBased colour spaces (PDF 1.3) shall be based on a cross-platform colour profile as defined by the International Color Consortium (ICC). Unlike the CalGray, CalRGB, and Lab colour spaces, which are characterised by entries in the colour space dictionary, an ICCBased colour space shall be characterised by a sequence of bytes in a standard format. Details of the profile format can be found in the ICC specification.
Replace the paragraph before Table 66 and Table 66 as follows:
"Table 66 -
ICC Specification versions supported by ICC based colour spaces" shows the versions of the ICC specification on which the
ICCBased colour spaces that PDF versions 1.3 and later shall use. (Earlier versions of the ICC specification shall also be supported.)
Change the bulleted list below Table 66 as follows:
PDF processors shall follow these guidelines for writing and rendering ICC based color spaces:
- A PDF reader shall support
ICC.1:2010 as required by PDF 2.0, which will enable it to properly render all embedded ICC profiles regardless of the PDF version.
- A PDF reader shall always process an embedded ICC profile according to the
corresponding version of the PDFbeing processed as shown in "ICC Specification versions supported by ICC based colour spacesabove; it shall not substitute the alternate colour space in these cases.
- A PDF writer should use ICC
1:2010profiles. It may embed profiles conforming to an earlier or later ICC version.
220.127.116.11 Rendering intents
Change the NOTE below Table 69 as follows:
NOTE The exact set of rendering intents supported can vary from one output device to another; a particular device
does not have to support all PDF rendering intents and
can support additional ones beyond those listed in the table above.
8.9.5 Image dictionaries
Change Table 87 as follows:
|ImageMask||boolean||(Optional) A flag indicating whether the image shall be treated as an image mask (see 8.9.6, "Masked images"). If this flag is true,
the value of BitsPerComponent, if present, shall be 1 and
18.104.22.168 Alternate images
Change the list below Table 89 as follows:
In PDF 1.5, optional content (see 8.11, "Optional content") may be used to facilitate selection between alternate images. The following algorithm shall be used to determine which image, if any, shall be rendered:
NOTE (2020) The following algorithm was changed in this document to
reflect that OC processing has precedence over DefaultForPrinting functionality, and situations where no image is to be rendered.
- If the base image contains an OC
key then DefaultForPrinting shall be ignored on all Alternates entries.
- If the base image contains an OC entry that specifies that the base image is visible, then the base image shall be rendered.
If the base image contains an OC entry that specifies that the base image is not visible, then the list of alternate image dictionaries specified by the base image Alternates entry shall be examined in order, and the first entry not containing an OC key, or containing an OC entry specifying that the alternate image should be visible, shall be selected. Further, if this selected alternate image has an OC entry, then that OC entry shall also be processed to determine if the alternate image shall be rendered or not. If none of the alternate image dictionaries have an OC key, or none of the alternate image dictionaries with an OC entry specify that that alternate image is visible, then nothing shall be shown. DefaultForPrinting shall be ignored on all Alternates entries.
If the base image does not contain an OC key and the PDF is being printed then the first entry in the Alternates array of the base image that has DefaultForPrinting set to true shall be selected. Further, if this selected alternate image has an OC entry, then that OC entry shall also be processed to determine if the alternate image shall be printed or not. If no alternate image dictionary in the Alternates array has DefaultForPrinting set to true, then the base image shall be printed.
8.9.7 Inline images
Change the paragraphs below Table 90 as follows:
Inline image objects shall not be nested; that is, two BI operators shall not appear without an intervening EI to close the first object.
Similarly, an ID operator shall only appear between a BI and its balancing EI. Unless the image uses ASCIIHexDecode or
one of its filters
, the ID operator shall be followed by a
single white-space character, and the next character shall be interpreted as the first byte of image data.
The key-value pairs appearing between the BI and ID operators (as listed in "Table 91 - Entries in an inline image object") are analogous to their respective key-value pairs in an image XObject dictionary (see "Table 87 - Additional entries specific to an image dictionary") or a stream dictionary (see "Table 5 - Entries common to all stream dictionaries"). For convenience, the abbreviations shown in "Table 91 - Entries in an inline image object" and "Table 92 - Additional abbreviations in an inline image object" may be used in place of the full names. Entries other than those listed shall be ignored.
Replace NOTE 3 as follows:
The names DeviceGray, DeviceRGB, and DeviceCMYK (as well as their abbreviations G, RGB, and CMYK)
always identify the corresponding colour spaces directly; they never refer to resources in the ColorSpace subdictionary.
Last modified: 14 August 2022