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.
With fewer design limitations, a faster turnaround, no minimum run length and higher margins (not to mention reduced use of power and water, and of pollution), it’s not surprising that the digitally printed textile market is growing.1 Inkjet has certainly made textile design and printing much more flexible than screen printing – and that goes for everybody involved, from the designer through the printing company, to the buyer.
But printing textiles on inkjet doesn’t come without its challenges: as a software provider focusing on print quality issues, we often hear from print service providers who can only digitally print two thirds of the jobs they receive because they would not be paid for the quality they could achieve on the others.
Shade or color variation is a common problem. It’s not new in digital printing (it’s always been an issue for screen-printed and dyed textiles as well) and is usually managed by providing a shade band, which printer operators refer to, to check allowable color variations between pieces.
But, unlike screen-printing or dyeing, the color variation on an inkjet press can be visible over a small distance, just a few centimeters, and this results in visible bands across the output. Banding describes features that tend to be 1 – 10 cm across and they’re often caused by variation of inkjet pressure or voltage differences within the head, which typically results in a frown or smile shape. We also see a certain amount of manufacturing variation between heads so that one may print lighter or darker than the head next to it in a print bar. Some types of heads can also wear in use, which can result in less regular banding that can change over time. This means that large areas which should be flat color may not be.
When such a variation occurs it can greatly complicate a lot of post-print steps, especially if you need to put more than one piece of textile together, either in sewing or use (such as a pair of curtains). If that’s the case, then a significant difference may be unacceptable and your printing rejected by your buyer. Ultimately this leads to print service providers rejecting jobs, because they know their digital press can’t handle printing those tricky flat tints or smooth tones.
What can you do about it? The first thing many companies do to try to overcome this banding is to adjust the voltage to the inkjet head, but this is often time-consuming and expensive because it requires an expert technician. A better alternative is to make the correction in software, which is a more cost-effective and faster solution. It means it can be automated and can act at a much finer granularity, so printing is more accurate. There’s no need to mess with controls that could damage the press, and printing companies themselves can make corrections without the vendor sending a technician on-site.
Our solution at Global Graphics Software for improving banding is PrintFlat™. It corrects tonality to hide banding based on measurements from the press. It adjusts every nozzle separately and doesn’t need a specialist engineer to make press adjustments. PrintFlat can be integrated into different digital front ends, using a variety of RIPs, including Caldera and Colorgate and, not to mention, our own Harlequin RIP®.
Over the years of working with many press manufacturers we’ve discovered that many technical issues and solutions are common across different sectors, including transactional, wide-format, commercial, labels and packaging, and industrial, including ceramics, wall coverings, flooring and of course textiles. That means that we already have years of experience in correcting for banding. Using PrintFlat in your press means print service providers can now take on those jobs they would normally reject.
To learn more about how to eliminate shade and color variation when printing on an inkjet press, listen to Global Graphics Software’s CTO Martin Bailey’s talk for FESPA 2020:
Digitally printed textiles are estimated to be between 2% – 5% of the total printed textiles market. Estimated at $146.5 billion in 2018 by Grand View Research
There are two completely different forms of variable data handling in the Harlequin RIP®, and I’m sometimes asked why we’ve duplicated functionality like that. The simple answer is that it’s not duplication; they each address very different use cases.
But those use cases are not, as many people then expect, “white paper workflows” vs imprinting, i.e. whether the whole design including both re-used and single-use elements is printed together vs adding variable data on top of a pre-printed substrate. Both Harlequin VariData™ and the “Dynamic overlays” that we added in Harlequin version 12 can address both of those requirements.
Incidentally, I put “white paper workflows” in quotes because that’s what it’s called in the transactional and direct mail spaces … but very similar approaches are used for variable data printing in other sectors, which may not be printing on anything even vaguely resembling paper!
The two use cases revolve around who has the data, when they have it, whether a job should start printing before all the data is available, and whether there are any requirements to restrict access to the data.
When most people in the transactional, direct mail or graphic arts print sectors think about variable data it tends to be in the form of a fully resolved document representing all of the many variations of one of a collection of pages, combining one or more static ‘backgrounds’ with single-use variable data elements, and maybe some re-used elements from which one is selected for each recipient. In other words, each page in the PDF file is meant to be printed as-is, and will be suitable for a single copy. That whole, fully resolved file is then sent to the press. It may be sent from one division of the printing company to the press room, or even from some other company entirely. The same approach is used for some VDP jobs in labels, folding carton, corrugated, signage and some industrial sectors.
This is the model for which optimized PostScript, and then optimized PDF, PDF/VT (and AFP) were designed. It’s a robust workflow that allows for significant amounts of proofing and process control at multiple stages. And it also allows very rich graphical variability. It’s the workflow for which Harlequin VariData was designed, to maximize the throughput of variable data files through the Digital Front End (DFE) and onto the press.
But in some cases the variable data is not available when the job starts printing. Indeed, the print ‘job’ may run for months in situations such as packaging lines or ID card printing. That can be managed by simply sending a whole series of optimized PDF files, each one representing a few thousand or a couple of million instances of the job to be printed. But in some cases that’s simply not convenient or efficient enough.
In other workflows the data to be printed must be selected based on the item to be printed on, and that’s only known at the very last minute … or second … before the item is printed. A rather extreme example of this is in printing ID cards. In some workflows a chip or magnetic strip is programmed first. When the card is to be printed it’s obviously important that the printed information matches the data on the chip or magnetic strip, so the printing unit reads the data from one of those, uses that to select the data to be printed, and prints it … sometimes all in less than a second. In this case you could use a fully resolved optimized PDF file and select the appropriate page from it based on identifying the next product to be printed on; I know there are companies doing exactly that. But it gets cumbersome when the selection time is very short and the number of items to be printed is very large. And you also need to have all of the data available up-front, so a more dynamic solution is better.
Printing magnetic strip on ID cards.
In other cases there is a need to ensure that the data to be printed is held completely securely, which usually leads to a demand that there is never a complete set of that data in a standard file format outside of the DFE for the printer itself. ID cards are an example of this use case as well.
Moving away from very quick or secure responses, we’ve been observing an interesting trend in the labels and packaging market as digital presses are used more widely. Printing the graphics of the design itself and adding the kind of data that’s historically been applied using coding and marking are converging. Information like serial numbers, batch numbers, competition QR Codes, even sell & use by dates are being printed at the same time as the main graphics. Add in the growing demands for traceability, for less of a need for warehousing and for more print on demand of a larger number of different versions, and there can be some real benefits in moving all of the print process quite close to the bottling/filling/labelling lines. But it doesn’t make sense to make a million page PDF file just so you can change the batch number every 42 cartons because that’s what fits on a pallet.
These use cases are why we added Dynamic overlays to Harlequin. Locations on the output where marks should be added are specified, along with the type of mark (text, barcodes and images are the most commonly used). For most marks a data source must be specified; by default we support reading from CSV files or automated counters, but an interface to a database can easily be added for specific integrations. And, of course, formatting information such as font, color, barcode symbology etc must be provided.
The ‘overlay’ in “Dynamic overlays” gives away one of the limitations of this approach, in that the variable data added using it must be on top of all the static data. But we normally recommend that you do that for fully resolved VDP submissions using something like optimized PDF anyway because it makes processing much more efficient; there aren’t that many situations where the desired visual appearance requires variable graphics behind static ones. It’s also much less of a constraint that you’d have with imprinting, where you can only knock objects like white text out of a colored fill in the static background if you are using a white ink!
For what it’s worth, Dynamic overlays also work well for imprinting or for cases where you need to print graphics of middling complexity at high quality but where there are no static graphics at all (existing coding & marking systems can handle simple graphics at low to medium quality very well). In other words, there’s no need to have a background to print the variable data as a foreground over.
So now you know why we’ve doubled up on variable data functionality!
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/)
