HP’s largest fastest T410 inkjet web press can consume up to 16 GB per second
Simon Eccles looks at how high speed multi-Rip processing is allowing digital front ends to cope with even the fastest digital presses.
With last month’s announcement of the Jet Press 720S by Fujifilm came the simultaneous announcement of a turbo version of its variable data processing capabilities. In the wider world, this may have rather more significance than the press, because the same technology will also appear from other suppliers for other digital presses.
The new 720S sheetfed B2 inkjet press uses XMF 6.0, the latest version of Fujifilm’s well established workflow front end, which in turn uses APPE3 (the latest Adobe PDF Print Engine) as its rendering technology. Rendering is the term preferred to Ripping nowadays, but it is basically the same thing.
When Adobe announced APPE3 in September 2013, it also announced Mercury technology, which makes Rips go faster. Fujifilm is not the first to adopt APPE3, but it is the first to add the Mercury technology, which basically lets you automatically scale up the processing with as many Rips as it can find, after which it will automatically and intelligently sort out the most efficient way to handle complex variable data jobs. It seems to be particularly relevant to PDF/VT, the variable data flavour of the PDF document format, which has had a slow start but may finally be gathering steam.
Although the new Fujifilm inkjet press is not particularly fast, it is intended for high resolution, high quality work such as photo books, so it needs to handle a lot of data. The new 720S remains simplex like its predecessor, but it is better suited to work-and-turn work because it has a bar code generator that puts a unique code on the first side of every sheet, with a reader that detects this when the stack is turned and run through again. The code is used to access the pre-processed second pages and load these, thus ensuring data integrity. This gets around the original problem of duplex variable data on a simplex press: that if there is a mis-feed then all the subsequent pages are out of order.
Shuffle the pile
‘In fact, you could print one side of a variable data job, shuffle the pile before printing the second side and the 720S will re-order the data on the fly,’ said Mark Stephenson, Fujifilm’s sales manager for digital solutions. ‘The data will always match on both sides of the sheet.’
According to John Davies, Fujifilm’s print production workflow manager: ‘We could process variable data with the original Jet Press 720, but we didn’t really have the data resources then, so that made it a bit risky. With the new XMF 6 all the pages are processed in advance and stored in the press. We can process the job quicker than the press runs, so we download everything beforehand. With a double-sided job the bar code is read and the appropriate second side is loaded and printed.’
He credits the higher speed processing to the Mercury technology. ‘With the old APPE 2.5 we could process variable data, but APPE3 and Mercury make it practical. We have some of the original Jet Press 720 users running variable data already, and they’ll be able to upgrade the front end and some elements of the hardware now. XMF6 will start to go in with the first installations at the end of this year and then it’ll go to the wider user base during 2015.’
He is also keen on PDF/VT, which he said is being implemented by more content creation systems now. ‘With PDF/VT comes a structure that is the document and the variable records. Our XMF recognises this as a VT file and can look at the structure, impose it and organise the processing based on the structure. The speed aspect is where Mercury comes in. APPE3 and Mercury are actually two separate entities. Mercury lets you run multiple Rips and it makes use of all the resources to run them. This is automatic; you don’t need to allocate servers, it’s done for you.’
XMF runs in the Windows operating environment, which already understands multiple processors and servers. ‘Mercury adds a software layer that lets you use all of those resources and take advantage of all the power available,’ Mr Davies explained. ‘If you have a PC and add more processing cores, Mercury will automatically expand to use them. There’s no actual limit on the number of Rips you can use, except for the practicalities of cost.’
Although the multi-Rip capability is of most relevance to the high data loads associated with digital printing, Mr Davies said that it will also be offered to some of the platesetter users who may have high seasonal workloads.
HP’s T410 inkjet web press
Other users to come
In the wider world there are far more powerful high speed digital presses around that also use APPE based front ends, such as Fujifilm’s own Jet Press 540W inkjet web presses, Screen’s Truepress Jet520 range, Ricoh’s related InfoPrint 5000 series, the various Canon/Océ JetStreams, Kodak Prosper presses and so on, some of which can hit speeds of several hundred metres per minute. All of their manufacturers have signed up to implement APPE3 as part of the normal upgrade cycle.
For example, Kodak uses APPE in its Prinergy universal workflows for platesetters and NexPresses, though the fast inkjet Prosper Presses have a separately developed front end for higher data rates. ‘We are running Prinergy 6.1 with APPE 2.6 at the moment and we are testing version 3.0 for an upcoming release of Prinergy,’ said Peter Hulsmans, Kodak’s EMEA regional marketing manager for output devices and workflow systems.
Mercury is a separate entity to APPE and so far commitment is vaguer from the OEMs, and some implementations, such as for wide format printers, will not need it anyway. Screen is due to release an APPE3 upgrade to its Equios workflow right about now, but had not confirmed whether this would use Mercury as Digital Printer went to press. Screen has fast digital inkjet web presses in its range, the Truepress Jet 520 series, so it certainly handles high data flows.
Harlequin’s answer
HP uses Global Graphics Harlequin based workflows for its rival high speed T-series inkjet webs and Indigo presses. These use a core of Global Graphics’ Harlequin technology for their digital front ends. Other press makers tend to be a bit shy about owning up to using Harlequin, but one that is on the record is Delphax, for its fast toner based web printers plus the newish elan sheetfed SRA2 inkjet.
Martin Bailey, chief technology officer at Global Graphics, said that Harlequin has been able to offer saleable multi-Rip, multi-server processing for almost a decade now. The company calls this scalable technology Host Renderer. Mr Bailey admits this is a little confusing as the standard Harlequin system is called MultiRIP, in the sense that one Rip can drive multiple devices, rather than lots of Rips driving one fast printer.
Having multiple Rips is vital to high data flows, he said. ‘It’s very common to use multiple Rips with ultra high volume devices. Take the HP T410: its data rate requirements are very high. In shipping configuration, it’s up to 600 feet per minute, with five colours – CMYK plus MICR – and it is 42 inches wide. It’s running about 5200 pages per minute and the uncompressed data rate is 15 or 16 GB per second. They’ve actually shown it running at 800 feet per minute and 20 GB/sec, but that isn’t shipping yet. You can’t get that volume of data out of one Rip, no matter what you do. It’s pretty tricky getting it out of one server even if you’ve got it running in memory already. You start needing multiple fibre cables per colorant, just to get the data to the heads fast enough.
‘Harlequin Host Renderer is specifically designed for this environment – we provide the same core Rip as the MultiRIP, except Host Renderer doesn’t have the user interface. It’s exactly the same core Rip inside, but the skin is far thinner and supplied to the OEM so they can do pretty well anything they want to integrate it into the rest of the DFE.
‘Making the Rip faster doesn’t typically make the press go any faster. The press will go as fast as it can and the goal of multiple Rips is to let it do that speed for as much of the time as possible. We get there most of the time. What making the individual Rips go faster means is that you can do the same amount of work with a smaller box, so you don’t need as many servers.’
For drupa 2008 on the HP stand, Global Graphics built a spectacular configuration of 168 Rips in a rack (called the Indigo SmartStream Ultra), to process high resolution photo books in more or less real time, certainly faster than any digital press at the time. ‘The drupa stack at 2008 was half a million dollars of hardware,’ Mr Bailey reveals. ‘It was a “show-off”. You don’t want to spend half a million just to drive a press, so the goal is always to make the Rip faster so you don’t need as many of them.’
This new Jet Press 7205 uses an internal bar code reader and some nifty data processing to make sure the second sides match the fronts
More than fast enough
In 2012 the independent research company InfoTrends ran speed tests on Host Renderer v3 technology (which has since been upgraded to v4) and concluded that it could process data faster than any digital press available at the time could run. It concluded that printers ‘can achieve rated engine speed with less processing power, with a concomitant reduction in the costs for hardware, operating systems and other associated software’.
Mercury technology has similar aims, and so last year Adobe commissioned IDC to run speed tests using a broadly similar set-up to InfoTrends for Host Renderer. You can download the white paper from the Adobe website, but the essential conclusion was that Mercury can process a range of realistic test pages faster than any digital press speeds, even using much the same hardware as InfoTrend’s tests from the previous year. Mr Bailey points out that servers have got faster since then, which will benefit both technologies.
Digital presses will undoubtedly get faster and higher resolution as time goes by. The good news is that front ends look certain to keep up with them at costs that do not have to be astronomical.
