Page Geometry
The page geometry frames of a PDF file are the boxes available in the PDF. There are five different page geometry frames:
TrimBox [1] – The final format frame, also called TrimBox, represents the final size of the printed and cut document. A document designed for printing requires a final format frame. The size of the final format frame must be smaller than or equal to the bleed and media frames.
BleedBox [2] – The bleed frame, also called the BleedBox, is an extended area around the final format frame that trims all page content in the output. A document that has been designed to drop (beyond the edge) also requires a bleed frame, which in practice is between 1 and 10 mm, depending on its use. The bleed frame should always be larger than the final format and smaller than the media frame. Print marks such as registration marks, crop marks or color bars should always be outside the bleed area.
MediaBox [3] – The media frame, also called MediaBox, represents the physical size of the media and corresponds to the selected paper format used when printing to a PostScript or PDF file. The media frame thus contains all the objects on a document page that appear on the page or protrude beyond the edge of the page size.
ArtBox [4] – The object frame, also called ArtBox, forms a frame drawn around all printable objects and defines the content to be placed on the page as intended by the document creator. The final format frame and the object frame usually have the same size, but this is forbidden in connection with PDF/X files - here only either object or final format frames may be present.
CropBox [5] – Mask frames, also called CropBox, are created by trimming the page with suitable tools. The mask frame is used by default both for display in PDF display programs and for placing PDF files in layout programs.
PDF stands for Portable Document Format. In 1991, Adobe co-founder John Warnock launched the Camelot project. The aim was to develop a file format that would allow documents to be captured from any program, sent as an electronic file and displayed and printed independently of the end device. In 1992, Camelot evolved into PDF, which has become the de facto standard in the graphics industry over the decades. The origin of PDF actually lies in the display list, an intermediate state of the RIP process of a PostScript file that is stored in a document. PDF is therefore a pure "object-based file format" to which no calculations or procedures need to be applied in order to enable output to screen or paper.
The following four properties speak in favor of using PDF in prepress:
- Cross-platform visualization - the content of a file can be displayed on all operating systems. The PDF format can save all content that can be written with PostScript. In addition to Adobe Reader, current operating systems have integrated PDF viewers that can also be used for display.
- Font embedding - an important point for a cross-platform display is that fonts can be reproduced accurately. The used fonts can be embedded directly in a PDF file.
- Low data volume - storage space can be reduced by encoding page content much more compactly and simply storing identical objects/images.
- Random access to objects, pages and file structure - PDF allows random access to objects and pages of a document. The individual components are separate objects in the file and can also be used multiple times on different pages. It does not matter whether it is text, vector graphics or images.
PDF works with the Adobe Imaging Model, i.e. the graphics model of PostScript. A PDF can consist of three page objects:
- Vector or path objects - a sequence of individual or connected points, lines and curves that are mapped in the PDF file in the form of path construction operators.
- Text objects - consist of one or more glyphs that are mapped as path objects in a separate data structure, the fonts. Like path objects, text objects can also consist of an outline and a fill.
- Image objects - rectangular areas consisting of individual pixel values that are stored by their unique position in the rectangle and the color values.
With each new Acrobat version, the associated PDF specification has also been changed. Extensions have been made to the format which open up new possibilities for certain areas of PDF application. Here is an overview of Acrobats' version designation and the corresponding PDF version:
Table 1: Overview of the PDF versions
Acrobat version |
PDF version |
PostScript version |
PostScript subversion |
Year |
---|---|---|---|---|
Carousell |
1.0 |
PostScript Level 1 |
- |
1992 |
Acrobat 2.0 |
1.1 |
PostScript Level 2 |
2014 |
1993 |
Acrobat 3.0 |
1.2 |
PostScript Level 2 |
2017 |
1996 |
Acrobat 4.0 |
1.3 |
PostScript 3 |
3010 |
1999 |
Acrobat 5.0 |
1.4 |
PostScript 3 |
3011 |
2001 |
Acrobat 6.0 |
1.5 |
PostScript 3 |
3015 |
2003 |
Acrobat 7.0 |
1.6 |
PostScript 3 |
3016 |
2004 |
Acrobat 8.0 |
1.7 |
PostScript 3 |
3016 |
2006 |
Acrobat 9.0 |
1.7 |
PostScript 3 |
3018 |
2008 |
Acrobat X | XI |
1.7 |
PostScript 3 |
3018 |
2010 | 2013 |
Acrobat DC | 2.0 | PostScript 3 | 3018:101 | 2017 |
PDF/A
The official designation ISO 19005 stands for standards that have been developed to describe methods for the long-term archiving of digital data. With PDF/A these ISO standards are defined. The "A" in the designation stands for Archiving and therefore the long-term storage of digital files. PDF/A is used for archiving plans or documentation, for example.
Table 2: Overview of the currently valid PDF/A norms
PDF/A level designation | Part of ISO | PDF versions |
---|---|---|
PDF/A-1 | 1 | 1.4 |
PDF/A-2 | 2 | 1.7 |
PDF/A-3 | 3 | 1.7 |
PDF/A-4 | 4 | 2.0 |
PDF/X
Standards have been developed with the official designation ISO 15930 - these standards describe methods for exchanging digital data in the graphic arts industry. ISO 15930 aims to standardize digital data exchange from a technical perspective in order to minimize potential sources of error. PDF/X describes precisely these ISO standards. The "X" in the name stands for "blind exchange", i.e. blind or secure data exchange.
The standards specify a series of rules that must be adhered to by PDF creators and processors. These rules are set out in the standard as optional, mandatory and required requirements. The mandatory and prohibited requirements of PDF/X are described below. Only PDF/X standards that enable complete data exchange are described.
Mandatory requirements
- Has to be a PDF file – the data structure of the underlying PDF file must consist of four areas header, body, cross-reference table, and trailer.
- Document ID – the document ID must be entered in the trailer to identify the file.
- Composite PDF file – a PDF/X file must be available as a composite file. Pre-separated files are not permitted.
- Complete embedding of fonts – all used fonts, the characters used in a font including the run-length table (only for PDF/X-4), and font encoding must be embedded.
- Tracking for fonts – while PDF/X-1a and PDF/X-3 were generous regarding the width information of a font, PDF/X-4 refers specifically to the presence of this information.
- The designation of the document has to be given for certain values – it is essential that the GTS PDF/X key and the information Title, Created on, Modified on and the information PDF created with are present in the PDF file in a completed and correct form.
- Document properties have to be compliant with the entries in the meta data – If document properties are entered, the values of the Document Information Dictionary must be set to the same values as the XMP file.
- Output Intent has to be present – it is mandatory to enter an output intent for PDF/X - except all PDF/X versions with the extension p such as PDF/X-4p or PDF/X-5pg.
-
Output Intent designation for PDF/X-4p – for those PDF/X versions where no output intent is required, further designation has to be made in the
DestOutProfileRef
. - Page Boxes have to be defined – each page of a PDF/X file must contain at least the TrimBox or the ArtBox, but not both together. The marking of the PDF size via the MediaBox can be inherited.
Prohibited Requirements
- LZW compression – for licensing reasons, the use of LWZ-compressed databases is not permitted.
- JavaScript and actions – the presence of JavaScript and Processes within a PDF/X file is not permitted, as this allows changes to be made to the PDF file before it is output.
- Safety restrictions – encrypting PDF files is not permitted in any way.
- OPI comments – all resources required for reproduction must be included (except PDF/X-2 and PDF/X-5). This is mandatory if a blind Exchange is to be achieved.
- PostScript-XObject – the use of PostScript XObjcts - XObject with subtype 2 - or various PostScript operators in a PDF/X is not permitted.
- BX/EX operators – the existence of BX and EX operators is also prohibited within the PDF content stream of a PDF.
- Transfer functions – the presence of a transfer function - stored in PDF as a TR or TR2 operator - is not permitted in a PDF/X file.
- Restricted requirements – these are conditions that may only be present with a precisely defined severity level so that the PDF/X can be created. The presence of a condition only prevents PDF/X creation if restrictions have been found for the condition.
Table 3: Overview of the currently valid PDF/X norms
PDF/X level designation | Part of ISO | Complete exchange | For media neutral Workflows | Supported color spaces | PDF versions |
---|---|---|---|---|---|
PDF/X-1:2001 | 1 | Ja | Nein | Bitmap, Grau, CMYK | 1.3 |
PDF/X-1a:2001 | 1 | Ja | Nein | Bitmap, Grau, CMYK | 1.3 |
PDF/C-1a:2003 | 4 | Ja | Nein | Bitmap, Grau, CMYK | 1.4 |
PDF/X-2:2003 | 5 | Nein | Ja | Bitmap, Grau, CMYK, RGB, ICCbased | 1.4 |
PDF/X-3:2002 | 3 | Ja | Ja | Bitmap, Grau, CMYK, RGB, ICCbased |
1.3 |
PDF/X-3:2003 | 6 | Ja | Ja | Bitmap, Grau, CMYK, RGB, ICCbased |
1.4 |
PDF/X-4:2008 | 7 | Ja | Ja | Bitmap, Grau, CMYK, RGB, ICCbased |
1.6 |
PDF/X-4:2010 | 7 | Ja | Ja | Bitmap, Grau, CMYK, RGB, ICCbased |
1.6 |
PDF/X-4p | 7 | Nein | Ja | Bitmap, Grau, CMYK, RGB, ICCbased |
1.6 |
PDF/X-5g | 8 | Nein | Ja | Bitmap, Grau, CMYK, RGB, ICCbased |
1.6 |
PDF/X-5pg | 8 | Nein | Ja | Bitmap, Grau, CMYK, RGB, ICCbased |
1.6 |
PDF/X-5n | 8 | Nein | Ja | n-colorant | 1.6 |
PDF/X-6 | 9 | Ja | Ja | Bitmap, Grau, CMYK, RGB, ICCbased |
2.0 |
PDF/X-6p | 9 | Nein | Ja | Bitmap, Grau, CMYK, RGB, ICCbased |
2.0 |
PDF/X-6n | 9 | Nein | Ja | n-colorant | 2.0 |
PostScript
The starting point for the development of PostScript (PS for short) was the desire to be able to depict two-dimensional objects. PostScript is a programming language that contains instructions with graphic functions, which are meaningfully strung together to describe a document page in the form of mathematical objects, independent of resolution. PostScript was developed to output text, graphics and images, which is why PostScript is also referred to as a page description language. In PostScript, a page is understood as a graphic, which can contain different graphic elements. The entire page is understood as a large coordinate system, which makes it possible to jump to any point in order to place a path or a geometric figure there. The position, rotation, drawing direction etc. of these objects can be changed using PostScript commands.
- Device-independent - graphics are not defined with reference to properties such as page size, color depth, resolution and halftone dot shape of a specific device, but device-independent.
- Resolution independence - when describing PostScript, it is not important what resolution the output device has or whether the document must be output in "knife sharpness" on a cutting plotter.
- Operating system-independent - PostScript files are simple text files that use the 7-bit ASCII character set and can therefore be processed on any operating system.
- Description of glyphs - the flexible assignment of the character set to all fonts, the integration of fonts into the graphics and the advantages of being able to treat glyphs as graphic elements are key strengths of PostScript. The typographic quality that PostScript makes possible with text alone was enough to revolutionize prepress.
- Downward compatibility - it should always be possible to generate PostScript Level 1 from any application. In the PDF environment, however, PostScript Level 2 should be used as a maximum.
There are no advantages when there are no disadvantages. The licensing of PostScript has inevitably led to some mutations that have resulted in disadvantages:
- PostScript extensions and dialects - many vendors took advantage of PostScript's capabilities and extended the features in their applications. These non-standardized applications led to some errors in the output. In addition, there were a variety of layout and graphics programs, some of which could generate PostScript themselves or in conjunction with a printer driver. These PostScript scripts were then "embellished" with PostScript extensions, resulting in numerous PostScript Level 2 dialects whose common core became smaller and smaller.
- Lack of structure - PostScript dialects and various extensions could be managed within a small processing chain by means of workarounds. However, the PostScript derivative lacked any structure for further processes. For this reason, Adobe issued the Document Structuring Convention (DSC) in 1996, which provided extreme relief.
- Performance - PostScript required an interpreter to make the contents of a file visible at all. This was usually implemented as a hardware RIP. The Hardware RIP was adapted to the hardware used. An upgrade to a new language version was therefore very cost-intensive.
Plate Configuration
Plate Templates – With version 1.11.0, the user can now save user defined layouts for printing plates as a template, which are required for conventional printing processes, in order to use this as a basis for an imposition and to transfer the entire imposition with the Plate configuration as a PDF to a platesetter.
PrePress digital - Softwareentwicklung GmbH
See Contact
Print Marks
Under Print Marks, all markings on a printout that are applied outside the print image for further processing. These Marks include:
- Color Control Strips [1] – These are usually applied only to the top and/or bottom edge of a printed sheet.
- Registration Marks [2] – Typically contain one set per sheet. In digital printing Registration Marks are no longer so important.
- Bleed Marks [3] – These are applied per page/motif.
- Crop Marks [4] – These are attached per page/motif
- Production Order Name [5] – These are applied per page/motif
- Page Number [6] – These are attached per page/motif
- Issue Date and Time [7] – These are applied per page/motif
Illustration: A visual overview of common Print Marks
Production Job
Print data is stored in the Workflow, together with job-related customer information, production and delivery data, and all information describing the actual output, such as substrate and color strategy, in so-called Production Jobs.
An Order can include one or more designs, it can also be "empty", i.e. the sales department can create an Order in the Workflow before the customer delivers the print data. These could be added to the Order later by an operator.
Production Job - Send to Printer
The final step in print production is usually to transfer the print data to the printer. This involves passing the document(s) or the Imposition to the integrated RIP with all the necessary rendering and color management parameters. The result of the RIP process is usually a device-dependent control instruction (job ticket) for the printer plus the required print data, which is then transferred to the printer via the network.
If a cutting device with a parameter set has also been selected in the Production Job, the cutting files for the print job are generated in the same process and also transmitted to the IP address stored for this purpose.
For the Workflow, the Production Job is initially completed after the transfer, which is why the status automatically changes to Sent to Printer. Whenthe connected printing system communicates with the Workflow, the status of the Production Job can still change automatically depending on the type of integration of the printing system.
Proof
In the printing industry, a Proof is a preliminary simulation of a print result to be used as a Template for the Production Run.
The aim of a Proof is to simulate what the subsequent print result will look like in order to detect possible errors at the earliest possible stage. In this way, errors are prevented from being discovered until after printing, thus avoiding complaints.
Proofs are usually output as a composite file on an inkjet printer that has more than 8 colors. In addition to the print data, a Proof must also bear a UGRA/Fogra Media Wedge in order to be color-compliant and legally binding. Thanks to the standardized Wedge, the printing company is thus able to check the Proof for correctness.