HP Site Flow is a workflow and production automation system for HP digital press owners.
When HP Inc began developing HP Site Flow, an end-to-end workflow and production automation system for HP digital press owners, they encountered several challenges including: addressing the growing personalized market; the need to ‘normalize’ PDFs, given the wide variation in the quality of files entering the system; and the ability to quickly scale up or down to accommodate varying levels of demand.
Read the case study to see how Mako Core™ SDK proved its capability and adaptability by rising to HP Site Flow’s development challenges, resulting in increased productivity and profitability for its users.
Are you confident that all your print jobs can be printed at full press speed? How do you know at what speed the press can be run for a given combination of print job – RIP / RIP – PC etc.
In his presentation at the recent FuturePrint Tech Digital Print for Manufacturing, David Stevenson explains how, using Streamline™ and the help of machine learning, we can analyze a PDF file and intelligently estimate how long it will take for that file to run through the press. But it doesn’t stop there: David explains how we can then optimize the file to ensure it will fly through the press without compromising quality or color integrity.
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.
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.
This month WhatTheyThink’s third Technology Outlook takes place. It’s a series of webinars and interviews that highlight new innovations from industry analysts and thought leaders.
As part of the Thought Leadership Video series, David Zwang of WhatTheyThink chatted to Mako™ product manager David Stevenson, about how, by using our vast experience in RIPs and rendering, we’ve created a high-performance framework for print inspection systems.
David introduces Smart QI™, a quality inspection system available with SmartDFE™. Designed especially for print, SmartQI is a camera-based, real-time quality inspection system, offering the same real-time streaming of rasters. It is especially useful as the use of variable data increases, and press speeds and resolutions continue to grow, making it essential to inspect the print for defects before it comes off the press and goes into finishing and converting.
Project manager Jason Hook shows how we’ve implemented OPC UA into our solutions in this film: How to transform your inkjet business with Industry 4.0 and OPC UA. Jason demonstrates how we track performance metrics like pressure levels across an entire production line using our PC and Ink Delivery System, all while uploading it securely onto cloud servers using AWS IoT SiteWise and Azure IoT.
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.
This week, Mako™ product manager David Stevenson explains vector flattening:
When you print PDF content or save or export it to other formats that do not support transparency, it will need to undergo a process called flattening. Flattening usually involves rasterizing areas of the page that are subject to transparency effects, which could mean replacing sharp-edged vector content with a jagged-edged bitmap. Of course, increasing the resolution of the rasterization can mitigate that problem, but doing so takes longer and adds to file size.
The alternative is to retain vector geometry, including text, as vector objects. This requires dividing the artwork down into smaller parts that no longer overlap, then tracing the edges of the new shapes with a vector path. In the latest release, Global Graphics Software’s Mako Core SDK (v6.2.0) adds this capability to its raster-based transparency flattening API. Using existing APIs that apply De Casteljau’s algorithm to decompose Bézier curves and a new method to trace around shapes, flattened content can retain its device independence and printing quality.
In this example, two partially transparent shapes overlap, and set to use a multiply blend.
The rectangle indicates the zoom area for the next two images.
The result of regular raster-based flattening. The shapes are rasterized (at somewhat low resolution for the purposes of illustration) and you can see the jagged edges that result.The result of vector-based flattening. The edges are smooth.
This image shows how the vector flattener has created three new vector paths that no longer overlap (moved apart for the purposes of illustration), with the color of 2 representing the blend evident in the original artwork.
I’ve included a short demo of the vector-based transparency flattening feature using Mako here:
Over the past year, Microsoft has been working hard to bring its new Cloud printing service, Universal Print, to general availability.
As a part of Universal Print, developers get access to a set of Graph APIs that allows analysis and modification of print job payload data. This feature enables a few different scenarios, including adding security (e.g. redactions or watermarks) to a Universal Print-based workflow.
As a curious engineer, I wanted to see how different it would be for an independent software vendor (ISV) to use our Mako™ Core SDK to modify a print job flowing through Universal Print, instead of using a more traditional route of using a virtual printer driver.
Thinking about the workflow a little more, I came up with the following design:
Using the Mako SDK to modify documents in Universal Print.
In the design above, we can see the end-user’s Word document gets printed to a virtual printer. This allows the ISV to be notified of the job, and modify it accordingly using Mako. Once modified, the ISV then redirects the job on to the physical printer for printing.
There’s a couple of nice things about this design:
Firstly, it uses the Graph API to access Universal Print, which is an easy-to-use and well documented REST API. Secondly, since the functionality is accessed via a REST API, it allows our ISV service to be written in whichever Mako supported language we like.
I chose C# to make best use of the C# Graph API SDK.
Developing the service
There are five main steps to developing the service:
Handle print job notifications
Download the print job payload
Modify the payload
Upload the payload
Redirect to the target printer
Handle print job notifications
To be notified of print jobs in Universal print, you can use the Graph’s change notifications. These will allow you to sign up to a notification, which will call a provided webhook.
Download the print job payload
Once we have notification that a print job has been sent to our virtual printer, we can start downloading its payload.
Here we use the appropriate Graph APIs, along with standard Graph authentication to access the print job’s document. We then simply save it to disk.
Modify the payload
Once we have the document on disk (although Mako can also modify streams too!), we can open the document and modify it using Mako’s document object model (DOM).
Alternatively, Mako can also convert from one page description language (PDL) to another. This is useful in situations where your destination printer doesn’t support the input PDL.
Upload the payload
Uploading the modified document is straightforward. This time we use the Graph API to create an upload session, and use the WebClient class to put the document back into the original print job.
Redirect to the target printer
And finally, after the print job has been updated, we can redirect it onto another printer. This redirection also automatically completes the print job and task.
Alternatively, if we want to be a little more green, we could always send the document to OneDrive, Sharepoint, or another document management system. After doing so, you then complete the print job and its associated task.
See it in action
We actually coded this demo live in our last Mako webinar, showing an implementation where an ISV wants to automatically redact content.
Access the code directly at our GitHub repository or watch the webinar recording below:
Try it out
We’re keen to talk to you about your Universal Print project and see how we can help. Contact us here.
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.
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
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!
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!
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 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:
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
Somebody asked me recently what the difference is between PDF/X-1a (first published in 2001) and PDF/X-4 (published in 2010). I thought this might also be interesting to a wider audience.
Both are ISO standards that deliberately restrict some aspects of what you can put into a PDF file in order to make them more reliable for delivery of jobs for professional print. But the two standards address different needs/desires:
PDF/X-1a content must all have been transformed into CMYK (optionally plus spots) already, so it puts all of the responsibility for correct separation and transparency handling onto the creation side. When it hits Harlequin, all the RIP can do is to lock in the correct overprint settings and (optionally) pre-flight the intended print output condition, as encapsulated in the output intent.
On the other hand, PDF/X-4 supports quite a few things that PDF/X-1a does not, including:
Device-independent color spaces
Live PDF transparency
Optional content (layers)
That moves a lot more of the responsibility downstream into the RIP, because it can carry unseparated colors and transparency.
Back when the earlier PDF/X standards were designed transparency handling was a bit inconsistent between RIPs, and color management was an inaccessible black art to many print service providers, which is why PDF/X-1a was popular with many printers. That’s not been the case for a decade now, so PDF/X-4 will work just fine.
In other words, the choice is more down to where the participants in the exchange want the responsibility to sit than to anything technical any more.
In addition, PDF/X-4 is much more easily transitioned between different presses, and even between completely different print technologies, such as moving a job from offset or flexo to a digital press. And it can also be used much more easily for digital delivery alongside using it for print. For many people that’s enough to push the balance firmly in favour of PDF/X-4.
For further reading about PDF documents and standards:
Martin Bailey is Global Graphics’ Chief Technology Officer. He’s 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
