New guides for best practice in creating print files for variable data printing

Best practice in creating PDF files for Variable Data Printing
Two new guides, one for designers and one for developers, to ensure best practice in creating PDF files for variable data printing are available now from the PDF Association.

When talking with digital press vendors it soon becomes apparent that the only thing more important than speed is quality; the only thing more important than quality is cost; and the only thing more important than cost is speed. I think I’d have to ask M C Escher for an illustration of that!

To focus on speed, what a press vendor usually means when talking to Global Graphics Software is “I need the Digital Front End (DFE) for my press to be able to print every job at full engine speed”, which is a subject that  we’re very happy to talk about and to demonstrate solutions for, even as the press engines themselves get faster with every new version.

But the components such as the RIP in a DFE are not the only things that can affect whether a press can be driven at full engine speed. There are plenty of things that a designer or composition engine can do that can vary how fast a PDF file can be RIPped by several orders of magnitude, without affecting the visual appearance of the print.

Obviously we like it when the files are efficiently built, but sometimes it’s not obvious to a designer, or a software developer working on either a design application or composition engine how they might be able to improve the files that they generate. That’s why we created a guide called “Do PDF/VT Right” back in 2014, stuffed full of actionable recommendations for both designers and developers making PDF files for variable data printing.

Over the years since we’ve updated and extended the guide. The rework in 2020 was sufficiently significant that we renamed it to “Full Speed Ahead: How to make variable data PDF files that won’t slow your digital press”.

It’s been very well received, and clearly filled a gap in materials available for the target audience; there have been thousands of downloads and printed copies given away at trade shows.

At the end of 2020 a new PDF/VT standard, PDF/VT-3, was published, and the committee in ISO that had developed it asked the PDF Association to write application notes for it, to assist developers implementing it with more extensive detail than can be included in International Standards. That sounds very formal, but in practice the two committees have many members in common (as an example I was project editor on PDF/VT-3 and I co-chair the PDF Association’s PDF/VT Technical Working Group (TWG)). The hand-over was mainly to enable much more agile and responsive document development and more flexibility around publication.

After some debate the PDF/VT TWG decided that what the industry really needed was a best-practice guide in how to construct efficient PDF files for VDP, whether they’re PDF/VT or ‘just’ “optimized PDF”. Any developer who has worked with PDF/VT-1 should have no trouble in implementing VT-3, but there are still some issues with slow processing of very inefficient PDF files preventing print service providers, converters etc from running their digital presses at full engine speed.

The next step was to agree to do the development of that guide in a new form of committee within the PDF Association, specifically so that people who were not members of the Association could be involved.

At this stage Global Graphics offered the text of Full Speed Ahead as a starting point for the Association guide, an offer that was very quickly accepted. But it was felt that it could be made more accessible if two editions of the guide were produced: one for designers and one for developers, rather than combining the two into a single document. Amongst other things it means that each guide can use the most appropriate terminology for each audience, which always makes reading easier.

We were lucky to have Pat McGrew working with us and she took over as champion for the designer edition, while I led on the developer one.

And so I’m very happy to announce that both the Developer and Designer editions of the PDF Association’s “Best Practice in creating PDF files for Variable Data Printing” have just been published and are available with a lot of other useful resources at https://www.pdfa.org/resources/.

DOWNLOAD
BEST PRACTICE IN CREATING PDF FILES FOR VARIABLE DATA PRINTING – DESIGNER EDITION

BEST PRACTICE IN CREATING PDF FILES FOR VARIABLE DATA PRINTING – DEVELOPER EDITION

About the author

Martin Bailey, CTO, Global Graphics Software

Martin Bailey, former distinguished technologist at Global Graphics Software, is currently the primary UK expert to the ISO committees maintaining and developing PDF and PDF/VT and is the author of Full Speed Ahead: how to make variable data PDF files that won’t slow your digital press, a guide offering advice to anyone with a stake in variable data printing including graphic designers, print buyers, composition developers and users.

Further reading

  1. Full Speed Ahead: How to make variable data PDF files that won’t slow your digital press
  2. Compliance, compatibility, and why some tools are more forgiving of bad PDFs
  3. What the difference between PDF/X-1a and PDF/X-4

To be the first to receive our blog posts, news updates and product news why not subscribe to our monthly newsletter? Subscribe here

Follow us on LinkedIn and Twitter

OpenXPS support in the Mako Core™ SDK

I’m excited to announce that Mako 6.6 will support OpenXPS (OXPS) as both an input and output!

But Mako already has lots of inputs and outputs – so why is this one so exciting?

Mako in Printing

Mako, in my opinion, is the premier SDK of choice when it comes to meeting challenges where performance, reliability and accuracy are required. This is particularly so with many printing use-cases.

These use-cases can include handling multiple page description languages (PDLs) from upstream workflows including PDF, PostScript, XPS, PCL, IJPDS and PPML. The only other PDL that was missing, until now, was OXPS.

The exciting part is that having this final PDL puts Mako in a unique and enviable position, as it now supports all common print PDLs, with a single, simple, consistent and clean interface and document object model (DOM).

Formats supported by Mako.
Formats supported by Mako.

Mako benefits

  • Consolidate multiple SDKs for each required PDL.
  • Requires less developer downtime to learn multiple libraries and interfaces.
  • Offers a single point of contact and support for all your common PDLs from a trusted company with years of industry experience.

If you’re interested in hearing more, please get in touch with us and see how we can help with your software challenges.

If you fancy taking a look at some code samples to see what Mako can do, feel free to head over to our developer documentation.

Further reading:

https://www.globalgraphics.com/products/mako

About the author

Andy Cardy, Principal Engineer at Global Graphics Software
Andy Cardy, Principal Engineer at Global Graphics Software

To be the first to receive our blog posts, news updates and product news why not subscribe to our monthly newsletter? Subscribe here

Follow us on LinkedIn and Twitter and YouTube

Keeping up to date – how the car analogy may no longer be relevant in the printing world

In his latest blog post, Martin Bailey, consultant at Global Graphics Software, takes a look at some of the reasons why his go-to car analogy to help his audience understand the world of print may no longer be as relevant as it once was:

Over the years I’ve used analogies in many of my blog posts, conference presentations and white papers; they’re a very effective way of sharing a high-level understanding of sometimes complex ideas. I’m not a car fanatic, so I’ve not had any specific motivation to compare print technologies to anything around cars, but for some reason it seems that car analogies have consistently just worked, so I’ve used them.

But I realized recently that I’m going to have to rework some of them in response to the growth of electric vehicles replacing internal combustion. I know that growth is very uneven across the world (wow, go Norway!), but it’s clearly the future of motoring for many of us. Much of what I write and report might be summarized as “this is the future and how we’ll get there”, so building on something that will become more and more outdated for many readers and listeners introduces an unwelcome distraction from the analogy. It also makes it less effective because analogies must be based on a common understanding or experience, otherwise they just don’t work.

On the other hand, internal combustion vehicles are not even close to the point yet where all readers and listeners will regard them as dinosaurs of historical interest only. So I can’t sensibly use them as a representation of what we were all doing in the past.

So, I thought I’d look through some of the car-based analogies I’ve used to see which need updating, and which are fine as they are:

I’ve often compared a digital press and its associated digital front end (DFE) to the components of a car:

  • The supplied job file, probably in PDF, is the fuel
  • The steering wheel and dashboard are the DFE control systems and user interface
  • The engine is the RIP (clearly the most important part of the entire system, but then I may be biased!)
  • The gearbox and transmission are the electronics and drivers, like those from our friends at Meteor inkjet
  • The wheels are the inkjet heads, actually putting the rubber/ink on the road/substrate

Well, some of those parts still make sense, but I’m not sure that I can equate submitting a PDF file to charging a battery. Somehow the motors in an electric vehicle never seem to have the prominence that I’d personally give to a RIP. And the motors are often linked direct to the wheels, with less of the gearbox and transmission infrastructure than you’d use for internal combustion. This one needs some serious fixing.

Next up is a statement that we used, for example, in Full Speed Ahead: how to make variable data PDF files that won’t slow your digital press: that making a PDF file constructed for efficiency is like using better fuel in a car. There can be a clear step-up from regular to super for gasoline/petrol, but electricity is electricity, at least once it’s in the car battery.

I guess you could argue that charging points with different power capabilities, from 7kW up to 350kW, will significantly affect how long it will take to recharge the car, and therefore on how far you can get in a day, but it’s not really the same discussion. That’s another analogy that I’m going to have to work on.

And finally, for now, I’ve described companies who build digital presses without thinking about software to process job files and proper user interfaces as being like people thinking they can sell rolling chassis: cars with no bodywork, no seats and not even a cup-holder. You may get a few sales for that in specialist markets, but it’s not exactly a mass market.

Of the three analogies I’ve listed here, I think this is the only one that might survive unscathed, although it probably has less value without being able to equate the other bits of the car to digital press and DFE components.

As I said to start with, I had no reason to pick cars as the base for analogies that I use other than that they seemed to work well. I have a feeling that may not be as true in the future. I guess there did have to be one advantage to big oil!

About the author

Martin Bailey, CTO, Global Graphics Software

Martin Bailey, consultant at Global Graphics Software, is a former CTO of the company and currently the primary UK expert to the ISO committees maintaining and developing PDF and PDF/VT. He is the author of Full Speed Ahead: how to make variable data PDF files that won’t slow your digital press, a guide offering advice to anyone with a stake in variable data printing including graphic designers, print buyers, composition developers and users.

To be the first to receive our blog posts, news updates and product news why not subscribe to our monthly newsletter? Subscribe here

Follow us on LinkedIn and Twitter

A nostalgic look back at the ISO PDF/X standard

In this blog post, Martin Bailey recalls his days as the first chair of the ISO PDF/X task force and how the standard has developed over the last 20 years.

Over the last few years there has been quite an outpouring of nostalgia around PDF. That was first for PDF itself, but at the end of 2021 we reached two decades since the first publication of an ISO PDF/X standard.

I’d been involved with PDF/X in its original home of CGATS (the Committee for Graphic Arts Technical Standards, the body accredited by ANSI to develop US national standards for printing) for several years before it moved to ISO. And then I became the first chair of the PDF/X task force in ISO. So I thought I’d add a few words to the pile, and those have now been published on the PDF Association’s web site at https://www.pdfa.org/the-route-to-pdf-x-and-where-we-are-now-a-personal-history/.

I realised while I was writing it that it really was a personal history for me. PDF/X was one of the first standards that I was involved in developing, back when the very idea of software standards was quite novel. Since then, supported and encouraged by Harlequin and Global Graphics Software, I’ve also worked on standards and chaired committees in CIP3, CIP4, Ecma, the Ghent Working Group, ISO and the PDF Association (I apologise if I’ve missed any off that list!).

It would be easy to assume that working on all of those standards meant that I knew a lot about what we were standardising from day one. But the reality is that I’ve learned a huge amount of what I know about print from being involved, and from talking to a lot of people.

Perhaps the most important lesson was that you can’t (or at least shouldn’t) only take into account your own use cases while writing a standard. Most of the time a standard that satisfies only a single company should just be proprietary working practice instead. It’s only valuable as a standard if it enables technologies, products and workflows in many different companies.

That sounds as if it should be obvious, but the second major lesson was something that has been very useful in environments outside of standards as well. An awful lot of people assume that everyone cares a lot about the things that they care about, and that everything else is unimportant. As an example, next time you’re at a trade show (assuming they ever come back in their historical form) take a look and see how many vendors claim to have product for “the whole workflow”. Trust me, for production printing, nobody has product for the whole workflow. Each one just means that they have product for the bits of the workflow that they think are important. The trouble is that you can’t actually print stuff effectively and profitably if all you have is those ‘important’ bits. To write a good standard you have to take off the blinkers and see beyond what your own products and workflows are doing. And in doing that I’ve found that it also teaches you more about what your own ‘important’ parts of the workflow need to do.

Along the way I’ve also met some wonderful people and made some good friends. Our conversations may have a tendency to dip in and out of print geek topics, but sometimes those are best covered over a beer or two!

About the author

Martin Bailey, CTO, Global Graphics Software

Martin Bailey is currently the primary UK expert to the ISO committees maintaining and developing PDF and PDF/VT and is the author of Full Speed Ahead: how to make variable data PDF files that won’t slow your digital press, a new guide offering advice to anyone with a stake in variable data printing including graphic designers, print buyers, composition developers and users.

Further reading

  1. Compliance, compatibility, and why some tools are more forgiving of bad PDFs
  2. What the difference between PDF/X-1a and PDF/X-4

Be the first to receive our blog posts, news updates and product news. Why not subscribe to our monthly newsletter? Subscribe here

Follow us on LinkedInTwitter and YouTube

XAML-icious graphics in Mako Core

Creating discrete graphics in Mako Core™ with XAML

It’s not often that one is inspired by the introduction of a new feature in an SDK, but that has happened with Mako 6.3.0 and support for something rather drily known as Abbreviated Geometry Syntax. The inspiration arises because this way of describing geometry – curved and straight lines that form a shape, sometimes filled, sometimes not, that can be added to a page – derives from Microsoft’s XPS (XML Print Specification). But crucially it also appears in XAML, the language used by Windows to describe user interface (UI) designs. 

Why is this significant? Some time ago I wrote a Mako sample that would take a regular PDF page, expand it then adorn it with printers’ marks. You know the sort of thing – tick marks that indicate the trimmed size of the page, or the edge of the bleed, and colour bars or gray scales that enable a printer to see a patch of 100% of an ink color, or the gradation from white to black. It also included small targets printed with all inks to help spot registration problems. The graphic itself was simple, but how to generate it with code? The APIs in Mako were somewhat unwieldy when it came to drawing on the page, so much so that I found it easier to copy content from another document. 

Having created many discrete graphics in XAML to be used in a Windows application, such as a button or an indicator of some sort, I thought then it would be great to be able to convert a XAML snippet into Mako DOM objects that I could add to a PDF page. At the time, that was too much work. But with this new feature, it’s very straightforward, particularly in C# as there is great support for parsing XML. I began experimenting. 

Draw a sample 
The first step was to create a graphic to test with that wouldn’t be too challenging but at the same time cover the principal elements found on a XAML canvas – the <Canvas> element itself then paths, rectangles and text blocks with their attendant properties for fill, stroke, color, font etc. Thus was born Funny Robot that you can see here in a screengrab from Visual Studio (VS). . 

Figure 1: My funny robot and the XAML that draws him

I often use VS for creating XAML graphics graphically; as you do so, the XAML is written for you. Plus, you can edit the code and immediately see the result in the preview window. Besides Visual Studio and its sibling Blend for Visual Studio, there’s Microsoft’s Expression Design 4. Unfortunately, Microsoft now consider it defunct, but there are those that think as I do that it is a very useful tool and have made it available for download. You will find it easily with a web search for “Expression Design 4”. This tool can import an Adobe Illustrator graphic which is an incredibly valuable feature, one not found in Visual Studio

Coding the solution 
The C# that I wrote for this first loads the XAML code as a .NET XmlDocument, then creates Mako DOM object(s) for each XAML element it finds, which are added to a Mako IDOMGroup. Once parsing is complete, that group of objects can then be added to a page, positioned and scaled as required. For the purposes of the example, I simply add the group to a new blank page and save it as a PDF. 

The complete code can be found on the MakoSDK GitHub page, alongside the Funny Robot XAML. 

Further reading:

  1. How to retain print quality with vector-based transparency flattening
  2. Carry out complex tasks for your print workflow easily with Mako SDK
  3. Improving PDF accessibility with Structure Tagging

Be the first to receive our blog posts, news updates and product news. Why not subscribe to our monthly newsletter? Subscribe here

Follow us on LinkedInTwitter and YouTube

Compliance, compatibility, and why some tools are more forgiving of bad PDFs

Compliant and compatible PDF documents and the Harlequin RIP

We added support for native processing of PDF files to the Harlequin RIP® way back in 1997. When we started working on that support we somewhat naïvely assumed that we should implement the written specification and that all would be well. But it was obvious from the very first tests that we performed that we would need to do something a bit more intelligent because a large proportion of PDF files that had been supplied as suitable for production printing did not actually comply with the specification.

Launching a product that would reject many PDF files that could be accepted by other RIPs would be commercial suicide. The fact that, at the time, those other RIPs needed the PDF to be transformed into PostScript first didn’t change the business case.

Unfortunately a lot of PDF files are still being made that don’t comply with the standard, so over the almost a quarter of a century since first launching PDF support we’ve developed our own rules around what Harlequin should do with non-compliant files, and invested many decades of effort in test and development to accept non-compliant files from major applications.

The first rule that we put in place is that Harlequin is not a validation tool. A Harlequin RIP user will have PDF files to be printed, and Harlequin should render those files as long as we can have a high level of confidence that the pages will be rendered as expected.

In other words, we treat both compliance with the PDF standard and compatibility with major PDF creation tools as equally important … and supporting Harlequin RIP users in running profitable businesses as even more so!

The second rule is that silently rendering something incorrectly can be very bad, increasing costs if a reprint is required and causing a print buyer/brand to lose faith in a print service provider/converter. So Harlequin is written to require a reasonably high level of confidence that it can render the file as expected. If a developer opening up the internals of a PDF file couldn’t be sure how it was intended to be rendered then Harlequin should not be rendering it.

We’d expect most other vendors of PDF readers to apply similar logic in their products, and the evidence we’ve seen supports that expectation. The differences between how each product treats invalid PDF are the result of differences in the primary goal of each product, and therefore to the cost of output that is viewed as incorrect.

Consider a PDF viewer for general office or home use, running on a mobile device or PC. The business case for that viewer implies that the most important thing it has to do is to show as much of the information from a PDF file as possible, preferably without worrying the user with warnings or errors. It’s not usually going to be hugely important or costly if the formatting is slightly wrong. You could think of this as being at the opposite end of the scale from a RIP for production printing. In other words, the required level of confidence in accurately rendering the appearance of the page is much lower for the on-screen viewer.

You may have noticed that my description of a viewer could easily be applied to Adobe Reader or Acrobat Pro. Acrobat is also not written primarily as a validation tool, and it’s definitely not appropriate to assume that a PDF file complies with the standard just because it opens in Acrobat. Remember the Acrobat business case, and imagine what the average office user’s response would be if it would not open a significant proportion of PDF files because it flagged them as invalid!

For further reading about PDF documents and standards:

  1. Full Speed Ahead: How to make variable data PDF files that won’t slow your digital press
  2. PDF Processing Steps – the next evolution in handling technical marks

About the author

Martin Bailey, CTO, Global Graphics Software

 

 

 

Martin Bailey, Distinguished Technologist, Global Graphics Software, is currently the primary UK expert to the ISO committees maintaining and developing PDF and PDF/VT and is the author of Full Speed Ahead: how to make variable data PDF files that won’t slow your digital press, a new guide offering advice to anyone with  a stake in variable data printing including graphic designers, print buyers, composition developers and users.

Be the first to receive our news updates and product news. Why not subscribe to our monthly newsletter? Subscribe here

Follow us on LinkedInTwitter, and YouTube

Live coding with Mako Core

Last week, my colleague David Stevenson and I ignored all common sense and ran a live coding demo using Mako™. What could have gone wrong!?

Mako is a software development kit that can be used to add a variety of functions into software products, which is why it’s often referred to as the software engineer’s Swiss Army knife.

During the demo we showed how to use Mako to modernize your print infrastructure in three simple ways:

Firstly, we looked at modernization through library consolidation and showed how you can operate on multiple PDLs including PDF, PCL, PostScript® and XPS, all using a single Mako SDK library. We then looked at adopting automated workflows with Mako and demonstrated how to analyze and redact text automatically in a PDF, using Mako’s layout analysis and text search capabilities. Finally, we showed how you can make the most of print infrastructure-as-a-service by integrating Mako with Microsoft’s Universal Print, including modifying and redirecting print jobs.

Thankfully, nothing did go wrong and if you missed it, don’t worry. We recorded everything and you can watch the recording above on demand.

Also, feel free to watch some of our other past webinars on our YouTube channel to find out more about the Mako SDK.

For more information about Mako, visit globalgraphics.com/mako

Further reading

  1. Carry out complex tasks for your print workflow easily with Mako
  2. Improving PDF accessibility with Structure Tagging

About the author

Andy Cardy, Principal Engineer at Global Graphics Software
Andy Cardy, Principal Engineer at Global Graphics Software

To be the first to receive our blog posts, news updates and product news why not subscribe to our monthly newsletter? Subscribe here

Follow us on LinkedInTwitter, and YouTube

The Digimarc interview: Fast, efficient print production with variable data printing

The impact of poorly constructed PDF files on production schedules has increased as press resolution, colorant count, speed, and width rise – greatly increasing the data rate required to drive them.

This increase in data places additional demands on the processing power of the DFE and risks slowing down the digital press: a delay of half a second on every page of a 10,000-page job adds 90 minutes to the whole job, while for a job of a million pages an extra tenth of a second per page adds 24 hours to the total processing time.

In his guide: Full Speed Ahead – How to make variable data PDF files that won’t slow your digital press, Martin Bailey, distinguished technologist at Global Graphics Software, gives some technical recommendations as to how you can make sure that you don’t make a PDF file for a variable data job that will bring a digital press to its knees. It provides objective information for graphic designers, print buyers, production managers, press operators, owners of PSPs, and developers of digital presses and composition tools.

Martin has just released a second edition of the guide and in this film he talks about the updates to Digimarc‘s marketing communications manager, Rob Fay. Digimarc provides additional functionality to Global Graphics’ software platforms and is a sponsor of the guide.

Topics in the interview include:

  • The guide’s purpose and target audiences
  • Background on updates related to the standards PDF/X-6 and PDF/VT-3
  • Differences in the various VDP applications: traceability; trackability; and personalization
  • Recent improvements in DFE (digital front end) technology that are enabling more advanced VDP

Martin Bailey, CTO, Global Graphics Software, and Rob Fay of Digimarc

WATCH THE INTERVIEW HERE

DOWNLOAD THE GUIDE HERE

Further reading:

  1. What’s the best effective photographic image resolution for your variable data print jobs?
  2. Why does optimization of VDP jobs matter?

To be the first to receive our blog posts, news updates and product news why not subscribe to our monthly newsletter? Subscribe here

Follow us on LinkedInTwitter, and YouTube

MPI Tech joins the Global Graphics Software Partner Network

MPI Tech joins the Global Graphics Software Partner Network

Leading provider of document management and document output solutions MPI Tech has joined the Global Graphics Software Partner Network as a technology partner.

MPI Tech will enable Global Graphics Software’s Harlequin Direct™ and Fundamentals™ products to support AFP and IPDS  jobs. AFP (Advanced Function Presentation) is the most widely used format for high-speed transactional printing in many industries including finance, insurance, manufacturing, health care and education. IPDS (Intelligent Printer Data Stream) is the print description language (PDL) to print AFP documents online.

MPI Tech offers a range of solutions to process AFPDS and native AFP/IPDS at speeds over 6,000 ipm or convert them into the most popular PDL (PCL, PDF, PDF/A, PS etc) on almost every platform (Windows, AIX, Linux, Solaris, UNIX).

Justin Bailey, managing director of Global Graphics Software commented: “We’re pleased to welcome MPI Tech to our partner network. With a proven technology and know-how for processing AFP or IPDS print jobs, Global Graphics Software turns to MPI Tech as its ‘go-to partner’ when our customers require solutions for these transactional print data-streams.”

MPI Tech has been a licensee of Global Graphics technology for many years, using it for converting to, and processing, PostScript, PDF, and other PDLs.

If you’re interested in joining the Partner Network visit our website to find out more.

 

Improving PDF accessibility with Structure Tagging

In this week’s post, Global Graphics Software’s principal engineer, Andrew Cardy, explores the structure tagging API in the Mako™ Core SDK. This feature is particularly valuable as it allows developers to create PDFs that can be read by screen readers, such as Jaws®. This helps blind or partially sighted users unlock the content of a PDF.  Here, Andy explains how to use the structure tagging API in Mako to tag both text and images:

What can we Structure Tag?

Before I begin, let’s talk about PDF: PDF is a fixed-format document. This means you can create it once, and it should (aside from font embedding or rendering issues) look identical across machines. This is obviously a great thing for ensuring your document looks great on your user’s devices, but the downside is that some PDF generators can create fixed content that is ordered in a way that is hard for screen readers to understand.

Luckily Mako also has an API for page layout analysis. This API will analyze the structure of the PDF, and using various heuristics and techniques, will group the text on the page together in horizontal runs and vertical columns. It’ll then assign a page reading order.

The structure tagging API makes it easy to take the layout analysis of the page and use it to tag and structure the text. So, while we’re tagging the images, we’ll tag the text too!

Mako’s Structure Tagging API

Mako’s structure tagging API is simple to use. Our architect has done a great job of taking the complicated PDF specification and distilling it down to a number of useful APIs.

Let’s take a look at how we use them to structure a document from start to finish:

Setting the Structure Root

Setting the root structure is straight forward. Firstly, we create an instance of IStructure and set it in the document.

Next we create an instance of a Document level IStructureElement and add that to the structure element we’ve just created.

One thing that I learnt the hard way, is that Acrobat will not allow child structures to be read by a screen reader if their parent has alternative (alt) text set.

Add alternate text only to tags that don’t have child tags. Adding alternate text to a parent tag prevents a screen reader from reading any of that tag’s child tags. (Adobe Acrobat help)

Originally, when I started this research project, I had alt text set at the document level, which caused all sorts of confusion when my text and image alt text wasn’t read!

Using the Layout Analysis API

Now that we’ve structured the document, it’s time to structure the text. Firstly, we want to understand the layout of the page. To do this, we use IPageLayout. We give it a reference to the page we want to analyze, then perform the analysis on it.

Now the page has been analyzed, it’s easy to iterate through the columns and nodes in the page layout data.

Tagging the text

Once we’ve found our text runs, we can tag our text with a span IStructureElement. We append this new structure element to the parent paragraph created while we were iterating over the columns.

We also tag the original source Mako DOM node against the new span element.

Tagging the images

Once the text is structured, we can structure the images too.

Earlier, I used Microsoft’s Vision API to take the images in the document and give us a textual description of them. We can now take this textual description and add it to a figure IStructureElement.

Again, we make sure we tag the new figure structure element against the original source Mako DOM image.

Notifying Readers of the Structure Tags

The last thing we need to do is set some metadata in the document’s assembly, this is straight forward enough. Setting this metadata helps viewers to identify that this document is structure tagged.

Putting it all Together

So, after we’ve automated all of that, we now get a nice structure, which, on the whole, flows well and reads well.

We can see this structure in Acrobat DC:

And if we take a look at one of the images, we can see our figure structure now has some alternative text, generated by Microsoft’s Vision API. The alt text will be read by screen readers.

Figure properties dialogue
Figure properties dialogue

It’s not perfect, but then taking a look at how Adobe handles text selection quite nicely illustrates just how hard it is to get it right. In the image below, I’ve attempted to select the whole of the title text in Acrobat.

Layout analysis is hard to get right!

In comparison, our page layout analysis seems to have gotten these particular text runs spot on. But how does it fair with the Jaws screen reader? Let’s see it in action!

Struture tagging with Mako SDK

So, it does a pretty good job. The images have captions automatically generated, there is a sense of flow and most of the content reads in the correct order. Not bad.

Printing accessible PDFs

You may be aware that the Mako SDK comes with a sample virtual printer driver that can print to PDF. I want to take this one step further and add our accessibility structure tagging tool to the printer driver. This way, we could print from any application, and the output will be accessible PDF!

In the video below I’ve found an interesting blog post that I want to save and read offline. If I were partially sighted, it may be somewhat problematic as the PDF printer in Windows 10 doesn’t provide structure tagging, meaning that the PDF I create may not work so well with my combination of PDF reader and screen reader. However, if I throw in my Mako-based structure and image tagger, we’ll see if it can help!

Structure tagging video

Of course, your mileage will vary and the quality of the tagging will depend on the quality and complexity of the source document. The thing is, structural analysis is a hard problem, made harder sometimes by poorly behaving generators, but that’s another topic in itself. Until all PDF files are created perfectly, we’ll do the best we can!

Want to give it a go?

Please do get in touch if you’re interested in having a play with the technology, or just want to chat about it.

Andy Cardy, Principal Engineer at Global Graphics Software
Andy Cardy, Principal Engineer at Global Graphics Software

Andy Cardy is a Principal Engineer for Global Graphics Software and a Developer Advocate for the Mako SDK.

Find out more about Mako’s features in Andy’s coding demo:

SHARPEN THE SAW – A LIVE CODING DEMO USING MAKO™

Sharpen the Saw: Mako SDK demo

In this session Andy uses coding in C++ and C# to show you three complex tasks that you can easily achieve with Mako:
• PDF rendering – visualizing PDF for screen and print (15 mins)
• Using Mako in Cloud-ready frameworks (15 mins)
• Analyzing and editing with the Mako Document Object Model (15 mins)

To be the first to receive our blog posts, news updates and product news why not subscribe to our monthly newsletter? Subscribe here

 

Follow us on LinkedInTwitter, and YouTube