Non-US Requests
Output intent enhancement
SUBMITTED BY DIN
| Request Title | Output intent enhancement |
| Request Submitted By | TC 130 |
| Executive Summary | Add ability to have have individual Output intents for each object in a PDF document. |
| Rationale | Merging of multiple PDF/X-3 documents with differing output intents (ie, profiles) requires that they be merged in the output device-space. |
| Use Case(s) | |
| Other Remarks |
Black Point Compensation
SUBMITTED BY DIN
|
Request Title |
Black Point Compensation |
| Request Submitted By | Callas/ECI |
| Executive Summary | |
| Rationale | |
| Use Case(s) | |
| Other Remarks | Further discussion |
Add processing instruction for color conversion
SUBMITTED BY DIN
| Request Title | Add processing instruction for color conversion |
| Request Submitted By | ECI/callas |
| Executive Summary | introduce "Do not convert", "Adjust tone value only" in addition to current rendering intents and PCS based color conversion model |
| Rationale | Color conversions in graphic arts is doing all this already based on heuristics (like: keep black text on black plate; do not convert grayscale image to 4c) - the suggested instruction will make this a predictable process again |
| Use Case(s) | Black text -> shall remain black; grayscale images -> shall remain on black plate; for spot colors -> adjust tint values; for process and spot combinations (as in duotone images) adjust the whole image appropriately |
| Other Remarks | Any other remarks you'd care to provide. |
Specify exactly how color has to be rendered on an output device
| Request Title | Specify exactly how color has to be rendered on an output device |
| Request Submitted By | callas/ECI |
| Executive Summary | Currently it is not fully specified when and how to convert source color values in a PDF for display/rendering on an output device; there is also currently no clear concept of proofing simulation versus "direct output". Use of Output Intents is not sufficiently specified |
| Rationale | Reduce ambiguity, especially in uses where exact color rendering is key; it may be OK to define a "precise color mode" and only require specifics for such a mode. |
| 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. |
No more uncalibrated color in a PDF
| Request Title | No more uncalibrated color |
| Request Submitted By | callas |
| Executive Summary | In some places (like, color of an annotation) it is still common to just have 3 numbers as an (uncalibrated) RGB triple; thus such objects may look different in different/viewers |
| Rationale | Remove ambiguity of rendering of any color aspect in a PDF file; wherever coor is specified in a PDF it shall be specified in a calibrated way |
| Use Case(s) | borders/lines/background in annotations, for fields; color of pop-up annotations |
| Other Remarks | it is to be discussed whether intentional use of just DeviceRGB in a content stream shall still be acceptable... |
Extend color model for better support of spot colors and overprints between spot colors (and with process colors)
| Request Title | Extend color model for better support of spot colors and overprints between spot colors (and with process colors) |
| Request Submitted By | ECI/callas |
| Executive Summary | Currently spot color rendering on a monitor (or any device that does not support such spot color directly) is based on heuristics, especially for intermediate tints and for overprints between one spot and another spot or process color |
| Rationale | Improve reliability of rendering (and color conversion) |
| Use Case(s) | Provide one or more use-cases. You may attach files to this page |
| Other Remarks | N-Color source profiles in theory could solve some of this, but in the real world it will not be viable to come up with n-color profiles for all the situations where they are needed. Some more generic and more flexible architecture will be needed (possibly based on spectral data?). |
Other
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. |
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 |
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. |
