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.
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.
We’ve recently released Mako™ 5.0, the latest edition of Global Graphics Software’s digital document SDK. Mako 5.0 earns its major version increment with an upgrade to its internal RIP, new features and a reworked API to simplify implementation. Much requested by Mako customers, Mako 5.0 is the first version to preview C# as a coding alternative to C++ and opens the possibility to support other programming languages in future versions.
Mako 5.0 enables PostScript® (including EPS) files to be read directly, extending the PDL (page description language) support in Mako that already includes PDF, XPS, PCL5 and PCL/XL. Mako can read and write all these PDLs, enabling bi-directional conversion between any of these formats.
With the update of Mako’s internal RIP has come new EDS (error diffusion screens) using algorithms such as Floyd-Steinberg and Stucki. All the screening parameters are exposed via this API, and to help define them, a Windows-based desktop tool can be downloaded from the Mako documentation site. Start with settings that match the popular algorithms and preview the monochrome or color result of your settings tweaks. Then use the settings you have chosen via a button that generates the C++ you need to paste into your code.
Mako 5.0 offers several new APIs that extend its reach into the internals of PDF. For example, it’s now possible to edit property values attached to form and image XObjects. Why is this useful? In PDF, developers can put extra key-value pairs into PDF XObject dictionaries. This is often used to store in application-specific data, as well as for things like variable data tags. This development has led to a more generalized approach to examining and modifying hard-to-reach PDF objects. As ever, well-commented sample code is provided to show exactly how the new APIs work and could be applied in your application.
Finally, we took the opportunity with Mako 5.0 to make changes aimed at making the APIs more consistent in their naming, behavior or return types. Developers new to Mako will be unaware of these changes, but existing code written for Mako 4.x may require minor refactoring to work with Mako 5.0. Our support engineers are ready to assist Mako customers with any questions they have.
Ever wondered what a raster image processor or RIP does? And what does RIPing a page mean? Read on to learn more about the phases of a RIP, the engine at the heart of your Digital Front End.
The RIP converts text and image data from many file formats including PDF, TIFF™ or JPEG into a format that a printing device such as an inkjet print head, toner marking engine or laser platesetter can understand. The process of RIPing a page requires several steps to be performed in order, regardless of whether that page is submitted as PostScript, PDF or any other page description language.
Interpreting: the page description language to be RIPed is read and decoded into an internal database of graphical elements that must be placed on the page. Each may be an image, a character of text (including font, size, color etc), a fill or stroke etc. This database is referred to as a display list.
Compositing: The display list is pre-processed to apply any live transparency that may be in the job. This phase is only required for any pages in PDF and XPS jobs that use live transparency; it’s not required for PostScript language pages because those cannot include live transparency.
Rendering: The display list is processed to convert every graphical element into the appropriate pattern of pixels to form the output raster. The term ‘rendering’ is sometimes used specifically for this part of the overall processing, and sometimes to describe the whole of the RIPing process. It’s only used it in the first sense in this document.
Output: the raster produced by the rendering process is sent to the marking engine in the output device, whether it’s exposing a plate, a drum for marking with toner, an inkjet head or any other technology.
Sometimes this step is completely decoupled from the RIP, perhaps because plate images are stored as TIFF files and then sent to a CTP platesetter later, or because a near-line or off-line RIP is used for a digital press. In other environments the output stage is tightly coupled with rendering.
RIPing often includes a number of additional processes; in the Harlequin RIP® for example:
In-RIP imposition is performed during interpretation
Color management (Harlequin ColorPro®) and calibration are applied during interpretation or compositing, depending on configuration and job content
Screening is applied during rendering or after the Harlequin RIP has delivered unscreened raster data if screening is being applied post- RIP, when Global Graphics’ ScreenPro™ and PrintFlat™ technologies are being used, for example.
These are all important processes in many print workflows.
The Harlequin RIP includes native interpretation of PostScript, EPS, DCS, XPS, JPEG, BMP and TIFF as well as PDF, PDF/X and PDF/VT, so whatever workflows your target market uses, it gives accurate and predictable image output time after time.
The above is an excerpt from our latest white paper: Scalability with the Harlequin RIP®.
I’ve been in the ISO PDF committee meeting in Sydney, Australia for a couple of days this week to review the comments submitted to the most recent ballot on PDF 2.0. Over 100 comments were received, including some complex issues around digital signatures, structure tagging (especially lists), optional content, document parts and soft masks. In all cases the committee was able to reach a consensus on what should be done for PDF 2.0.
The plan is now for one more ballot, the responses to which will be reviewed in Q2 next year, with an expectation that final text for PDF 2.0 will be delivered to ISO for publication shortly thereafter.
So we’re still on track for publication next year.
All of which means that it’s past time that a couple of PDF’s unsung heroes were acknowledged. The project leaders for PDF 2.0 have invested very substantial amounts of time and mental energy updating text in response to comments and ballots over the last several years. When somebody like me requests a change it’s the project leaders who help to double-check that every last implication of that change is explored to ensure that we don’t have any inconsistency.
So a big thank you to Duff Johnson of the PDF Association and Peter Wyatt of CISRA (Canon)!
It’s also worth noting that one of the significant improvements in PDF 2.0 that probably won’t get highlighted elsewhere is that the text now is much more consistent. When you’re writing a detailed technical document 1000 pages long it’s inevitable that some disconnections between different sections will creep in. PDF 2.0 illustrates the value of a broad group of people from many countries and many industries reviewing text in the ISO process: we’ve managed to stamp on many of those cases in this new version.
In the middle of 2017 ISO 32000-2 will be published, defining PDF 2.0. It’s eight years since there’s been a revision to the standard. In the second of a series of blog posts Martin Bailey, the primary UK expert to the ISO committee developing PDF 2.0, looks at the changes to rendering PDF transparency for print.
These changes are all driven by what we’ve learned in the last few years about where the previous PDF standards could trip people up in real-world jobs. Inheritance of transparency color spaces
Under certain circumstances a RIP will now automatically apply a color-managed (CIEBased) color space when a device color space (such as DeviceCMYK) is used in a transparent object. It will do that by inheriting it from a containing Form XObject or the current page.
That sounds very technical, but the bottom line is that it will now be much easier to get the correct color when imposing multiple PDF files from different sources together. That’s especially the case when you’re imposing PDF/X files that use different profiles in their output intents, even though they may all be intended for the same target printing condition. The obvious examples of this kind of use case is placing display advertising for publications, or gang-printing.
We’ve tried hard to minimize impact on existing workflows in making these improvements, but there will inevitably be some cases where a PDF 2.0 workflow will produce different results from at least some existing solutions, and this is one case where that could happen. But we believe that the kinds of construct where PDF 2.0 will produce different output are very uncommon in PDF files apart from in the cases where it will provide a benefit by allowing a much closer color match to the designer/advertiser’s goal than could be achieved easily before. Clarifications on when object colors must be transformed to the blend color space
The ISO PDF 1.7 standard, and all previous PDF specifications were somewhat vague about exactly when the color space of a graphical object involved with PDF transparency needed to be transformed into the blending color space. The uncertainty meant that implementations from different vendors could (and sometimes did) produce very different results.
Those statements have been greatly clarified in PDF 2.0.
This is another area where an upgrade to a PDF 2.0 workflow may mean that your jobs render slightly differently … but the up-side is that if you run pre-press systems or digital presses from multiple vendors they should now all be more similar to each other.
As a note to Harlequin RIP users, the new rules are in line with the way that Harlequin has always behaved; in other words, you won’t see any changes in this area when you upgrade. ColorDodge & Burn
It tends to be taken for granted that the older PDF specifications must match what Adobe® Acrobat® does, but that’s not always correct. As an example, the formulae for the ColorDodge and ColorBurn transparency blending modes in the PDF specification have never matched the implementation in Acrobat. In pursuit of compatibility Harlequin was changed to match Acrobat rather than the specification many years ago. In PDF 2.0 the standard is finally catching up with reality and now both Acrobat and Harlequin will be formally ‘correct’! The background
The last few years have been pretty stable for PDF; PDF 1.7 was published in 2006, and the first ISO PDF standard (ISO 32000-1), published in 2008, was very similar to PDF 1.7. In the same way, PDF/X 4 and PDF/X 5, the most recent PDF/X standards, were both published in 2010, six years ago.
In the middle of 2017 ISO 32000-2 will be published, defining PDF 2.0. Much of the new work in this version is related to tagging for content re-use and accessibility, but there are also several areas that affect print production. Among them are some changes to the rendering of PDF transparency, ways to include additional data about spot colors and about how color management should be applied.
Sign up to the Global Graphics newsletter here for regular updates.
Just when you’ve all cozied down with PDF 1.7 what happens? Yes, that’s right. A new standard rears its head.
Around the middle of 2017 the ISO committee will publish PDF 2.0 (ISO 32000-2). So by the end of 2017 you’ll probably need to be considering how to ensure that your workflow can handle PDF 2.0 files correctly.
As the primary UK expert to this committee I thought I’d give you a heads up now on what to expect. And over the coming months via this blog and our newsletter I’ll endeavor to keep you posted on what to look out for as far as print is concerned. Because, of course, there are many aspects to the standard that do not concern print at all. For instance there are lots of changes in areas such as structure tagging for accessibility and digital signatures that might be important for business and consumer applications.
As you probably already know, in 2008 Adobe handed over ownership and development of the PDF standard to the International Standards Organization. Since that time I’ve been working alongside other experts to ensure that standards have real-world applicability.
And here’s one example relating to color.
The printing condition for which a job was created can be encapsulated in professional print production jobs by specifying an “output intent” in the PDF file. The output intent structure was invented for the PDF/X standards, at first in support of pre-flight, and later to enable color management at the print site to match that used in proofing at the design stage.
But the PDF/X standards only allow a single output intent to be specified for all pages in a job.
PDF 2.0 allows separate output intents to be included for every page individually. The goal is to support jobs where different media are used for various pages, e.g. for the first sheet for each recipient of a transactional print job, or for the cover of a saddle-stitched book. The output intents in PDF 2.0 are an extension of those described in PDF/X, and the support for multiple output intents will probably be adopted back into PDF/X-6 and into the next PDF/VT standard.
But of course, like many improvements, this one does demand a little bit of care. A PDF 1.7 or existing PDF/X reader will ignore the new page level output intents and could therefore produce the wrong colors for a job that contains them.
In my next post I’ll be covering changes around live transparency in PDF 2.0. Bet you can’t wait!
You can sign up to the Global Graphics newsletter here.
The background
The last few years have been pretty stable for PDF; PDF 1.7 was published in 2006, and the first ISO PDF standard (ISO 32000-1), published in 2010, was very similar to PDF 1.7. In the same way, PDF/X 4 and PDF/X 5, the most recent PDF/X standards, were both published in 2010, six years ago.
In the middle of 2017 ISO 32000-2 will be published, defining PDF 2.0. Much of the new work in this version is related to tagging for content re-use and accessibility, but there are also several areas that affect print production. Among them are some changes to the rendering of PDF transparency, ways to include additional data about spot colors and about how color management should be applied.
Standards for variable data printing (VDP) have come a long way since the first work by CGATS to develop a universal delivery format in the late 1990s. In 2010 the International Standards Organization published the PDF/VT standard, marking the first really effective specification for a reliable, vendor-neutral exchange of variable data jobs, both within and between companies.
A special type of the PDF file format, PDF/VT is specifically used for variable data and transactional printing in a variety of environments, from desktop printing to high volume digital production presses. Built on PDF/X, it therefore brings all the advantages of that standard in enforcing best practices for reproducible and predictable color and appearance to the variable data and transactional print worlds.
The industry is gradually realizing its value to improve quality, competitiveness and productivity, and I’ve been working with the PDF/VT Competence Center, especially with Christoph Oeters (Sofha), Paul Jones (Teclyn bv) and Tim Donahue (technical consultant) to produce a new set of Application Notes highlighting the benefits of using PDF/VT and the workflows that it enables.
The Application Notes explain how to make the highest quality and most efficient PDF/VT files to achieve the required visual appearance of a job, so if you develop software to read and write PDF/VT files, for example in composition tools, RIPs, digital front ends and imposition tools, or if you work on print workflow integration, you’ll find the notes really beneficial. They also show how document part metadata can be applied and leveraged for VDP specific production workflows.
Of course, there are wider benefits to using PDF/VT: The adoption of PDF/VT will allow the industry to finally move towards a reliable, vendor-neutral exchange of variable data jobs, simplifying the process of variable data printing significantly.
Read the press release from the PDF Association (http://www.pdfa.org/2016/01/pdf-association-publishes-pdfvt-application-notes-showcasing-the-benefits-for-variable-data-print-streams/)
