The PDF Techniques Accessibility Summit’s objective is to establish a broad-based understanding of how PDF files should be tagged for accessibilty. It’s an opportunity to focus on establishing a common set of examples of accessible PDF content, and identify best-practice when tagging difficult cases.Modernizing PDF Techniques for Accessibility
The PDF Techniques Accessibility Summit will identify best-practices in tagging various cases in PDF documents. Questions to be addressed will likely include: the legal ways to tag a nested list, the correct way to caption multiple images, the appropriate way to organize content within headings.Refried PDF
My hospital emailed me a medical records release form as a PDF. They told me to print it, fill it, sign it, scan it and return it to the medical records department, in that order. In 2018? To get the form via email (i.e., electronically), yet be asked to print it? Did the last 20 years just… not mean anything! So I thought I’d be clever. I’d fill it first, THEN print it. Or better yet, never print it, but sign it anyhow, and return it along with a note making the case for improving their workflow. The story continues…Slides and video recordings of PDF Days Europe 2018
You missed the PDF Days Europe 2018? Never mind! Here you can find the slides and video recordings of all 32 stunning sessions!Using PDF/UA in accessibility checklists
PDF/UA, like PDF itself, is internally complex, but used correctly, actually makes things easier.
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.