Graphics
- 8.7.3 Tiling patterns
- 8.9.5 Image dictionaries
- 8.9.6 Masked images
- 8.9.6.2 Stencil masking
- 8.11.4 Configuring optional content
8. Graphics
8.2 Graphics objects
Change Table 50 as follows:
Category | Operators | Location |
---|---|---|
Shading patterns |
|
"Table 76 — Shading operator" |
... | ... | ... |
Marked-content | MP, DP, BMC, BDC, EMC |
|
8.4 Graphics state
8.4.1 General
Add the following row to Table 52 below the Haftone entry as follows:
Parameter | Type | Value |
---|---|---|
flatness | number |
The precision with which curves shall be rendered on the output device (see 10.7.2, "Flatness tolerance"). The value of this parameter |
halftone origin | array | (PDF 2.0) The X and Y coordinates of the halftone origin. Initial value: a PDF reader shall initialise this to a suitable device dependent value. |
8.4.2 Graphics state stack
Append a new sentence to the last paragraph as follows:
Occurrences of the q and Q operators shall be balanced within a given content stream (or within the sequence of streams specified in a page dictionary’s Contents array). See 9.4.1, "General" for additional information that must be managed as part of the graphics state stack when q and Q operators occur within text objects.
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.4.4 Graphics state operators
Change Table 56 as follows:
Operands | Operator | Description |
---|---|---|
flatness | i |
Set the flatness tolerance in the graphics state (see 10.7.2, "Flatness tolerance"). |
8.4.5 Graphics state parameter dictionaries
Change Table 57 as follows:
Key | Type | Value |
---|---|---|
UseBlackPtComp | name |
...
|
8.5 Path constructing and painting
8.5.3 Path-painting operators
8.5.3.1 General
Add a new NOTE above Table 59 as follows:
NOTE: While these operators are primarily for path-painting, they also serve a purpose in path construction as they may affect the current graphics path (see 8.5.2, "Path-construction operators").
Change Table 59 as follows:
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
... |
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.
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 where x ≤ 3 | ISO 15076-1:2010, 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:2010profiles conforming to ISO 15076-1:2010. It may embed profiles conforming to an earlier or later ICC version. - ...
Add a new NOTE 2 below NOTE 1 and above Table 67 as follows:
NOTE 2 ICC profiles can contain private tags or tags defined in later versions of ICC profile specifications than specified in "Table 66 - ICC Specification versions supported by ICC based colour spaces". This document intentionally does not specify how a PDF processor might use such data in ICC profiles. A PDF processor can ignore such data altogether. Any use of such data is implementation dependent.
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.6.6 Special colour spaces
8.6.6.5 DeviceN colour spaces
...
Change the paragraph this is 2 paragraphs above NOTE 4 as follows:
The component names shall all be different from one another, except for the name None, which may be repeated as described later in this subclause. The special name None shall not be used in DeviceN colour spaces that have the NChannel subtype The special name All, used by Separation colour spaces, shall not be used. The names Cyan, Magenta, Yellow and Black are reserved to name the subtractive process colourants of a CMYK device.
...
Change the paragraph below NOTE 6 as follows:
The colour component name None
, which may be present only for DeviceN colour spaces that do not have the NChannel subtype,
indicates that the corresponding colour component shall never be painted on the page, as in a Separation colour space for the None colourant. When a DeviceN colour space is painting the named device colourants directly, colour components corresponding to None colourants shall be discarded. However, when the DeviceN colour space reverts to its alternate colour space, those components shall be passed to the tint transformation function, which may use them as desired.
8.7 Patterns
8.7.3 Tiling patterns
8.7.3.1 General
Change the second paragraph as follows:
The pattern cell can include graphical elements such as filled areas, text, and sampled images. Its shape need not be rectangular, and the spacing of tiles can differ from the dimensions of the cell itself. When performing painting operations such as S (stroke) or f (fill), the PDF processor shall paint the cell on the current page as many times as necessary to fill an area. The order in which individual tiles (instances of the cell) are painted is unspecified and unpredictable (implementation dependent) ; figures on adjacent tiles should not overlap.
...
Change the caption of Table 74 as follows:
Key | Type | Value |
---|---|---|
... | ... | ... |
8.9 Images
8.9.5 Image dictionaries
8.9.5.1 General
Change Table 87 as follows:
Key | Type | Value |
---|---|---|
BitsPerComponent | integer |
(Required except for image masks and images that use the JPXDecode filter) The number of bits used to represent each colour component. Only a single value shall be specified; the number of bits shall be the same for all colour components. The value shall be 1, 2, 4, 8, or (from PDF 1.5) 16. If ImageMask is true, this entry is optional, but if specified, its value shall be 1.
If the image stream uses a filter, the value of BitsPerComponent shall be consistent with the size of the data samples that the filter
delivers. In particular, a CCITTFaxDecode or JBIG2Decode filter shall always deliver 1-bit samples, a RunLengthDecode or
DCTDecode filter shall always deliver 8-bit samples, and an LZWDecode or FlateDecode filter shall deliver samples of
If the image stream uses the JPXDecode filter, this entry is optional and shall be ignored if present. The bit depth is determined by the PDF processor in the process of decoding the JPEG 2000 image. |
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 | stream or array |
(Optional; shall not be present for image masks; PDF 1.3) An image XObject defining an image mask to be applied to this image (see 8.9.6.3, "Explicit masking"), or an array specifying a range of colours to be applied to it as a colour key mask (see 8.9.6.4, "Colour key masking"). If ImageMask is true, this entry shall not be present (if present, it shall be ignored). NOTE Interactions between SMask, SMaskInData and the current soft mask in the graphics state are set out in clause 11.6.4.3, "Mask shape and opacity". |
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 |
(Optional; PDF 1.4) A subsidiary image XObject defining a soft-mask image (see 11.6.5.2, "Soft-mask images") that shall be used as a source of mask shape or mask opacity values in the transparent imaging model. The alpha source parameter in the graphics state determines whether the mask values shall be interpreted as shape or opacity. If present, this entry shall override the current soft mask in the graphics state, as well as the image’s Mask entry, if any. However, the other transparency-related graphics state parameters — blend mode and alpha constant — shall remain in effect. If SMask is absent and SMaskInData has value 0, the image shall have no associated soft mask (although the current soft mask in the graphics state may still apply). SMask shall not be present if SMaskInData has a non-zero value (if present, SMask shall be ignored). Additional limitations also apply to this key when used in soft-mask image dictionaries - see clause 11.6.5.2 Soft-mask images. |
SMaskInData | integer |
(Optional for images that use the JPXDecode filter, meaningless otherwise; PDF 1.5) A code specifying how soft-mask information (see 11.6.5.2, "Soft-mask images") encoded with image samples shall be used:
If this entry has a non-zero value, SMask shall not be specified (if present, SMask shall be ignored). If SMaskInData is non-zero, there shall be only one opacity channel in the JPEG 2000 data and it shall apply to all colour channels. See also 7.4.9, "JPXDecode filter". NOTE 2 Interactions between SMask, SMaskInData and the current soft mask in the graphics state are set out in clause 11.6.4.3, "Mask shape and opacity". Default value: 0. |
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.
- 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. - 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. - 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.
-
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. - 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.
- If steps c and d above do not identify an alternate to be rendered then the base image shall be rendered.
...
8.9.6 Masked images
8.9.6.2 Stencil masking
...
Change the NOTE as follows:
NOTE One of the most important uses of stencil masking is for painting character glyphs represented as bitmaps. Using such a glyph as a stencil mask transfers only its "black" bits to the page, leaving the "white" bits (which are really just background) unchanged. For reasons discussed in
9.6.5.3, "Encodings for Type 3 fonts"
9.6.4, "Type 3 fonts"
, an image mask, rather than an image,
need almost always be used to paint glyph bitmaps
is normally used to paint glyph bitmaps.
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.
...
Change Table 91 as follows:
Full Name | Abbreviation |
---|---|
Interpolate | I (uppercase |
...
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").
...
8.10 Form XObjects
8.10.2 Form dictionaries
Change Table 93 as follows:
Key | Type | Value |
---|---|---|
Resources | dictionary |
(
In PDF 1.2 and later versions, NOTE 1 In PDF 1.1 and earlier, all named resources used in the form XObject were defined to be included in the resource dictionary of each page object on which the form XObject appears, regardless of whether they also appeared in the resource dictionary of the form XObject. These resources also needed to be specified in the form XObject’s resource dictionary as well, to determine which resources were used inside the form XObject. If a resource was included in both dictionaries, it needed to have the same name in both locations. NOTE 2 Linearized PDF files impose additional requirements on resources - see "Annex F - (normative) Linearized PDF". |
StructParent | integer | (Required if the form XObject is a structural content item; PDF 1.3) The integer key of the form XObject’s entry in the structural parent tree (see 14.7.5.4, "Finding structure elements from content items"). At most one of the entries StructParent or StructParents shall be present. A form XObject shall be either a content item in its entirety or a container for marked-content sequences that are content items, but not both. |
8.11 Optional Content
8.11.4 Configuring optional content
8.11.4.3 Optional content configuration dictionaries
Change Table 99 as follows:
Key | Type | Value |
---|---|---|
RBGroups | array |
(Optional) An array consisting of one or more arrays
In the default configuration dictionary, the default value for RBGroups shall be an empty array; in other configuration dictionaries, the default is the RBGroups value from the default configuration dictionary. |
Last modified: 19 November 2024