Microsoft Word C042274e doc Reference number ISO 24517 1 2008(E) © ISO 2008 INTERNATIONAL STANDARD ISO 24517 1 First edition 2008 05 15 Document management — Engineering document format using PDF — Pa[.]
File header
The % character of the file header shall occur at byte offset 0 of the file.
File trailer
The file trailer dictionary shall contain the ID keyword The value for the ID entry shall be an array of length two, containing two non-empty string objects.
Document ID
If the document catalog contains an Encrypt entry, the value for the ID entry in the document trailer and the strings contained in the ID array shall be direct
This provision guarantees that the ID entry remains accessible and readable even when the document is encrypted A circular dependency issue occurs when encryption algorithms rely on indirect document ID strings, as the PDF Reference mandates that all indirect objects outside the encryption dictionary must be encrypted The situation becomes more complex with the presence of object streams, as the ID strings may be embedded within an encrypted object stream.
Cross-reference tables and cross-reference streams
Indirect objects not listed in a cross-reference table or stream are exempt from the requirements of ISO 24517 A PDF/E-1 compliant reader must not utilize these objects in processing or presenting a PDF/E document.
Document information dictionary
A document information dictionary can be included in a PDF/E-1 compliant file, and if present, its elements must align with the corresponding XMP metadata properties outlined in the XMP Specification, as detailed in Clause 13.
String objects
Hexadecimal strings shall contain an even number of non-white-space characters, each in the range 0 to 9,
Stream objects
The Length key in the stream dictionary must correspond to the byte count of the file that appears after the LINE FEED character and before the EOL marker, just prior to the endstream keyword.
NOTE 1 These requirements remove potential ambiguity regarding the ending of stream content
A stream object dictionary shall not contain the F, FFilter, or FDecodeParams keys
These keys are designed to reference content outside the document By explicitly excluding these keys, external content that may create dependencies and impede portability is effectively disallowed.
Copyright International Organization for Standardization
Linearized PDF
Linearization shall be permitted but any linearization information supplied within a file may be ignored by PDF/E-1 conforming readers.
Implementation limits
PDF/E-1 conforming files shall not violate the following implementation limits for objects outside of stream data or comments (as defined in PDF Reference, 3.1.2)
All integer values shall be in the range [ −2 31 , (2 31 − 1) ]
All decimal numbers must fall within the range that IEEE single-precision floating-point numbers can represent Additionally, the length of a name object should be a minimum of one byte and a maximum of 127 bytes.
Indirect object numbers shall be at least one and at most 8 388 607
In a DeviceN colour space, the number of colourants or tint components must range from a minimum of one to a maximum of 32 Additionally, the character identifier (CID) value should be between zero and 65,535.
NOTE 1 By complying with these limits, a PDF/E-1 conforming file is compatible with the widest possible range of readers
The limitation on integer size restricts the maximum size of a linearized PDF/E file to (2^31 - 1) bytes, as the T entry in the linearization dictionary represents the file size as an integer.
General
Restrictions placed on both PDF/E-1 conforming files and reader are described in 7.2 to 7.13 They are intended to address the rendering of graphical page contents, including text and font issues.
Output intent
A PDF/E-1 conforming file can define the color characteristics of the intended rendering device through a PDF/E-1 OutputIntent This OutputIntent is an OutputIntent dictionary included in the file's OutputIntents array, featuring ISO_PDFE1 as the value for its S key and a valid ICC profile stream for its DestOutputProfile key.
If a file's OutputIntents array has multiple entries, all entries with a DestOutputProfile key must have the same value, which should be a valid ICC profile stream represented as an indirect object.
NOTE This subclause is not in conflict with similar requirements in ISO 19005-1 because multiple OutputIntent dictionaries are allowed by both.
Colour spaces
All colors must be defined in a device-independent way, either through a device-independent color space or by utilizing an OutputIntent A PDF/E-1 compliant file can employ any color space outlined in the PDF Reference, with specific restrictions noted in sections 7.3.2 to 7.3.4.
Specifying color in a device-independent manner, as outlined in section 7.3, ensures consistent color rendering based on a colorimetric definition, eliminating the need for external assumptions or information This approach also allows for the association of a colorimetric definition with device-dependent color data.
All ICCBased colour spaces shall be embedded as ICC profile streams as described in PDF Reference, 4.5.4
A PDF/E-1 conforming reader shall render ICCBased colour spaces as specified by ICC.1:2004-10 and shall not use the Alternate colour space specified in an ICC profile stream dictionary
A PDF/E-1 conforming file must utilize either the DeviceRGB or DeviceCMYK color space, but not both If an uncalibrated color space is present, the file must include a PDF/E-1 OutputIntent as specified in section 7.2 DeviceRGB is permissible only when the file has a PDF/E-1 OutputIntent that employs an RGB color space, while DeviceCMYK is allowed solely if the OutputIntent uses a CMYK color space.
When a DeviceGray color specification is rendered in a file with an RGB OutputIntent, a PDF/E-1 compliant reader must convert the DeviceGray color to RGB using the method outlined in the PDF standards.
When a DeviceGray color specification is rendered in a file with a CMYK OutputIntent, a PDF/E-1 compliant reader must convert the DeviceGray color to DeviceCMYK using the method outlined in PDF Reference 6.2.2.
When rendering colours specified in a device-dependent colour space a PDF/E-1 conforming reader shall use the file’s PDF/E-1 OutputIntent dictionary, as defined in 7.2, as the source colour space
7.3.4 Separation and DeviceN colour spaces
A PDF/E-1 conforming file shall not make use of DeviceN colour spaces with an NChannel subtype
A PDF/E-1 conforming reader shall obey the following rules when rendering colour spaces based on DeviceN or Separation colour spaces
If a file contains only the colourants Cyan, Magenta, Yellow, and Black, and has a CMYK OutputIntent, these colourants must be regarded as components of the specified colour space in the PDF/E-1 OutputIntent dictionary, as outlined in section 7.2, without utilizing an alternate colour space.
⎯ If the output device does not support the Separation colour space or DeviceN colorants, the Alternate colour space shall be used
The Alternate colour space of a Separation or DeviceN colour space shall obey all restrictions on colour spaces specified in 7.3.2 and 7.3.3
3D content is defined in an unqualified RGB color space, and a PDF/E-1 conforming reader is not obligated to manage colors for 3D content However, if the reader does manage colors, it must adhere to the guidelines in section 7.3.3 for handling DeviceRGB colors, with color management occurring post-rendering of the 3D content In cases where the reader cannot render the 3D content and defaults to the standard appearance of the 3D annotation, the rules outlined in sections 7.3.2 to 7.3.4 should be applied.
NOTE This means that the PDF/E-1 specification does not ensure consistent colour-rendering of 3D content across devices and reader applications
Copyright International Organization for Standardization
Images
If an image dictionary contains alternate images, the image dictionary and each alternate image dictionary shall contain OC keys as defined in Tables 4.39 and 4.41 in the PDF Reference
An image dictionary shall not contain the OPI key
If an image dictionary contains the Interpolate key, its value shall be false
The use of the Intent key shall conform to the rules given in 7.10.
Form XObjects
A form XObject dictionary shall not contain any of the following:
⎯ the Subtype2 key with a value of PS; or
In earlier PDF versions, the Subtype2 key with a value of PS and the PS key were utilized to define executable PostScript code streams, which could disrupt reliable and predictable rendering.
PostScript XObjects
A PDF/E-1 conforming file shall not contain PostScript XObjects
NOTE PostScript XObjects contain arbitrary executable PostScript code streams that have the potential to interfere with reliable and predictable rendering.
Shading operator
The shading dictionary, when referenced by the sh operator shall contain a valid BBox entry.
Extended graphics state
An ExtGState dictionary must not include the TR key or the TR2 key with any value other than Default Additionally, a PDF/E-1 compliant reader may disregard any occurrence of the HT key within an ExtGState dictionary.
Use of the RI key shall conform to the rules of 7.10.
Rendering intents
Where a rendering intent is specified, its value shall be one of the four values defined in PDF Reference, i.e
RelativeColorimetric, AbsoluteColorimetric, Perceptual, or Saturation
NOTE The default rendering intent is RelativeColorimetric
Content streams
A PDF/E-1 conforming file shall not include operators in a Contents stream that are not described in the PDF
Reference, even if they are encapsulated between BX and EX operators
A PDF/E-1 conforming reader shall process every page operator according to the PDF Reference, even when they are encapsulated between BX and EX operators
It is recommended that a PDF/E-1 writer not use the BX/EX operators
The operators BX and EX mark sections in a page description where undefined page operators are not reported, as specified by the PDF.
Reference can be ignored and not rendered by a reader that does not understand some or all of the page operators in between BX and EX
Use of the ri operator shall conform to the rules of 7.10
Content streams are essential for page descriptions, including the Contents stream of a page object and the stream of a form XObject They also play a crucial role in the appearance stream of annotations, such as form fields and Widget annotations.
NOTE 3 In earlier versions of the PDF format a PostScript operator PS was defined As this operator is not defined in
PDF Reference, its use is implicitly prohibited by 7.10
The NOTE 4 Set line width (LW) operator permits values of line width, including 0, although this can lead to device-dependent outcomes A line width of 0 may produce a one-pixel-wide line that could be invisible on high-resolution devices.
Optional content
The category array in a usage application dictionary shall not contain a CreatorInfo or User entry
The OCG is permitted to include CreatorInfo or User entries in their Usage dictionaries; however, these entries are strictly for descriptive purposes and will not influence the operational states of the OCGs.
Print scaling
A PDF/E-1 compliant reader must adhere to the PrintScaling key specified in the viewer preferences dictionary When the PrintScaling key is included and set to None, readers are required to follow specific behavior guidelines.
Non-interactive printing readers are required to print documents only if all pages can be printed without any scaling If a document cannot be printed under these conditions, the reader may generate an error.
⎯ Interactive readers shall not allow any scaling factor when performing a print operation
General
The intent of the requirements in 8.2 to 8.6 is to ensure that future rendering of the textual content of a
A PDF/E-1 conforming file matches the original static appearance of the document on a glyph-by-glyph basis, enabling the recovery of semantic properties for each character in the text.
For optimal text searchability in PDF/E files, it is advisable to implement full text searchability, although it is not mandatory When full text searchability is essential, the file must adhere to the guidelines of PDF/A-1a, ensuring Level A conformance.
Copyright International Organization for Standardization
Font types
All fonts used in a PDF/E-1 conforming file shall conform to the font specifications defined in PDF Reference, 5.5
In the context of ISO 24517, multiple master fonts are treated as a specific variant of Type 1 fonts, meaning that any requirements specified for Type 1 fonts also apply to multiple master fonts.
Writers must ensure that all fonts comply with the relevant standards, as outlined in ISO 24517 This section does not specify how to determine font conformance.
The value of the Subtype key in a font dictionary shall be one of the values listed in Table 5.7 of the PDF
NOTE 2 This requirement resolves an ambiguity in the PDF Reference regarding validity of unknown values for Subtype
A PDF/E-1 conforming reader may ignore hinting information present in Type 1 fonts
The Type 1 font specification lacks completeness concerning hinting information; however, it is still feasible to achieve satisfactory rasterizations of font outlines without relying on this data.
Composite fonts
In a PDF/E-1 conforming file, the CIDSystemInfo entries of a composite (Type 0) font's CIDFont and CMap dictionaries must be compatible, as outlined in PDF Reference 5.6.2 Specifically, the Registry and Ordering strings of the CIDSystemInfo dictionaries for that font should match, except when the CMap dictionary's UserCMap key is set to Identity-H or Identity-V.
All Type 2 CIDFonts must include a CIDToGIDMap entry in the CIDFont dictionary, which can either be a stream mapping CIDs to glyph indices or the name Identity, as outlined in PDF Reference, Table 5.14.
All CMaps in a PDF/E-1 conforming file must be embedded, except for Identity-H and Identity-V, as outlined in PDF Reference 6.5.4 The integer value of the embedded CMaps is also specified.
Embedded font programs
All fonts utilized in a PDF/E-1 conforming file must be embedded, as specified in PDF Reference 5.8, unless they are exclusively used in text-rendering mode 3 A font is deemed to be in use if any of its glyphs are referenced in specific contexts.
⎯ the Contents stream of a page object;
⎯ the stream of a Form XObject;
⎯ the appearance stream of an annotation, including form fields;
⎯ the content stream of a Type 3 font glyph; or
⎯ the stream of a tiling pattern
Only fonts that are legally embeddable in a file for unlimited, universal rendering shall be used
All PDF/E-1 conforming readers shall use the embedded fonts, rather than other locally resident, substituted, or simulated fonts for rendering
Text-rendering mode 3, as outlined in PDF Reference, indicates that glyphs are neither stroked nor filled and are not utilized as a clipping boundary Consequently, any font designated for exclusive use in this mode is not rendered and is therefore exempt from the embedding requirement.
Type 3 fonts are exempt from the requirements of section 8.4, as they are always embedded within PDF files through a different mechanism than that of the PDF Reference However, the 14 standard Type 1 fonts do not have any exemptions from these requirements.
Font subsets are permissible if they include glyph definitions for all characters used in the document, as outlined in section 8.5 By embedding font programs, any PDF/E-1 compliant reader can accurately reproduce all glyphs as originally intended, without relying on potentially unreliable external resources.
ISO 24517 prohibits the inclusion of fonts that require special agreements with copyright holders, as this creates significant challenges for archives in verifying the existence, validity, and longevity of such agreements.
Font subsets
Embedded font programs must define all font glyphs used for rendering in a PDF/E-1 conforming file, as outlined in section 8.4 Type 0 CIDFont, Type 1, and TrueType font subsets can be utilized, provided that the embedded font programs include all necessary glyphs, as specified in PDF Reference 5.5.3.
In a PDF/E-1 compliant file, every Type 1 font subset must have a font descriptor dictionary that includes a CharSet string, which lists the character names defined in that font subset, as outlined in the PDF specifications.
In a PDF/E-1 compliant file, each CIDFont subset must have a font descriptor dictionary that includes a CIDSet stream, which specifies the CIDs included in the embedded CIDFont file.
NOTE The use of font subsets allows a potentially substantial reduction in the size of PDF/E-1 conforming files.
Character encodings
All non-symbolic TrueType fonts shall specify MacRomanEncoding or WinAnsiEncoding as the value of the
Symbolic TrueType fonts must not include an Encoding entry in their font dictionary, and their cmap tables should contain precisely one encoding.
NOTE This requirement makes normative the suggested guidelines described in PDF Reference, 5.5.5
General
PDF/E-1 compliant interactive readers must include a feature that allows users to view the values of the Contents key in annotation dictionaries, in accordance with the rendering behavior specified by the PDF Reference and modified by ISO 24517.
NOTE This part of ISO 24517 does not prescribe the specific behaviour or technical implementation details that interactive readers can use to implement this functional requirement
Copyright International Organization for Standardization
Annotation types
Annotation types not defined in PDF Reference shall not be permitted.
Annotation dictionaries
An annotation dictionary shall contain the F key The F key’s Print flag bit shall be set to 1 and its Hidden,
Invisible and NoView flag bits shall be set to 0
The NoZoom and NoRotate flag bits of the F key in a Text annotation shall be 1
Restrictions on annotation flags limit the use of hidden or non-printable annotations However, the NoZoom and NoRotate flags are allowed, enabling annotation types to function similarly to standard text annotations Text annotations inherently display NoZoom and NoRotate behavior, as outlined in PDF Reference, 8.4.5 Explicitly setting these flags clarifies any ambiguity between the annotation dictionary settings and how readers interact with them.
An annotation dictionary shall not contain the C array or the IC array unless the colour space of the
DestOutputProfile in the PDF/E-1 OutputIntent dictionary, defined in 7.2, is RGB
NOTE 2 These provisions ensure that the device colour spaces used in annotations by mechanisms other than an appearance stream are indirectly defined by means of the PDF/E-1 OutputIntent
An annotation dictionary with the AP key must have an appearance dictionary that includes only the N key, which defines the annotation's appearance as a stream PDF/E-1 compliant readers will render only this specified appearance, except for 3D and multimedia annotation types, as outlined in the PDF Reference.
This subclause limits the display of annotations on the rendered page, allowing readers to use alternative user interface elements related to these annotations The International Standard does not impose any restrictions or requirements on how these presentations should be made.
The document's interactive form dictionary that forms the value of the AcroForm key in the catalog object of a PDF/E-1 file, if present, shall not contain the XFA key
NOTE The use of XML-based XFA forms is prohibited by this requirement because of their dynamic layout
The NeedAppearances entry in an interactive form dictionary, if present, shall have a value of False
General
JavaScript and ImportForm actions shall not be permitted Additionally, the deprecated set-state and no-op actions shall not be permitted
NOTE 1 JavaScript actions permit arbitrary executable code that has the potential to interfere with reliable and predictable rendering
NOTE 2 ImportForm actions introduce data from sources outside the PDF file, violating the requirement that the document be self-contained
Hypertext links
Interactive PDF/E-1 compliant readers can opt to disable hyperlinks However, they must still adhere to the rendering behavior specified by the PDF Reference, as updated by ISO 24517 Additionally, these readers should offer a way to display the F and D keys from a GoToR action dictionary, the URI key from a URI action dictionary, and the F key from a SubmitForm action dictionary.
Hyperlinks can lead users away from the control of an interactive reader, so this subclause allows readers to opt out of making them actionable To ensure complete archival disclosure of PDF/E documents, interactive readers must provide a way to reveal the destination of all hyperlinks However, ISO 24517 does not specify the exact behavior or technical implementation that interactive readers should adopt to fulfill this requirement.
Non-interactive PDF/E-1 conforming readers shall ignore all parameters pertaining to presentations, as described in PDF Reference, 8.3.3
Non-interactive PDF/E-1 conforming readers shall ignore the PresSteps entry in a page dictionary
Interactive PDF/E-1 compliant readers can follow specific parameters related to presentations as outlined in PDF Reference 8.3.3 These readers may also adhere to the PresSteps entry in a page dictionary If supported, the interactive reader must offer a unique "Presentation Mode," as detailed in PDF Reference 8.3.3, with navigation controls that are only functional when the reader is in this mode.
NOTE This subclause makes the recommended behaviour described in PDF Reference, p 566, a requirement
General
PDF/E-1 files shall conform to all of the requirements of ISO 19005-1:2005, 6.7 and its Corrigenda, except those overridden by this part of ISO 24517.
Version Identification
The XMP metadata of PDF/E-1 conforming files may contain conformance properties defined in other
PDF-based ISO Standards In particular, properties belonging to the pdfxid: (ISO 15930 series) and pdfaid:
(ISO 19005 series) namespaces are allowed but not required
The document information dictionary of PDF/E-1 files may include conformance entries from other PDF-based ISO Standards, notably allowing the inclusion of GTS_PDFXVersion from the ISO 15930 series, although its use is not mandatory.
NOTE This subclause explicitly makes the presence of required conformance properties and entries as defined in other PDF-based ISO Standards optional for PDF/E-1 conforming files
Copyright International Organization for Standardization
Document information dictionary
In addition to the entries in ISO 19005-1, Table 1, the following entry applies to PDF/E-1 files
Table 1 — Crosswalk between document information dictionary and XMP properties
Entry PDF type Property XMP type
ISO_PDFEVersion text string pdfe:ISO_PDFEVersion Text
The XML namespace URIs for various prefixes are essential for metadata management The dc prefix corresponds to the URI , while the pdf prefix is linked to Additionally, the xmp prefix has its own designated namespace URI, which is crucial for ensuring proper data interoperability and adherence to standards in digital content management.
The XML namespace URI for the pdfe prefix is
The value of GTS_PDFXVersion in the information dictionary, if present, shall be encoded in
PDFDocEncoding; Unicode encoding shall not be used
The values of document information dictionary entries must match their corresponding XMP properties For properties transitioning from the PDF text string type to the XMP Text type, this equivalence is determined on a character-by-character basis, regardless of encoding, by comparing the numeric ISO/IEC 10646 code points of the characters.
The explicit requirement for equivalence between document information dictionary entries and their corresponding XMP properties ensures a clear and unambiguous interpretation of the property's value.
The dc:creator property in XMP metadata must be represented as an ordered Text array of length one, containing one or more names The equivalence between Author and dc:creator is determined on a character-by-character basis, regardless of encoding, by comparing the numeric values.
ISO/IEC 10646code points for the characters
To convert the Author to the dc:creator property in XMP metadata, the dc:creator is represented by a seq ProperName structure This structure consists of one or more names per entry, where each entry in the ordered list corresponds to a name separated by commas.
EXAMPLE 1 The document information dictionary entry:
/Author (Peter, Paul and Mary) is equivalent to the XMP property:
Peter
Paul
Mary
Date properties consist of a variable-length sequence of temporal components, including year, month, day, hour, minute, and second, which vary in granularity These properties are designed to correspond with the PDF date type as defined by PDF specifications.
The XMP Date type, as outlined in section 3.8.3, requires that value equivalence be determined on a component-by-component basis in relation to Coordinated Universal Time (UTC), taking into account local time zone offsets.
EXAMPLE 2 The document information dictionary entries:
/CreationDate (D:20040402) /ModDate (D:20040408091132-05'00') are equivalent to the XMP properties:
XMP header
The bytes and the encoding attributes shall not be used in the header of an XMP packet
NOTE Both the bytes and encoding attributes are deprecated in XMP Specification.
File identifiers
A conforming PDF/E-1 file must contain metadata properties for file identification, specifically utilizing the xmpMM:DocumentID, xmpMM:VersionID, and xmpMM:RenditionClass properties within the document's metadata stream Typically, the xmpMM:RenditionClass value is set to default.
This part of ISO 24517 recommends the use of a 128-bit number in the form of a uuid-schemed UI (e.g uuid:
The xmpMM:DocumentID property should be generated to ensure a high probability of uniqueness Although ISO 24517 does not mandate a specific scheme for creating unique identifiers, it recommends using the algorithms outlined in ISO/IEC 11578:1996 and DCE 1.1.
All PDF/E-1 files must include specific properties in the document metadata stream, which are essential for proper data exchange These properties include xmp:CreateDate, xmp:ModifyDate, xmp:MetadataDate, and dc:title, and it is important that they contain valid data Additionally, a zero-length string must not be used for any of these four keys.
The xmp:CreatorTool and pdf:Producer properties should be present in the document metadata stream
The file trailer must include an ID key, which should be unique to ensure proper document identification Document creators are advised to adhere to the guidelines outlined in the PDF Reference to achieve this uniqueness.
File provenance information
When the contents of a document are altered, it is essential to update the ModDate key in the Document Info Dictionary, along with the Metadata fields xmp:ModifyDate and xmp:MetadataDate, if they exist Conversely, if only the document information dictionary or Metadata values are modified, only the xmp:MetadataDate should be updated.
Any alteration to a PDF/E-1 conforming file, including changes to metadata or digital signatures, necessitates an update to the changing identifier section of the file trailer dictionary by the PDF/E-1 writer.
ID key as described in PDF Reference, 10.3.
Validation
All XMP packet content must adhere to the well-formed standards set by XML 1.0 and the RDF/XML Syntax Specification It is recommended that writers validate the content of XMP packets when creating or resaving a PDF/E-1 compliant file.
A non-interactive PDF/E-1 conforming reader may ignore all embedded files
An interactive PDF/E-1 conforming reader shall provide user-interface elements suitable for communicating the presence of embedded files to a user
Copyright International Organization for Standardization
General
Sections 15.2 to 15.5 outline the management of multimedia across various reader conformance levels and establish essential parameters to enhance the effectiveness of embedded media.
Self-contained
All multimedia clips must be fully self-contained and embedded within the PDF/E-1 file as a single stream Media types that depend on multiple streams or external data sources are not allowed.
Handling of multimedia
A non-interactive PDF/E-1 conforming reader shall display the normal appearance of a screen annotation
An interactive PDF/E-1 conforming reader shall either display the normal appearance of a multimedia screen annotation or process the multimedia in accordance with the PDF Reference
It is not required that a PDF/E-1 conforming reader further process multimedia clips.
Must-have parameters
No dictionary listed in PDF Reference, 9.1.1 (p 714), may have an MH entry
This provision enhances the chances of a media clip's viability However, ISO 24517 does not dictate policies regarding the inclusion of multimedia players in systems that support PDF/E compliant readers.
Alternate presentations
The Names dictionary in a PDF/E-1 conforming file shall not have an AlternatePresentations entry
General
The conformance levels regarding handling of 3D artwork are defined in 16.2 to 16.4, which facilitates predictable rendering of 3D models without the need for 3D JavaScript.
Display of 3D annotations
A non-interactive PDF/E-1 conforming reader shall display the Normal appearance of a 3D annotation
An interactive PDF/E-1 conforming reader must either show the standard appearance of a 3D annotation or process and present the related 3D artwork according to the PDF Reference, the U3D specification, and the specific limitations outlined in ISO 24517.
Supported 3D formats
The Subtype entry in a 3D stream dictionary shall have a value of U3D
NOTE 1 PDF Reference states that there might be other values of the 3D Subtype in future versions of the reference
Future parts of ISO 24517 based on later versions of the PDF Reference might allow other 3D subtypes
If a Subtype other than U3D is encountered, a PDF/E-1 conforming reader shall leave the annotation in its inactive state and display its normal appearance
NOTE 2 This provision makes the behaviour recommended in PDF Reference a requirement for a PDF/E-1 consumer
A PDF/E-1 conforming reader may ignore the OnInstantiate entry in a 3D stream
NOTE This provision allows a reader to be conformant without supporting 3D JavaScript
A 3D stream dictionary shall not contain a Resources entry
The Resources entry serves as a repository for image data and 3D models, designed for the OnInstantiate script to assemble complex models from component sub-parts This ensures that all necessary information for instantiating and accurately rendering the 3D model is included within the U3D stream, eliminating the need for JavaScript assembly.
Extensions to the PDF format
The rendering of PDF/E-1 conforming files must adhere to the guidelines outlined in the PDF Reference, along with additional requirements specified in ISO 24517 Any features from PDF specifications earlier than version 1.6 that are not explicitly mentioned in the PDF Reference are prohibited in PDF/E files.
This subclause permits the inclusion of future or third-party extensions in a PDF/E-1 conforming file, while ensuring that these extensions do not influence how a PDF/E-1 conforming reader displays the file.
General
The security features allowed in a PDF/E-1 conforming file and the restrictions and requirements placed on conformant consumers regarding their processing of PDF/E-1 files are defined in 18.2 to 18.4
This part of ISO 24517 allows PDF/E-1 conforming documents to be encrypted
This section of ISO 24517 does not address how readers, whether interactive or non-interactive, acquire passwords to access encrypted documents Interactive readers can directly request this information from users, while non-interactive readers must rely on specific implementation methods, such as using a separate communication channel or an associated job ticket.
Encryption version
If a PDF/E-1 file contains an encryption dictionary, it shall contain a V entry The value of the V entry shall be 1, 2, or 4
Copyright International Organization for Standardization
Direct objects in the encryption dictionary
The values of all entries of Tables 3.18, 3.19, 3.21, 3.22, and 3.24 in PDF Reference whose types are string, array, or dictionary shall be direct
This clarification ensures that all strings, dictionaries, and arrays within the encryption dictionary, as specified in the PDF Reference, must be direct, regardless of their nesting level While ISO 24517 does not impose similar restrictions on entries defined by other security handlers, it is crucial that any strings used for decryption remain direct to prevent circular dependencies when accessing the encryption dictionary upon document opening.
User access permissions
A PDF/E-1 conforming reader shall restrict user access to an encrypted PDF file according to the permissions contained in the file
General
PDF Reference outlines various signature features, but some depend on algorithms for computing digest values that lack comprehensive documentation In contrast, PDF/E limits the use of signature features to those that are clearly and explicitly defined Sections 19.2 to 19.5 detail the restrictions on digital signature features permissible in a PDF/E-1 file, while sections 19.6 to 19.10 specify the behavior of PDF/E-1 compliant readers regarding digital signatures.
Declaring the presence of signatures
A PDF/E-1 compliant file with signature fields must include a SigFlags entry in the interactive form dictionary, where the low-order bit is set to 1 Conversely, if the document lacks signature fields, the SigFlags entry should either be missing or have the low-order bit set to 0.
NOTE This subclause guarantees that the SigFlags entry accurately reflect the status of the document with respect to the presence of signature fields.
Signature dictionaries
A signature dictionary shall appear as the value of the V entry in at least one signature field in the document
A signature dictionary shall contain a ByteRange entry that spans the entire document at the time of signing, excluding the signature’s Contents entry
A signature dictionary may have a References array
PDF/E-1 mandates that all signatures must be linked to a signature field To create invisible signatures, one can use an empty appearance stream and set the Rect entry to [0 0 0 0] for the widget annotation of the signature field Additionally, PDF/E-1 stipulates that the complete file must be included in the calculation of the signature digest.
Signature reference dictionaries
A signature reference dictionary shall have a TransformMethod entry with a value of DocMDP
The P entry in a signature reference dictionary’s TransformParams dictionary shall have a value of 1
NOTE The use of FieldMDP, Identity, and UR transform methods is prohibited by this requirement
Document permissions dictionary
The document permissions dictionary shall not contain UR entries
The document permissions dictionary may contain a DocMDP entry The value of this entry, a signature reference dictionary, shall conform to the restrictions detailed in 19.2.
Detection and notification
A PDF/E-1 conforming interactive reader shall provide features to inform the user of the presence of signatures and to view the signature information.
Display of signature fields
A PDF/E-1 conforming reader shall display the normal appearance of a signature field’s associated Widget annotation.
Detection of changes
An interactive PDF/E-1 conforming reader must include features that verify if the document has been altered since signing It should assess and display the signature's validity while adhering to all relevant restrictions associated with the signature.
Prevention of changes
An interactive PDF/E-1 compliant reader must respect all restrictions on document modifications set by digital signatures Specifically, if the document's permissions dictionary includes a DocMDP entry, the reader is required to prevent any alterations to the document.
Verification of the identity of signer
An interactive PDF/E-1 conforming reader may provide tools for verifying the identity of the signer
An interactive PDF/E-1 conforming reader must notify users if a signer's identity is unverified It should also clarify whether this issue arises from insufficient resources, lack of verification support in the reader, or an invalid signer identification.
Verification of a signer's identity may necessitate access to external resources, such as servers and data, which are not guaranteed to be available on the system where the reader operates Therefore, it is not mandatory for an interactive PDF/E-1 to conform to signature verification requirements.
Copyright International Organization for Standardization
This annex presents a series of use cases that attempt to capture some of the most common applications (both existing and potential) of PDF/E for the exchange of engineering information
This collection of use-cases was developed by the joint members of ISO/TC 171/SC 2 and AIIM utilizing both their direct knowledge, and their industry expertise
This document does not aim to comprehensively list all uses of PDF/E for engineering information exchange, but it highlights potential areas where the PDF/E structure could be beneficial.
Manufactured or modular construction refers to buildings constructed in a factory and transported to their final location, rather than being built on-site These structures must comply with the building codes and regulations of their destination and undergo an approval process to ensure proper construction Typically, the manufacturer does not conduct the plan review approval; instead, this review is carried out by a third-party agency, with the approved plans subsequently submitted to the final regulatory authority.
Users of modular and engineered housing include:
The workflow begins with the manufacturer creating design drawings and converting them into PDF files for review by a third-party agency to ensure compliance with building codes Upon approval, the agency stamps and digitally signs the plans before submitting them to the final regulatory agency If revisions are necessary due to code violations, the agency utilizes comment and markup tools in Acrobat to indicate required changes, returning the plans to the manufacturer for adjustments This process continues with resubmissions until the plans receive approval, digital signatures, and are forwarded to the final regulatory agency The final agency then conducts its review, affixes approval stamps, seals the drawings with a digital signature, and returns the approved documents to the manufacturer for construction.
The benefits are the following:
⎯ fast secure document exchange between manufacturer and reviewer;
⎯ a significant cost advantage over paper and postal review methods;
⎯ document storage is far more efficient;
⎯ changes or markup can be easily identified to speed re-review times;
⎯ PDF/E drawing exchange is platform and program independent, which allows diversity in both manufacturing and review environments
The requirements or best practices are the following
⎯ Final engineering documents need to comply with regulatory agencies’ specific requirements
⎯ Digital signatures used to “seal” and certify engineering documents in lieu of the traditional “wet stamp”
⎯ Third party review stamp annotations should be flattened prior to transmission to ‘lock’ the stamp to the page
Engineering documents often require submission to regulatory agencies for approval or official notification Although this process may appear to be merely archival, the PDF/E format enhances the regulatory utility of these documents.
Copyright International Organization for Standardization
The workflow involves several key steps: first, the engineering professional submits the final documents to the regulatory agency; next, the agency adheres to its internal procedures for handling these documents Additionally, it is often necessary for engineering documents to be professionally “sealed,” and two formats have been identified for electronically sealing these documents.
1) In the case of engineering documents that need a single seal, or are sealed by a single professional, the use of a digital signature on the entire PDF file is recommended
Engineering documents typically originate from various sources before being submitted to regulatory agencies By using PDF and PDF/E formats, separate digitally signed documents can be attached to a master sealed cover letter or digital envelope This approach enables a lead professional to digitally sign and seal the complete set of documents, which have been individually signed and sealed by multiple subcontractors.
The benefits are the following:
⎯ a significant cost advantage over paper and postal methods;
⎯ document storage is far more efficient;
⎯ PDF/E drawing exchange is platform and program independent, which allows diversity in both the engineering professional and regulatory environments
The requirements or best practices are the following
⎯ Final engineering documents need to comply with regulatory agencies’ specific requirements
⎯ Digital signatures used to “seal” and certify engineering documents in lieu of the traditional “wet stamp” on paper
A municipal planner can better judge proposals by seeing the impact of structures on skylines or landscapes
An architect can bring a project to life on the desktops of clients, contractors, and colleagues with interactive, photorealistic models and fly-through animations
Plant owner-operators can lower their total cost of ownership by equipping maintenance crews with composite PDF documents that feature hierarchical animations for access and dismantling procedures, facilitating equipment repairs and refits These comprehensive PDF files can also incorporate interactive 3D models, work instructions, specifications, and schedules, all in one place.
Members of the public will better understand proposed changes to infrastructure and cast more informed votes for approval or rejection
PDF/E serves as an essential format for manufacturing, enabling the production of prototypes directly from 2D drawings rendered in the PDF/E file By embedding 3D data, it effectively conveys design intent, providing clarity that may not be apparent in traditional 2D representations.
Engineers often create PDF files for manufacturing, but shop floor workers may need clarification on design details, such as hole depth These inquiries can delay prototype lead times due to back-and-forth communication between engineering and manufacturing However, if shop floor personnel can access a 3D representation alongside the 2D drawings, the design intent becomes clearer, reducing the need for further clarification from engineering.
Users vary from municipal planners to engineering clients
The workflow varies with application
The benefits are the following:
⎯ a significant cost advantage over paper and postal methods;
⎯ document storage is far more efficient;
⎯ PDF/E drawing exchange is platform and program independent, which allows diversity in both the engineering professional and regulatory environments
Assembly instructions show how parts fit together and utilize part numbers, or animations showing parts Assembly instructions include parts catalogues and maintenance and repair manuals
Copyright International Organization for Standardization
The workflow includes the manufacturer creating a catalogue of details and repair drawings to be distributed to their maintenance facilities to aid with repair of assemblies
The benefits are the following:
⎯ a significant cost advantage over paper and postal methods;
⎯ document storage is far more efficient;
⎯ PDF/E drawing exchange is platform and program independent, which allows diversity in both the engineering professional and regulatory environments
The engineering workflow includes steps where it is necessary to generate printed documents with various levels of quality and quantity, for example
Users can request varying quality levels for their printing needs, ranging from drafts to high-quality outputs, with quantities that may range from a few copies to thousands Printing can be centralized in one location for distribution or executed in multiple global locations, allowing for flexibility in the print and distribution process.
The documents intended for printing typically include standard multi-sheet files as well as specialized engineering documents that feature larger sizes and graphical elements These original documents are often created using various applications, such as CAD systems, GIS software, and MS Office.
At printing time, it may be necessary to add additional signage like a stamp, print date, scaling factor
Depending on infrastructure, the printing work can be done in-house or by outside engineering department or commercial reprographers
Printing must be achievable independently of original CAD applications and without assumptions regarding the printer environment Additionally, it is essential to ensure that the print results are clearly defined and predictable.
The content of the file to be printed should be tamper-proof, thereby addressing security issues and enabling some legal assurance
PDF/E-1 supports engineering workflows by incorporating 3D models, allowing users to view the model from various angles and under different lighting conditions This interactivity enhances the user experience, making it easier to analyze and understand complex designs.
24 © ISO 2008 – All rights reserved is possible to produce a printed snapshot of this model at operator’s request These snapshots are derived from the view currently displayed on the screen