8. Graphics

8.2 Graphics objects

Change Table 50 as follows:

Table 50 - Operator categories
Category Operators Location
Shading patterns Sh sh "Table 76 — Shading operator"
... ... ...
Marked-content MP, DP, BMC, BDC, EMC "Table 351 — Entries in a data dictionary" "Table 352 — Marked-content operators"

8.4 Graphics state

8.4.3 Details of graphics state parameters

8.4.3.5 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 be a number greater than or equal to 1.0 and 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

8.5.3.1 General

Change Table 59 as follows:

Table 59 - Path-painting categories
Operands Operator Description
- B

Fill and then stroke the path, using the non-zero winding number rule to determine the region to fill. In the opaque imaging model, this This operator shall produce the same result as constructing two identical path objects, painting the first with f and the second with S.

...

8.6.5.5 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 specifications.

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.) ICC profile versions supported by ICCBased colour spaces" lists the ICC profile versions as specified in the ICC header that shall be supported.

Table 66 - ICC Specification versions supported by ICC based colour spacesICC profile versions supported by ICCBased colour spaces
ICC profile header version ICC Specification
2.x.y.z "Specification ICC.1:2001-04 - File Format for Color Profiles [REVISION of ICC.1:1998-09]"
4.x.y.z ISO 15076-1, Image technology colour management – Architecture, profile format and data structure — Part 1: Based on ICC.1:2010

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.0both ICC profile header version 2.x and 4.x profiles, 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 PDFICC specification being processed as shown in "ICC Specification versions supported by ICC based colour spaces"Table 66 - ICC profile versions supported by ICCBased colour spaces" above; it shall not substitute the alternate colour space in these cases.
  • A PDF writer should use ICC 1:2010 profiles conforming to ISO 15076. It may embed profiles conforming to an earlier or later ICC version.
  • ...

8.6.5.8 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

8.9.5.1 General

Change Table 87 as follows:

Table 87 - Additional entries specific to an image dictionary
Key Type Value
Intent name

...

Additional limitations also apply to this key when used in soft-mask image dictionaries - see clause 11.6.5.2 Soft-mask images.

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 Mask Mask and ColorSpace shall not be specified; unmasked areas shall be painted using the current nonstroking colour. Default value: false.
Alternates array

...

Additional limitations also apply to this key when used in soft-mask image dictionaries - see clause 11.6.5.2 Soft-mask images.

SMask stream

...

Additional limitations also apply to this key when used in soft-mask image dictionaries - see clause 11.6.5.2 Soft-mask images.

Name name

...

Additional limitations also apply to this key when used in soft-mask image dictionaries - see clause 11.6.5.2 Soft-mask images.

StructParent integer

...

Additional limitations also apply to this key when used in soft-mask image dictionaries - see clause 11.6.5.2 Soft-mask images.

ID byte string

...

Additional limitations also apply to this key when used in soft-mask image dictionaries - see clause 11.6.5.2 Soft-mask images.

8.9.5.4 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 renderedclarify the relationship between optional content and DefaultForPrinting.

  1. If the base image contains an OC key then DefaultForPrinting shall be ignored on all Alternates entriesentry that specifies that the content is not visible, then nothing shall be shown.

  2. If the base image contains an OC entry that specifies that the base image is visible, then the base image shall be rendered.

  3. 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.

  4. Otherwise if the PDF is being printed and any of the Alternates entries has DefaultForPrinting set to true, then that alternate image shall be printed.

  5. 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.

  6. Otherwise, the list of alternates specified by the base image Alternates entry is examined, and the first alternate containing an OC entry specifying that its content is visible shall be shown (Alternates that have no OC entry shall not be shown.) Furthermore if the image dictionary that forms the value of the Image key of the selected alternate contains an OC entry, then that OC in the image dictionary shall not be examined.

  7. If steps c and d above do not identify an alternate to be rendered then the base image shall be rendered.

...

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 ASCII85Decode as one of its filters its final or only filter, 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. In the situation where both an abbreviated key name and the corresponding full key name from Table 91 are present, the abbreviated key name shall take precedence. Entries other than those listed shall be ignored.

...

Replace NOTE 3 as follows:

NOTE 3 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. never refer to resources in the ColorSpace subdictionary; they always identify the corresponding colour spaces either directly or via a default colour space (see 8.6.5.6 "Default colour spaces").

...

</div>

Last modified: 14 August 2022