At the PDF Europe 2018 Joris Schelekens from iText will hosting a presentation titled “Structure Recognition for Information Retrieval and Layout” – what’s that about?”. In this interview he gives some background information about his presentation.Five reasons developers should participate in PDF Days Europe
PDF Days Europe, the annual PDF technology education event, will take place from 14 to 16 May 2018 in Berlin at the Hotel Steglitz International. Of the many good reasons for developers to participate, here are five of the best.5 reasons why those implementing electronic document technologies should attend PDF Days Europe
PDF Days Europe, the annual PDF technology education event, will take place from 14 to 16 May 2018 in Berlin at the Hotel Steglitz International. Of the many good reasons for users to participate, here are five of the best.2018 PDF 2.0 Interop Workshop
Following the success of our previous interop workshops in Cambridge, England and Boston, Massachusetts, the 3rd PDF 2.0 Interop Workshop takes place on May 16, 2018 as part of the post-conference program immediately following this year’s PDF Days Euro …Post-Conference of PDF Days Europe 2018 in Berlin
On Wednesday, May 16, 2018, directly following PDF Days Europe, the PDF Days Post-Conference offers a variety of workshops on PDF 2.0 Interop or PDF/UA.
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.