32000-2 requests (post-Beijing)
PDF Reference >> 32000-2 Requests >> 32000-2 requests (post-Beijing)
3D, CAD and Engineering
** Post Beijing** Request Title Incorporate the 3D algorithm, PRC into Part 2.
Incorporate the 3D algorithm, PRC into Part 2.
Request Submitted By
Adobe Systems
Executive Summary
Acrobat 8.1 introduced a new 3d algorithm, PRC. ISO 32000-2.
Rationale
To adopt Adobe extensions.
Use Case(s)
Please fill
Other Remarks
Please fill
** Post Beijing**
Non-Scaling Lines and Patterns
Request Title
Non-Scaling Lines and Patterns
Request Submitted By
ISO 24517 (PDF/E)
Executive Summary
Extend the existing PDF rendering model to include the notion of lines and patterns that don't scale to the supplied transformation matrix.
Rationale
Certain types of CAD solutions require this.
Use Case(s)
Other Remarks
Document Features
** Post Beijing** Association of an Action with content objects is the ability to have links (or other types of actions) directly connected to a set of content operators that enabling non-rectangular/quad-based (perhaps even disconnected) shaped areas that can be actionable. This will work exactly as Optional Content does by using marked content operators that point at a relative data structure with more info. The technical material will be to copy 8.11.3 (Making Graphical Content Optional) to 12.6.5 (Actions) and then modify accordingly. Association of an Action with content objects
Request Title
Association of an Action with content objects
Request Submitted By
Bentley Systems
Executive Summary
Rationale
An area of a hyperlink may cover a very large area covering other objects. Would like an option to have the hyperlink area only be on the object, like the properties behavior.
Use Case(s)
CAD Drawings
Other Remarks
Any other remarks you'd care to provide.
Use of native Unicode in PDF page content streams
** Post Beijing**
|
Request Title |
Use of native Unicode in PDF page content streams | |
| Request Submitted By | Microsoft, et. al. | |
| Executive Summary | More accurate metadata behind all page content. | |
| Rationale | Currently page content requires using glyphs and code mapping to render content that is not 7-bit ANSI text. The current mapping method works adequately where the mapping is 1 to 1 or many Unicode to 1 glyph, but not many to many or in 1 Unicode to many glyphs as is the cases in much of the Complex Script world and other shaped text. Current implementation can cause poor behavior for search, selection, copy/paste, etc. | |
| Use Case(s) | Arabic, Thai, Tamil (and others), OpenType (ligatures in some instances, some adornments, math).
OCR with hidden text - needs more info from others. |
|
| Other Remarks | An alternative for the shaped text would be a better mapping table solution, or in-place mapping tables. For every text cluster you have a Unicode ID, a glyph ID and a array of indices that maps between them. For an example see "5.1.2 Mapping Code Units to Glyphs" of the XML Paper Specification (TC46). |
** Post Beijing** Associate annotations (especially comments) directly with page content
Request Title
Associate annotations (especially comments) directly with page content
Request Submitted By
callas
Executive Summary
Currently comment annotations are syntactically separate from the page content they (seemingly) refer to; on the background of improved accessibility it should become possible to assiociate a comment directly with the portion of the page it is commenting on.
Rationale
Use Case(s)
Provide one or more use-cases. You may attach files to this page
Other Remarks
Any other remarks you'd care to provide.
** Post Beijing **
Improved file provenance and "audit trails"
Request Title
Improved file provenance and "audit trails".
Request Submitted By
Adobe Systems
Executive Summary
Standardize metadata format for inclusion of document processing history.
Rationale
Use Case(s)
Other Remarks
** Post Beijing ** Page Range Metadata
Request Title
Page Range Metadata
Request Submitted By
ISO 16612-2
Executive Summary
A language feature needs to be introduced that enables a hierarchical grouping of named page ranges. Currently, the recommendation is to extend the /Outline tree
Rationale
Ability for out-of-band communication to refer to a named set of pages that are organized in a hierarchical fashion.
Use Case(s)
Provide one or more use-cases. You may attach files to this page
Other Remarks
Any other remarks you'd care to provide.
Accessibility
The following items are to be forwarded to the US PDF Reference Committee for consideration during the 2009 Hamburg ISO conference. See PDF/UA's 2008 Beijing Conference requests or 32000-2 Requests: Orlando. Request Title Change to Table 323 Table 323, change ID key from Optional to Required in cases where a Reference tag (See Table 338) is present in the PDF. Following 14.8.5.5, add a new section, as follows: If present, the Destination attribute, described in Table (see below) shall appear in a Reference element. It provides viewers following the tag structure with a means to access content (typically footnotes and endnotes) referred to in the text of a document. Request Title Change to Table 330 – add three new rows: The following types of artifacts can be specified by the Type entry: Table 330, change the Value of the Subtype key to include new valid value: PageIdent Request Title The Note to Table 337 says "Lookup is heuristic". This will lead to inconsistent behavior by AT. No algorithm is given in ISO 32000-1 to address the case in which header cell IDs and table data cell IDs are not present. In the case that header data cell IDs and table data cell IDs are not specified, this change specifies an algorithm to associate table header cell(s) with table data cell(s). The current ISO 32000 algorithm is flawed. The recursive lookup mentioned in Table 349 (Headers) is ambiguous in that the headers might be only associated with a row, a column, or both. The following suggested change to Table 349 requires that a recursion be explicit. In particular: The following description of the Headers and Scope attributes should replace the description in ISO 32000, Table 349, Standard table attributes. (Optional; not inheritable) An array of byte strings, where each string shall be the element identifier (see the ID entry in Table 323) for a TH structure element that shall be used as a a header associated with this cell. This attribute may apply to header cells (TH) as well as data cells (TD) (see Table 337). The order in which they are listed shall be row IDs followed by column IDs. The row and column IDs shall be ordered from most specific to most general. For any cells with an ID listed in Headers, those cells shall specify a Scope so that the header can be determined to be either a row header, a column header or both. (Optional; not inheritable) A name whose value shall be with one of the following: Row, Column, or Both. This attribute shall only be used when the structure type if the element is TH (see Table 337). If a Scope is not specified, then the assumed value for the Scope shall be: Below Table 337, delete Note 2 and insert the following text: If the Headers attribute (Table 349) is not specified, the following algorithm determines which headers are associated with any given cell by finding an ordered list of row and column headers: To find headers for any data or header cell, search left/up from the cell's position to find row/column header cells. The search in a given direction stops when any of these conditions is reached: When a header cell is found in the search and the (implicit or explicit) Scope of the header cell is either Both or Row/Column, the header cell is appended to the end of the list of row/column headers, resulting in a list of headers ordered from most specific to most general. Informative Note: This algorithm works for languages with different intrinsic directionality of the script (such as right-to-left) because the structure always reflects the reading order of the table. Request Title PDF/UA would require (shall) this structure in the case of line-numbered content, however, new structure elements are required to support the concept. PDF/UA would then specify usage as follows: Add a new row to Table 333 as follows: Add a new row to Table 338 as follows: LineNum Request Title Add new rows to Table 338 as follows: Destination
Add a "Destination" concept for structure tags.
Request Submitted By
PDF/UA
Executive Summary
Make it possible for user to follow a logical reference from one tag to another (such as with an endnote reference and the endnote itself).
Rationale
References need to be associated with a note at the logical level to allow AT users navigation to foot- and end-notes while retaining their original place within the document’s logical reading order.
Use Case(s)
Any document with footnotes, endnotes, cross-references, sidebars, pull-quotes or other cases in which content refers logically to other content.
Details of Proposed Change
New Section
Reference Attribute
Standard Reference Attribute
Key
Type
Value
Destination
Byte string
(Required) The ID (see Table 323) of the Reference's Destination tag.
Artifacts
Changes to Table 330
Request Submitted By
PDF/UA
Executive Summary
Addresses the need to make artifacts accessible if/when deemed desirable by the author/user.
Rationale
Artifacts may or may not have semantic value, even if they do not appear in the tag tree. PDF/UA requires that artifacts be available to AT in principle, if not generally in practice.
Use Case(s)
Details of Proposed Change
Key
Type
Value
Alt
Text String
(Optional) An alternate description of the artifact in human readable form.
Lang
Text String
(Optional) A language identifier specifying the natural language for all text in the artifact. If this entry is absent, the language (if any) specified in the document catalog applies.
ActualText
Text String
(Optional) Text that is an exact replacement for the artifact. This replacement text (which should apply to as small a piece of content as possible) is useful when extracting the document’s contents in support of accessibility to users with disabilities or for other purposes.
Scope and Header attributes of tables
Modify definition of Scope, Headers, and ID attributes of Tables
Request Submitted By
PDF/UA
Executive Summary
Specify an algorithm for associating header cells in a table with data cells in a table. Additionally, clarify the specification of Scope, Headers, and ID attributes so that header lookup through IDs is well-defined. This modifies the description of these attributes given in Table 337 and Table 349. No new tags or attributes are requested.
Rationale
The existing description for tables lacks a precise definition of how headers are associated with table cells. Such a definition is needed so that authors and AT agree on which header is associated with which cell, especially for non-trivial tables.
Use Case(s)
AT needs to know how to find row and column headers associated with each cell.
Details of Proposed Change
Headers
array
Scope
name
These assumptions are used by the algorithm following Table 337 for determining which headers are associated with a cell.
Line Numbering
Make line-numbering accessible
Request Submitted By
PDF/UA
Executive Summary
Provide sematic structure elements to allow correct tagging of line-numbered content.
Rationale
Use Case(s)
Documents that use line-numbered sections.
Details of Proposed Change
Structure Type
Description
LineGroup
A generic block-level element that encloses line-numbered content.
Structure Type
Description
An inline element used for each line number within a LineGroup to tag the line numbers.within a LineGroup block.
Redaction
Make redaction accessible in PDF
Request Submitted By
PDF/UA
Executive Summary
Ensure that sematic structure elements exist to allow correct tagging of a redacted document.
Rationale
While redaction is a common process in government, legal, heathcare and other sectors, no method presently exists for assuring the accessibility of redacted documents.
Use Case(s)
See Rationale
Details of Proposed Change
Structure Type
Description
Redaction
An inline item (visible or invisible) of content indicating a redaction.
Justification
An item of content indicating a justification or explanation (often known as an Exemption Code) for one or more redactions.
Color
Enable N-Colorant ICC profiles as source profiles
** Post Beijing **
Request Title
Enable N-Colorant ICC profiles as source profiles to support ICC requirements
Request Submitted By
ICC
Executive Summary
Extend PDF profile handling capability to accept N-colorant ICC profiles as source profiles.
Rationale
Use Case(s)
Other Remarks
** Post Beijing ** Support for DeviceLink profiles
Request Title
Support for DeviceLink profiles.
Request Submitted By
Dave McDowell
Executive Summary
Ability to carry DeviceLink profiles as extensions to Output intent.
Rationale
Use Case(s)
Other Remarks
Architecture
** post-Beijing ** Request Title Support for Newspaper XML document instances and related style-sheets
Support for Newspaper XML document instances and related style-sheets
Request Submitted By
NAA
Executive Summary
Carry Newspaper XML into PDF workflows
Rationale
Use Case(s)
Other Remarks
Other
How To Guide
Request Title
"How To" Guide
Request Submitted By
Appligent Document Solutions
Executive Summary
The PDF Reference exists today as a dictionary, only a partial reference that does not tell one how to use it to draw content together. Postscript has two other books that describe how to use PostScript. We could produce a "Technical Report" or "How to Guide" for PDF.
Rationale
Make it easier to develop with PDF
Use Case(s)
Other Remarks
To be presented in Orlando to gauge interest form interested parties. PostScript Green and Blue books to be added to the ISO-32000 Bibliography.
One possible approach will be to revise the xref table structure. Alternatively some altogether new mechanism that will replace current xref table structure might be considered. Whatever the solution, it must remain possible to have random access to arbitrary parts of a PDF file. Adobe points out that with the use of Xref streams (PDF 1.5), the 10G limit is no longer present. PDF file size beyond 10 GB (non-US)
Request Title
PDF file size beyond 10 GB
Request Submitted By
Olaf Drümmer, PDF/A Competence Center
Executive Summary
In certain environments (for example those trying to move from traditional spool formats like AFP to PDF) the current effective file size limit of about 10 GB it turning into a problem. File sizes beyond 10 GB should be made possible.
Rationale
In larger companies that have traditionally used print spool formats like AFP for both print production as well as archiving there is a tendency to switch to PDF. In some cases at least resulting file size are several GBs, with a tendency to grow even further, and in the end to grow beyond 10 GB. Currently this is not feasible. If it remains unfeasible users will have to look for alternatives to PDF.
Use Case(s)
creation, storage/archival, retrieval of pages from of very large PDFs (hundreds of thousands or millions of pages)
Other Remarks
Share referenced resources between PDFs
Request Title
Share referenced resources between PDFs
Request Submitted By
Olaf Drümmer / PDF/A Competence Center
Executive Summary
In collections of numerous PDFs the shared use of referenced resources - like fonts or ICC profiles, maybe even partial pages like logos - can substantially reduce effective file size.
Rationale
In certain environments - just think of the millions of invoices a telco company has to send out each month - the major portion of the effective combined file size is due to the repeated inclusion of the very same resources (and not by the actual content). Even though one could opt to not include fonts a safer approach is needed, where the exact same font can be retrieved to guarantee perfect rendering.
Use Case(s)
Very large numbers of very similar PDFs where all (most) of them use the same resources over and over again. Main advantage: reduced storage needs while maintaining unambiguous rendering.
Other Remarks
A possible implementation could pick up what has been specified in PDF/X-4p for a referenced OutputIntent profile.
[[include:pdfISO-pb-FR0001] [[include:pdfISO-pb-FR0002]
