It’s always good to see our technology being used in the ‘real world’; it really helps us to understand our customers’ daily challenges so we can develop software to make their lives easier.
With this in mind, we recently visited Baker Labels, a leading UK trade label printer with over 45 years’ experience in the business. Bakers has three HP Indigo WS6900 presses, an HP Indigo 20000 press, a Truepress Jet L350 UV and L350 UV+LM inkjet press, as well as a Nilpeter FB3 flexographic press.
Managing director Justin Bailey reflects on our visit:
Global Graphics Software’s technology is used by many thousands of printing companies around the world. We’re committed to innovation and to continue to innovate it’s important that our software developers understand the challenges faced by those companies in the printing industry. I wanted to take our team to an environment where the code they have written might be used.
I set out to find a printing company that shared our values in innovation and would be happy to show us around their facilities. My research led me to Baker Labels, a leading UK print provider for the label and packaging market, who embraced the idea of welcoming us and showing us round.
The thing that struck me immediately about Bakers, was the pride they had in their business and the culture they had built, which clearly radiated as soon as you walked through the door. It was also a bonus to learn that they use PACKZ® and CLOUDFLOW® from our sister company, HYBRID Software, to automate many of their processes.
Bakers also work very closely with HP Indigo in both their label printing business, and BakPac, their flexible packaging business. This meant that our Harlequin RIP® engineers could see presses working that used the technology they had developed deep inside the HP Indigo digital front end. This gave them a sense of real purpose and pride.
One of the HP Indigo 20000 presses at Baker Labels.Baker’s BakPac digital flexible packaging business prints short to medium runs of stand-up pouches, pillow pouches and printed film for trade customers looking for a high-speed-to-market option for their customers.
Bakers’ domain expertise was clear for our team to see: Jamie Godson did an incredible job of explaining the application of technology and challenges that they face within the industry; Jamie Doogan provided important perspective on commercial considerations; and Simon Chandler shared his perspectives on technical infrastructure necessary to stay competitive in the market.
Feedback from my team was overwhelmingly positive and the energy that they got from the visit will be something that I am confident will continue to resonate within our engineering team, spurring on new ideas to solve challenging technical problems. Bakers’ willingness to engage in such conversations will no doubt help us all to do what we do better and facilitate solutions which may well have a broader market application.
On behalf of the Global Graphics Software and Hybrid Software Group PLC, I would like to express my gratitude to Steve Baker and his team for their incredible hospitality and willingness to collaborate. It’s meeting people at companies like Bakers that makes getting out of bed in the morning exciting, and it’s no surprise to me that they are as successful as they are. Long may it continue.
Managing director, Justin Bailey, left, with the team from Global Graphics Software and Jamie Godson, Jamie Doogan and Simon Chandler from Baker Labels.
About the author
Justin Bailey, Managing Director, Global Graphics Software
Justin Bailey has been managing director at Global Graphics Software since 2018. He has over 25 years’ experience in the document imaging and print markets.
To be the first to receive our blog posts, news updates and product news why not subscribe to our monthly newsletter? Subscribe here
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.
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/.
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.
Twenty years ago it was common to find people RIPping jobs for production print with no color management. Indeed, many print service providers (PSPs), magazine publishers etc actively avoided it as being “too complicated” and “unpredictable”. You might read that as an indictment of their vendors for a lack of investment either in developing good product or in educating their users. Alternatively it might simply show that the printing companies were quite understandably risk-averse because it could be expensive if the client didn’t like the resulting color, especially in an environment like display advertising in a major magazine, or packaging for a major brand.
A decade after that more and more people (on both the buying and the printing sides) grasped the value of color management in print and were using it, but there was still a significant minority that had not managed to make the time to understand it. This is borne out by the uproar when Adobe ‘forced’ people to use color management by changing from using CMYK for the alternate color space for Pantone spots in Creative Cloud to using Lab1, and by the continuing demand for support for PDF/X‑1a, where everything has already been converted to press colorants before the PDF is made.
Now we’re in 2022, and the need for color management is accepted almost universally in print sectors that use an ink set based on CMYK. I phrased it that way because some of the industrial print space (textiles, ceramics, laminate flooring etc) have historically used many inks, but usually job-specific rather than CMYK. Some of those markets will continue to use job-specific ink sets as they transition to digital, while others would find a switch to digital extremely challenging without a concurrent switch to a color managed workflow2.
So, why am I writing this now?
It’s because I still talk to people who tell me that they don’t need to do any color management inside the RIP when processing PDF; they RIP it first and then apply color management.
I’m sorry, that just won’t work reliably and with maximum quality.
There was a time, back in the days when PDF 1.3 was the latest and greatest (which pretty much means last millennium) when a PSP could get away with this approach, because their customers were happy to define all their colors in CMYK and spots. As soon as they used anything else, including Lab or colors tagged with ICC profiles, they’d have to have some fallback to generate CMYK values from that data. It doesn’t need a full color management module (CMM), but they’d need something.
And then along came PDF 1.4, adding transparency. And transparency requires that you can convert colors between color spaces, potentially multiple times. That’s because PDF transparency includes the concept of transparency groups. Each group is one or more graphics that are blended with any graphics that are behind them in the design.
The blending depends on a number of parameters, the most obvious of which are the blend mode (Overlay, Multiply, Hard Light etc), and the blend color space. The result of rendering all graphics that are underneath the transparency group will be transformed from whatever space the RIP holds it in (often the CMYK for the output device) into the blending color space. The result of rendering all the graphics inside the transparency group itself is also transformed into the blending color space. Then the blend mode is applied, to do the actual transparency calculation, and the result is transformed back into whatever color space the RIP needs it to be in for further processing (again, often the CMYK of the output device). The blending color space is quite often sRGB, because that’s the default in a number of popular design applications.
So correct rendering of the transparency will often require color transforms between the color space in which graphics are specified (such as, maybe, an image tagged with an ECI RGB ICC profile), the blend color space (most commonly sRGB) and the output device color space (usually a specific CMYK). That’s just not possible without applying a pretty complete color management process during RIPping. And if you try to take short-cuts you’ll usually get a visually different result, sometimes very different.
Color transformation with transparency requires a full color management capability.
Even so, back in the early 2000s a PSP could avoid the need to upgrade software, process control and operator training by insisting that their customers supplied files in a format such as PDF/X-1a, which prohibited device-independent colors and transparency. But making a PDF/X-1a file from a rich design in a creative application requires a number of compromises affecting graphical elements that were originally specified in device independent colors, or which use transparency. Both risk degrading the quality of the final piece.
These days insisting on PDF/X-1a to avoid the need for color management in the RIP is no longer widely acceptable to customers3. And therefore neither is color managing after the RIPping is complete.
Your check-list is therefore:
Don’t use PDF/X-1a. In fact don’t use PDF/X-3 either. Both are two decades old. PDF/X-3 may allow device-independent colors, but both of them force the creation tool to flatten transparency, discard layers and a bunch of other potentially damaging procedures. It’s over ten years since PDF/X-4 was published, and that’s currently the best balance between capability and getting too far ahead of common usage in print workflows.
If you’re a print service provider, converter, industrial printing manufacturer or digital press vendor, don’t cut corners; use a workflow that applies the color management in or before the RIP4. It shouldn’t be hard; all the leading RIP vendors (and therefore leading press vendors, because they license technology from the RIP vendors) supply suitable systems.
About the author
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
Notes 1 – If a spot color will be emulated using process inks on press, then using a CMYK alternate gives predictable color numbers in those inks, but is less good at producing a predictable color appearance. Using Lab for the alternate color space often leads to unpredictable color numbers on each separation, but a more predictable color appearance on the print. There is a benefit to both models, but when it comes to paying for printing the color appearance usually wins!
2 – if run-lengths on digital are long enough to justify warehousing a variety of inks, and changings inks on inkjet presses, it can be reasonable to stay with job-specific ink sets, especially if it’s difficult or expensive to make usable inks for all of CMY and K. As an example, the best Magenta ink for inkjet printing on ceramics is made with gold. Any move to using digital presses for short-run printing more or less requires a fixed ink set to allow for quick job changes without excessive waste, and that typically means CMYK+.
3 – and I say that as the chair of the committees that developed PDF/X for many years, first in CGATS and then in ISO.
4 – There are situations where applying color management in a color server before the RIP can be useful, especially when multiple presses will be used in parallel. This approach brings its own challenges around handling spot colors in the job that will be emulated on press, but can produce excellent results when used with care.
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, inFull 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, 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
At the recent Fespa show in Berlin, Justin Bailey, managing director at Global Graphics Software, spoke to Morten Reitoft of INKISH TV about the technologies offered for inkjet by Hybrid Software Group and why the SmartDFE™ is a key component if you’re planning to integrate print into your smart factory.
Join us at the Industrial Print Integration conference
It’s my first time at the Industrial Print Integration Conference; I’ve packed my suitcase and my passport is raring to go, glad to be out of the drawer after two years of hibernation. I’m looking forward to meeting new people in the industry and learning about the new developments in technology.
If you’re interested in integrating print into your smart factory, join me for my talk at 12.30pm on Wednesday, 18 May 2022. I’ll be explaining how you integrate inkjet into the Smart Factory with the help of fully automated software that connects to the rest of the production system via Industry 4.0 technologies like OPC UA, the open standard for exchanging information for industrial communication. I’ll also explain how you can build in capability so you can deliver everything from mass production to mass customization at the same cost as current print systems.
And if you want to know more, then come along to our booth A7. We’re going to be showing a demo of our SmartDFE™, which I think is pretty impressive. You can watch a snippet here:
SmartDFE is our smart software that drives an inkjet printing subsystem in a factory setting, including those printers used for ultra-high speeds and 300m per minute production rates! The demo shows what happens when you combine high-tech SCADA systems (Supervisory Control and Data Acquisition) with OPC UA to monitor and control virtual print subsystems via iPads. You can control them both inside and outside of your plant location so management always knows what’s happening without ever having be physically present.
Ian Bolton, Product Manager – SmartDFE™ and Direct™
Ian Bolton is the product manager for SmartDFE™ and Direct™. He works with printer OEMs to break down barriers that might be preventing them from reaching their digital printer’s full potential. A software engineer at heart, Ian has a masters in Advanced Computer Science from the University of Manchester, and over 15 years’ experience developing software for both start-ups and large corporations, such as Arm and Sony Ericsson. He draws on this technical background and his passion for problem-solving to define and drive features and requirements for innovative software solutions for digital print.
Be the first to receive our blog posts, news updates and product news. Why not subscribe to our monthly newsletter? Subscribe here
I finally made time for a very overdue tidy of my filing cabinet yesterday. In between wondering why I still had receipts from travel in 2003, I tripped over a piece of history: it’s a Harlequin Harpoon board, a hardware accelerator for halftone screening and part of the technology that allowed Harlequin to become the first to RIP the Seybold Musicians’ speed test page in under 60 seconds.
A Harlequin Harpoon board, a hardware accelerator for halftone screening.
Speed is still a key focus for Global Graphics Software, but the Harpoon was designed for screening for offset plates, and developments in chips and compilers by Intel, AMD, Microsoft and others, together with further optimizations to Global Graphics Software code, removed the need for custom hardware for that use case fairly soon afterwards.
Today’s challenge is much more for digital presses, and especially for inkjet. Current press speeds make the idea of celebrating RIPping and screening a single page in less than a minute seem quaint and even slightly bizarre; very last millennium! The fastest digital presses now print well over the equivalent of 10,000 pages per minute, often with every page different, which means that at least something on every page must be RIPped and screened, at full engine speed.
For that kind of performance, or even a more common 100 m/min for a narrow-web label press, it’s now normal to use multiple RIPs in parallel and to share the pages out between them. This makes it tricky to use custom hardware unless that is tied to specific ink channel delivery, because otherwise it must be load-balanced in a way that complements the load-balancing across the RIPs. We still see some custom hardware associated with raster delivery to the heads in the press, but nowhere else in current systems.
For the same reason, increasing the raw speed of a single RIP is no longer a target; scheduling pages to each RIP in a cluster and managing the rasters delivered by each one, together with managing the interactions between those multiple RIPs, are far more important. System engineering is now a key part of being able to drive inkjet presses at full speed without an unfeasibly high bill of materials for the Digital Front End, almost as much as the core technologies themselves.
In other words Global Graphics’ Direct™ and SmartDFE™ technologies are the logical successors of the Harpoon board, bringing affordable and reliable speed to a new generation of printing technology. But there’s still something rather nice in being able to hold a physical piece of history in my hands!
About the author
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 blog posts, news updates and product news. Why not subscribe to our monthly newsletter? Subscribe here
Whenever we start working with a company who’s interested in using Harlequin Core™ for their Digital Front End (DFE), there are always three technical topics under discussion: speed, quality and capabilities. Speed and quality are often very quick discussions; much of the time they’ve approached us because they’re already convinced that Harlequin can do what they need. In the remaining cases we tend to jointly agree that the best way for them to be convinced is for them to take a copy of Harlequin Core and to run their own tests. There’s nothing quite like trying something on your own systems to give yourself confidence in the results.
So that leaves capabilities.
If the company already sells a DFE using a different core RIP they will almost always want to at least match, and usually to extend, the functionality of their existing solution when they switch to Harlequin. And if they’re building their first DFE they usually have a clear idea of what their target market will need.
At that stage we start by ensuring that we all understand that Harlequin Core can deliver rasters in whatever format is required (color channels, interleaving, resolution, bit depth, halftoning) and then cover color management pretty quickly (yes, Harlequin uses ICC profiles, including v4 and DeviceLink; yes, you can chain multiple profiles in arbitrary sequences, etc).
Then we usually come on to a series of questions that boil down to handling spot colors:
Most spot separations in jobs will be emulated on my digital press; can I adjust that emulation?
Can I make sure that the emulation works well with ICC profiles for different substrates?
Can I include special device colorants, such as White and Silver inks in that emulation?
Can I alias one spot separation name to another?
Can I make technical separations, like cut and fold lines, completely disappear, without knocking out if somebody upstream didn’t set them to overprint?
Alternatively, can I extract technical separations as vector graphics to drive a cutter/plotter with?
Since the answer to all of those is ‘yes’ we can then move on to areas where the vendor is looking for a unique capability …
But I’ve always been slightly disappointed that we don’t get to talk more about some of the interesting corners of spot handling in Harlequin. So I created a video to walk through some examples. Take a look, and I’d welcome your comments and questions!
Following his post last week about the speed and scalability of your raster image processor, in this film, Martin Bailey, distinguished technologist at Global Graphics Software, explains how to determine how much raster image processor (RIP) power you need to drive a digital press by calculating the press data rate. It’s the best way of calculating how much RIP power you need in the Digital Front End (DFE) to drive it at engine speed and to ensure profitable printing.
If you’re building a digital press, or a digital front end (DFE) to drive a digital press, you want it to be as efficient and cost-effective as possible. As the trend towards printing short runs and personalization grows, especially in combination with increasing resolutions, more colorants and faster presses, the speed and scalability of the raster image processor (RIP) inside that DFE are key factors in determining profitability.
For your digital press to print at speed you’ll need to understand the amount of data that it requires, i.e. its data rate. In this film, Martin Bailey, distinguished technologist at Global Graphics Software, explains how different stages in data handling will need different data rates and how to integrate the appropriate number of RIP cores to generate that much data without inflating the bill of materials and DFE hardware.
Martin also explains that your next press may have a much higher data rate requirement than your current one.
