It’s a question that vexes vendors of web-based solutions everywhere: why do people still insist on PDF files? And why does PDF’s mindshare keep going up? “PDF is such antediluvian technology!” they say. “It’s pre-web, are you kidding me? It’s so old-f …PDF Association technical resources: an overview
PDF is PDF because files produced with one vendor’s software can be read using a different vendor’s software with no loss of fidelity. Interoperability is key to our industry. The PDF Association is a international membership organization dedicated to …2022: The last year of paper for records-keeping
NARA (The National Archives and Records Administration) is the final depository for the long-term records generated by all other agencies of the U.S. Federal Government. The agency has a key role in preserving the cultural history of the republic as we …PDF 2.0 examples now available
The PDF Association is proud to present the first PDF 2.0 example files made available to the public. Created and donated to the PDF Association by Datalogics, this initial set of PDF 2.0 examples were crafted by hand and intentionally made simple in construction to serve as teaching tools for learning PDF file structure and syntax.PDF 2.0 interops help vendors
The PDF 2.0 interop workshops included many vendors with products for creating, editing and processing PDF files. They came together in Boston, Massachusetts for a couple of days to test their own software against 3rd party files.
by Dietrich von Seggern
PDF/X was the first ISO standard based on PDF technology. A subset of the PDF specification, PDF/X was designed to constrain PDF files in order to cater to specific use-cases. The first part, PDF/X-1a, based on PDF 1.3, came out in 2001. Why did that happen?
In the 1980s, Adobe invented PostScript, a standard page description language that allowed for connecting any (PostScript) printer to any (PostScript) layout application / computer. PostScript serialized page description commands so that a printing device could convert them into a printed page without big processors or lots of memory; at that time, a very important requirement. However, PostScript was not designed to be saved to a disk, it usually resulted in very large files and on screen rendering was – if at all possible – time consuming.
As the developer of Photoshop, FrameMaker and Illustrator, Adobe had a strong graphic arts background. However, when they designed PDF to overcome the shortcomings of PostScript they initially thought of it more as an exchange format for documents. What Adobe did not see – at least not in the beginning – was the desperate need for a data exchange format in the print industry as well.
In the 1990s, the print production marketplace was disrupted by desktop publishing technologies bringing what used to be very expensive tools to the average user’s desktop. This change affected the cost and equipment used by print production companies, and generated a need for exchanging print layouts between companies.
At that time, I was working for the German newspaper marketing organization responsible for a network connecting advertising agencies with newspaper production facilities. EPS (Encapsulated PostScript) was used as the exchange format. It was – compared to PDF – huge, no viewers were available, it was not easy to parse and preflight, fonts were usually not embedded and had to be sent separately, and so on.
Due to the limitations of EPS, we were constantly searching for a replacement. Unfortunately, all candidates (there was PDF 1.0 but also a few others) were too focused on document processes and did not support the print color space with CMYK and many other core requirements of prepress. When Adobe announced PDF 1.2 – which would not only support CMYK, but in addition create very small files even for high resolution images – it sounded too good to be true.
PDF 1.2 was a great step forward, but there were still a few weaknesses and particularly one important shortcoming: the lack of spot color support. PDF’s ability to change the whole prepress production chain was nonetheless becoming clear. In 1998, a group of European prepress experts wrote a white-paper on “PDF for prepress” and sent it to Adobe; almost all of this group’s recommendations were addressed in PDF 1.3. From that point forwards PDF was a cornerstone of graphic arts workflows.
PDF’s inherent flexibility made it clear that not every PDF file could be used for printing, a fact that triggered developers to create preflight tools to establish whether a given PDF file met the requirements of the printing industry.
To streamline their own workflows, printers started to develop their own requirements for PDF files, and they shared these requirements with the creators of the PDF files that they had to process and print.
Technically this made a lot of sense, but this approach had some major limitations: First, it required that a print file creator had to align their PDF files with the print house of choice, which meant that a PDF file acceptable to one print house might be refused by another. Discussing the print house’s specific requirements, which might be necessary to alignment, represented overhead, and didn’t scale well.
Even more important was the fact that print file creators were usually also the printer’s customers or at least closely affiliated with them. They discovered that it is difficult to apply strict rules that potentially require addition.al work to an input when the supplier is at the same time the customer. What’s more likely that the customer just goes elsewhere to find a printer that conforms to the customer’s preferences rather than being forced to match preferences with the print vendor.
It was clear that what was needed was a clear 3rd party specification – a standard – for both creator and receiv.er. This urgent need for independent rules for print-ready PDF culminated in the development of PDF/X.