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.
The third part of the PDF/A standard was officially published by the ISO in October 2012 and is now available to the general public. Several members of the PDF Association quickly released new versions of their products which support PDF/A-3 to varying extents. Our seminars since then have been well attended, as the Single Feature standard has immense potential for optimizing document-based processes. The easy and safe integration of source and additional information, in their original formats, does not pose a risk for reliable archiving (as was originally thought) but rather introduces a practical extension of the PDF/A archiving format. And this extends far past the case of standard archiving with catchwords like hybrid archiving. PDF/A-3 allows you to avoid media breaks when transferring documents, for example between companies.
Our new cooperation partner, the Forum electronic billing Germany (Forum elektronische Rechnung Deutschland FeRD) quickly recognized these advantages. FeRD is working together with the DIN (German Institute for Standardization) on the standardization of a PDF- and XML-based invoice exchange format called ZUGFeRD (www.ferd-net.de) with the aim of eliminating all capturing and data entry requirements on the receivers side. A visual representation of the invoice is provided in the PDF part of the file, facilitating the quick review and processing in small businesses. In the XML part, all of the data are included in machine-legible format, so that the required information can be directly imported into the financial bookkeeping or banking software. A secure file format is of course necessary, which on one side guarantees the same visual representation every time, while on the other side can capture the XML file and mange it correctly. And this is exactly what PDF/A-3 does! FeRD therefore specified PDF/A-3 as the file format for ZUGFeRD at a very early stage in the project.
The members LuraTech and intarsys represent the PDF Association in the FeRD working group. I can personally report on the high commitment and rapid progress of the standardization project. And the work goes on at the CeBIT you can find FeRD-compatible PDF/A solutions from LuraTech, intarsys and other PDF Association members. There is a high level of interest in FeRD and the project has received the same wide support from the political and business sectors as we are accustomed to with PDF/A.
PDF/A-3 brings a lot of new potential for improving processes. Read the feature article below and get into contact with our experts to learn more about your own possibilities with PDF/A-3 and FeRD. Or meet with us at the upcoming CeBIT.
Enjoy the newsletter!
PDF Association Board Member
Members of the PDF Association at CeBIT 2013:
Easy exchange of invoices with the new ZUGFeRD standard
Overview and where it fits In
There is already an abundance of information available dealing with FeRD, and work on the definition of the XML-content within the ZUGFeRD specification is progressing rapidly. It has also already been determined that PDF/A is the optimal document format and should be used.
Theoretically it is quite simple: the FeRD-compatible XML files are embedded in a PDF/A-3 file when the invoice is created. The recipient of the invoice then extracts the XML data and transfers it into his or her own system for processing the invoice.
During the most recent discussions, many questions were posed to the PDF Association and the experts as to how the implementation should be done correctly and what the integration scenarios could look like. Therefore, this article will address these questions and attempt to structure the previous experiences and approaches.
First and foremost, it must be stated that there is unfortunately no SINGLE solution. The optimal creation and implementation is dependent on the actual systems, processes and workflows in place.
For the invoice creator, e.g. in an ERP system, the following basic guidelines apply, whereby the decisive starting point is always the question: How are PDF files and invoices created in the current system?
If the company is rethinking their future product planning, then a new PDF tool can be introduced which creates technically sound PDF/A files as well as supports PDF/A-3 with embedded FeRD-XML data. Technically these are usually so-called PDF SDKs or else printer drivers. When selecting the PDF tool, you should ensure that both PDF/A-1 as well as PDF/A-3 are supported by the supplier. The products from PDF Association members provide a good starting point. Aspects like the programming language with SDKs (e.g. Java, .NET etc.) and architecture (e.g. 32- or 64-bit processing) must also be taken into consideration.
This case may not be quite as common; however there are currently very few ERP systems that can already create invoices in PDF/A format.
This would mean that your system supplier is providing new releases regularly, since PDF software tools that support the new PDF/A-3 standard are only available in the newest product versions. The respective PDF tools must be checked to verify how the interface is used, and it may be wise to enlist the aid of an expert.
In this case, the existing PDF-creation process is vital as the basis for the ensuing steps. If the system uses for example a PDF printer driver, the scenario could look like this:
Important: A PDF/A-3 file MUST first be a valid PDF/A file before the XML data can be embedded in it.
The conversion of PDF files to PDF/A is not trivial; however, in the case with invoices, you are dealing mostly with PDF files that are technically similar. In the system, i.e. at the source of the data, PDF/A restrictions can be accommodated relatively easily. Another option is to use the post process to correct the technically homogeneous documents.
Then the XML data is exported out of the invoicing system. The XML data is either already prepared in the system to be compatible with FeRD, or a small post-processing tool does an individual mapping of the standard XML output into the ZUGFeRD XML scheme.
In the final step, the post-processing tool combines the XML data with the PDF file to create a PDF/A-3 invoice.
For companies that generate large numbers of invoices, e.g. telecommunications companies, electrical utilities etc., complex output management systems are often used, including the use of AFP format for printing.
In such cases, only an individual solution for creating the PDF/A-3 invoices, discussed with the output system supplier, comes into question. The PDF Association however has several members who are experts in output solutions and are quite willing to provide advice.
These four cases describe the basic guidelines for suppliers of ERP and inventory management systems, who can update their products themselves. End users whose invoice creation systems dont yet support PDF/A-3 can generally apply the third case within a reasonable amount of effort. Every invoicing system typically offers an interface for exporting the invoice information as XML data, so that the further mapping to ZUGFeRD-XML only needs to be realized once. Then there are also server tools that can convert the invoice PDFs to PDF/A as well as support the embedding of the XML data.
On the other side of the process are the invoice recipients who receive the digital PDF/A-3 files and should transfer them into their companys own financial system, e.g. ERP or DMS/ECM.
The XML data can be extracted out of the PDF/A-3 file by means of a (typically even simple) PDF SDK. Here it is also necessary to map the ZUGFeRD XML structure to the XML scheme of the target system.
The validation of the XML scheme during its receipt and transfer into the target system is certainly an open question where more experience needs to be gained. The XML validation can be logically split into two levels, and the first level with the formal validation of the XML data to the scheme is relatively easy. The second level, where the business logic is validated, is a much more complicated process.
To explain the technical details, the PDF Association has created a Guideline PDF/A as Medium for ZUGFeRD, which can be found on the website:
A small list of members who already are offering FeRD-compatible tools can be found here:
Author: Thomas Zellmann
LuraTech delivers production software along with document and data conversion solutions, including the accompanying customization services and exemplary support. With LuraTech as their partner, scanning service providers and other businesses and organizations achieve maximum output from their production facilities. DocYard is a production software solution for scanning service providers, acting as an integration platform to transfer, control and centrally analyze all production stages through configurable workflows. The LuraDocument PDF Compressor Enterprise is a production application for compressing document files, converting them to PDF(/A) and performing optical character recognition (OCR). LuraTech is headquartered in Berlin, with additional offices in Remscheid (GER), Redwood City CA (USA) and Swindon (UK).
PDF/A user day in Seattle
The PDF Association is geared towards developers of PDF solutions; companies that work with PDF in document management systems (DMS) and electronic content management (ECM), interested individuals, and users who want to implement PDF technology in their organizations. Although the Associations original members were predominantly from German-speaking countries, the PDF Association now boasts members from over 20 countries worldwide.
Neue Kantstr. 14
Phone: +49 30 39 40 50-0
Fax: +49 30 39 40 50-99
You are receiving this newsletter because you are registered for the PDF/A News. If you do not want to receive further news, please answer with UNSUBSCRIBE.