We’ve now been shipping the Harlequin Host Renderer™ (HHR) to OEMs and partners for over a decade, driving digital printers and presses. Back then Harlequin was our only substantial software component for use in digital front ends (DFEs), and we just came up with a name that seemed to describe what it did.
Since then our technology set includes a component that can be used upstream of the RIP, for creating, modifying, analyzing, visualizing, etc page description languages like PDF: that’s Mako™. And we’ve also added a high-performance halftone screening engine: ScreenPro™.
We’ve positioned these components as a “Core” range and their names reflect this: “Mako Core” and “ScreenPro Core”. We also added higher level components in our Direct™ range, for printer OEMs who don’t want to dig into the complexities of system engineering, or who want to get to market faster.
Harlequin is already part of Harlequin Direct™, and we’re now amending the name of the SDK to bring it into line with our other “Core” component technologies. The diagram below shows how those various offerings fit together for a wide range of digital printer and press vendors (please click on it for a better view).
So, farewell “Harlequin Host Renderer”, hello “Harlequin Core”.
Vast amounts of data can slow down your digital press resulting in wasted product or delayed delivery times.
In this post, Global Graphics Software’s product manager for Mako, David Stevenson, explores the challenge of printing large amounts of raster data and the options available to ensure that data doesn’t slow down your digital press:
The print market is increasingly moving to digital: digital printing offers many advantages over conventional printing, the most valuable of these is mass-produced, personalized output making every copy of the print different. At the same time digital presses are getting faster, wider, and printing at higher resolutions with extended gamut color becoming common place.
To drive the new class of digital presses, you need vast amounts of raster data every second. Traditional print software designed for non-digital workflows attempts to handle this vast amount of data by RIPping ahead, storing rasters to physical disks. However, the rate at which data is needed for the digital press causes disk-based workflows to rapidly hit the data rate boundary. This is the point where even state-of-the-art storage devices are simply too small and slow for the huge data rates required to keep the press running at full rated speed.
This is leading to a new generation of RIPs that ditch the disk and RIP print jobs on the fly directly to the press electronics. As well as driving much higher data rates, it also has the benefit of no wasted time RIPping ahead.
As you can imagine, RIPping directly to the press electronics presents some engineering challenges. For example, two print jobs may look identical before and after printing, but the way in which they have been made can cause them to RIP at very different rates. Additionally, your RIP of choice can have optimizations that make jobs constructed in certain ways to RIP faster or slower. This variability in print job and RIP time is a bit like playing a game of Russian roulette: if you lose the press will be starved of data causing wasted product or delivery delays.
With a RIP driving your press directly you need to have confidence that all jobs submitted can be printed at full speed. That means you need the performance of each print job and page to be predictable and you need to know what speed the press can be run at for a given combination of print Job, RIP and PC.
Knowing this, you may choose to slow down the press so that your RIP can keep up. Better still, keep the press running at full speed by streamlining the job with knowledge of optimizations that work well with your choice of RIP.
Or you could choose to return the print job to the generator with a report explaining what is causing it to run slowly. Armed with this information, the generator can rebuild the job, optimized for your chosen RIP.
Whatever you choose, you will need predictable print jobs to drive your press at the highest speed to maximize your digital press’s productivity.
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!
Ever wondered what a raster image processor or RIP does? And what does RIPping a file mean? Read on to learn more about the phases of a RIP, the engine at the heart of your Digital Front End (DFE).
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 printhead, toner marking engine or laser platesetter can understand. The process of RIPping a job requires several steps to be performed in order, regardless of the page description language (such as PDF) that it’s submitted in. Even image file formats such as TIFF, JPEG or PNG usually need to be RIPped, to convert them into the correct color space, at the right resolution and with the right halftone screening for the press.
Interpreting: The file to be RIPped is read and decoded into an internal database of graphical elements that must be placed on the output. 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 graphics in formats that support live transparency, such as PDF; it’s not required for PostScript language jobs or for TIFF and JPEG images 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.
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, and the output raster is kept in memory instead of writing it to disk to increase speed.
RIPping 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 can be applied during rendering. Alternatively it can be done after the Harlequin RIP has delivered unscreened raster data; this is valuable if screening is being applied using Global Graphics’ ScreenPro™ and PrintFlat™ technologies, for example.
A DFE for a high-speed press will typically be using multiple RIPs running in parallel to ensure that they can deliver data fast enough. File formats that can hold multiple pages in a single file, such as PDF, are split so that some pages go to each RIP, load-balancing to ensure that all RIPs are kept busy. For very large presses huge single pages or images may also be split into multiple tiles and those tiles sent to different RIPs to maximize throughput.
The raster image processor pipeline. The Harlequin RIP includes native interpretation of PostScript, EPS, DCS, TIFF, JPEG, PNG and BMP 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.
To find out more about the Harlequin RIP, download the latest brochure here.
When developing your first or next digital press, the software you use to drive it will be a key factor in its success, both for the data rates and output quality you can achieve. The time it takes to get your press to market based on the engineering effort involved to deliver and integrate that software is also a consideration.
A simple user interface to get you started
The Press Operator Controller (POC) is an example front end or user interface available with Harlequin Direct™ , the software solution that drives printhead electronics at ultra-high data rates while retaining high output quality. The POC provides you with an initial working system, so you’re up and running without any significant in-house software development. We provide you with the source code so that you have the option to update and integrate it as part of your production system.
I have created a short video to show you its main functions:
Ian has over 15 years’ experience in industry as a software engineer focusing on high performance. With a passion for problem-solving, Ian’s role as product manager for the Direct range gives him the opportunity to work with printer OEMs and break down any new technology barriers that may be preventing them from reaching their digital printer’s full potential.
Be the first to receive our news updates and product news. Why not subscribe to our monthly newsletter? Subscribe here
When planning the implementation of your first or next digital press, the PC specification you choose to run your software workflow will play an important part in the data rates you will be able to achieve. Assuming you are not bottlenecked by disk drive performance due to requiring intermediate disk accesses, you can generally expect data rates to rise with the computational power of your PC.
It might therefore make sense to review the PassMark scores for a range of CPUs within your budget and make your choice based on that, but this alone won’t be enough to tell you whether you’ll be able to drive your printer at full rated speed. Similarly, you may already have an existing PC system in mind but need to know if it will be powerful enough for your new requirements.
Ideally, you could set up an evaluation system to run some typical print jobs to get a definitive answer, but this could be costly and labor-intensive, especially if this is your first digital press.
It’s for this reason we created Direct Benchmark™: an analysis tool that exercises Harlequin Direct™, our ultra-high data rate RIPping and screening solution, with your choice of press configuration and print jobs, stepping through a tuning cycle to obtain a series of data rates and line speeds that can be achieved.
There are two main ways Direct Benchmark can help you: firstly, if you have an existing PC system to run on, you can install Direct Benchmark and gather your own results; secondly, you could base your decision on a database of Direct Benchmark results we are gathering here at Global Graphics Software from running a variety of jobs on a range of PC specifications.
Running Direct Benchmark yourself
Whilst a real Harlequin Direct system would be connected to printhead electronics and driving your press directly, the Harlequin Direct invoked by Direct Benchmark doesn’t require this connection. This makes it very quick and easy to install and start gathering performance numbers. The screenshot below shows the settings you can use to reflect your printer configuration and define the print jobs to benchmark.
During benchmarking, you will be presented with a screen showing statistics for each run and a real-time graph of data rate at the bottom, and then you will be able to export the results at the end. If you would like to see Direct Benchmark in action, you can view a short demo here:
Using the Direct Benchmark database
If you aren’t in a position to run Direct Benchmark yourself, we are in the process of gathering results for a range of press configurations and print jobs, running on a variety of PC hardware specifications. This is being conducted in conjunction with Proactive Technologies, who are providing access to some of the machines we’re using. Whilst it is too early to draw any conclusions or share our results at this stage, if you have some typical print jobs and a press configuration in mind, please get in touch with me, ian.bolton@globalgraphics.com, because we may be able to generate the results for you.
Ian has over 15 years’ experience in industry as a software engineer focusing on high performance. With a passion for problem-solving, Ian’s role as product manager for the Direct range gives him the opportunity to work with printer OEMs and break down any new technology barriers that may be preventing them from reaching their digital printer’s full potential.
Would you fill your brand-new Ferrari with cheap and inferior fuel? It’s a question posed by Martin Bailey in his new guide: ‘Full Speed Ahead – how to make variable data PDF files that won’t slow your digital press’. It’s an analogy he uses to explain the importance of putting well-constructed PDF files through your DFE so that they don’t disrupt the printing process and the DFE runs as efficiently as possible.
Here are Martin’s recommendations to help you avoid making jobs that delay the printing process, so you can be assured that you’ll meet your print deadline reliably and achieve your printing goals effectively:
If you’re printing work that doesn’t make use of variable data on a digital press, you’re probably producing short runs. If you weren’t, you’d be more likely to choose an offset or flexo press instead. But “short runs” very rarely means a single copy.
Let’s assume that you’re printing, for example, 50 copies of a series of booklets, or of an imposed form of labels. In this case the DFE on your digital press only needs to RIP each PDF page once.
To continue the example, let’s assume that you’re printing on a press that can produce 100 pages per minute (or the equivalent area for labels etc.). If all your jobs are 50 copies long, you therefore need to RIP jobs at only two pages per minute (100ppm/50 copies). Once a job is fully RIPped and the copies are running on press you have plenty of time to get the next job prepared before the current one clears the press.
But VDP jobs place additional demands on the processing power available in a DFE because most pages are different to every other page and must therefore each be RIPped separately. If you’re printing at 100 pages per minute the DFE must RIP at 100 pages per minute; fifty times faster than it needed to process for fifty copies of a static job.
Each minor inefficiency in a VDP job will often only add between a few milliseconds and a second or two to the processing of each page, but those times need to be multiplied up by the number of pages in the job. An individual delay of half a second on every page of a 10,000-page job adds up to around an hour and a half for the whole job. For a really big job of a million pages it only takes an extra tenth of a second per page to add 24 hours to the total processing time.
If you’re printing at 120ppm the DFE must process each page in an average of half a second or less to keep up with the press. The fastest continuous feed inkjet presses at the time of writing are capable of printing an area equivalent to over 13,000 pages per minute, which means each page must be processed in just over 4ms. It doesn’t take much of a slow-down to start impacting throughput.
If you’re involved in this kind of calculation you may find the digital press data rate calculator useful: Download the data rate calculator
Global Graphics Software’s digital press data rate calculator.
This extra load has led DFE builders to develop a variety of optimizations. Most of these work by reducing the amount of data that must be RIPped. But even with those optimizations a complex VDP job typically requires significantly more processing power than a ‘static’ job where every copy is the same.
The amount of processing required to prepare a PDF file for print in a DFE can vary hugely without affecting the visual appearance of the printed result, depending on how it is constructed.
Poorly constructed PDF files can therefore impact a print service provider in one or both of two ways:
Output is not achieved at engine speed, reducing return on investment (ROI) because fewer jobs can be produced per shift. In extreme cases when printing on a continuous feed (web-fed) press a failure to deliver rasters for printing fast enough can also lead to media wastage and may confuse in-line or near-line finishing.
In order to compensate for jobs that take longer to process in the DFE, press vendors often provide more hardware to expand the processing capability, increasing the bill of materials, and therefore the capital cost of the DFE.
Once the press is installed and running the production manager will usually calculate and tune their understanding of how many jobs of what type can be printed in a shift. Customer services representatives work to ensure that customer expectations are set appropriately, and the company falls into a regular pattern. Most jobs are quoted on an acceptable turn-round time and delivered on schedule.
Depending on how many presses the print site has, and how they are connected to one or more DFEs this may lead to a press sitting idle, waiting for pages to print. It may also delay other jobs in the queue or mean that they must be moved to a different press. Moving jobs at the last minute may not be easy if the presses available are not identical. Different presses may require different print streams or imposition and there may be limitations on stock availability, etc.
Many jobs have tight deadlines on delivery schedules; they may need to be ready for a specific time, with penalties for late delivery, or the potential for reduced return for the marketing department behind a direct mail campaign. Brand owners may be ordering labels or cartons on a just in time (JIT) plan, and there may be consequences for late delivery ranging from an annoyed customer to penalty clauses being invoked.
Those problems for the print service provider percolate upstream to brand owners and other groups commissioning digital print. Producing an inefficiently constructed PDF file will increase the risk that your job will not be delivered by the expected time.
You shouldn’t take these recommendations as suggesting that the DFE on any press is inadequate. Think of it as the equivalent of a suggestion that you should not fill your brand-new Ferrari with cheap and inferior fuel!
The above is an excerpt from Full Speed Ahead: how to make variable data PDF files that won’t slow your digital press. The guide is designed to help you avoid making jobs that disrupt and delay the printing process, increasing the probability of everyone involved in delivering the printed piece; hitting their deadlines reliably and achieving their goals effectively.
To be the first to receive our blog posts, news updates and product news why not subscribe to our monthly newsletter? Subscribe here
About the author:
Martin Bailey, CTO, Global Graphics Software
Martin Bailey first joined what has now become Global Graphics Software in the early nineties, and has worked in customer support, development and product management for the Harlequin RIP as well as becoming the company’s Chief Technology Officer. During that time he’s also been actively involved in a number of print-related standards activities, including chairing CIP4, CGATS and the ISO PDF/X committee. He’s currently the primary UK expert to the ISO committees maintaining and developing PDF and PDF/VT.
To be the first to receive our blog posts, news updates and product news why not subscribe to our monthly newsletter? Subscribe here
It was an interesting exercise, not because it was difficult, but because we started with a bit of archaeology. Back in February 2003 we published an “Application Data Sheet” of instructions for configuring versions 5.3 and 5.5 of the Harlequin RIP to render PDF/X-1a files. We followed that up with another edition for Harlequin 6 (the Eclipse release), addressing PDF/X-3 as well in 2004, and then for Harlequin 7 (Genesis) in 2005.
After that it seemed that PDF/X was sufficiently well understood and so widely adopted in the marketplace that we didn’t need to continue the series. Added to that, we’d added the ability for Harlequin RIPs to recognize PDF/X files and automatically change the RIP configuration around things like overprinting to, as we phrased it at the time, “Do the Right Thing™”.
So when we started writing up how to configure Harlequin for the GWG Output Suite we simply opened up the 2005 doc and replaced the screen grab of the user interface in Harlequin MultiRIP with a one from Harlequin 12.1. In 14 years we’ve added a few options, and, of course, a Windows 10 dialog looks a bit different to one from Windows XP!
We did have to add a couple of extra bullet points to the instructions, especially around perfecting the color management of spots being emulated in process colorants. Some of our color focus over the last decade has been on outputting to a fixed ink set, whether that’s on a digital press or for flexo or offset. So we made the point by delivering our sample output to be reviewed by the GWG as a CMYK raster file … and yes, all of the spot colors in the test suite showed up correctly in their emulations, it all passed 100%.
But that was it.
We thought about adding an indication of which RIP versions the instructions applied to, but ended up simply pointing out when a configuration item had been changed from a check-box to a three-way drop-down menu. The instructions will give you good output from all Harlequin RIPs shipped by Global Graphics in the last decade, and into the future as well.
I love it when stuff just works, and continues to just work, like this. There’s definitely a benefit to aiming to Do the Right Thing™!
Harlequin RIP® gains Ghent PDF Output Suite 5 compliancy
To be the first to receive our blog posts, news updates and product news why not subscribe to our monthly newsletter? Subscribe here
When we hear the phrase “big data”, we’re meant to think of extremely large data sets that are too complex to process in traditional ways. But, in the context of the next generation of digital presses, you’d be forgiven for thinking it refers to the ultra-high data rates required to drive them.
For example, consider a typical narrow-web label press: 13 inches (330mm) wide, 4 colors, 600x600dpi, running at 230 fpm (70m/min). This requires 0.9 GB/s of raster data to drive it at its rated speed.
Assuming next year’s press adds three more colors (Orange, Green and White) and is upgraded to 1200x1200dpi and expected to run a little faster at 330 fpm (100m/min), the required data rate will jump to 8.6 GB/s: almost a factor of ten increase!
Already this is a data rate far in excess of what the fastest solid-state drives can manage, so what hope is there for a traditional disk-based workflow when moving to 20 inches wide, duplex or 200m/min? Clearly, any part of the workflow involving a disk drive is going to become a bottleneck.
Ditch the disk. Rather than write intermediate raster files to disk between RIPping and screening, or between screening and the printhead electronics, everything takes place in memory.
This was one of the reasons behind the creation of Direct™, the integrated software pipeline we announced at the end of April. Rather than write intermediate raster files to disk between RIPping and screening, or between screening and the printhead electronics, everything takes place in memory.
There’s more to future-proofing your press than eliminating comparatively slow disk accesses, however. You’ll need a system that’s scalable and built from the fastest components, which is why Harlequin Direct™ is composed from a configurable number of Harlequin Host Renderer™ and ScreenPro™ instances working in parallel to make the best of the most powerful desktop PCs available.
When it comes to adding new colors or supporting duplex, the scalability extends to multiple Harlequin Directs across multiple PCs, one per printbar.
An added advantage of this approach is that each printbar need not use the same resolution or drop-count etc. For example, you might wish to use a lower resolution and disable color management for white or varnish. Our Press Operator Controller user interface is supplied to manage your configuration, along with submitting and controlling your print jobs.
The beauty of a software-only solution like Direct is that once you have built it into your workflow, you are free to upgrade your PCs over time for greater performance without any further software integration expense. A Direct-based system will evolve as your needs evolve, making it the ideal choice for future-proofing your next digital press.
To be the first to receive our blog posts, news updates and product news why not subscribe to our monthly newsletter? Subscribe here
Ian Bolton, Product Manager, Direct
About the author:
Ian has over 15 years’ experience in industry as a software engineer focusing on high performance. With a passion for problem-solving, Ian’s role as product manager for the Direct range gives him the opportunity to work with printer OEMs and break down any new technology barriers that may be preventing them from reaching their digital printer’s full potential.
Working with a Mako customer recently, I showed him how to code a utility to extract data from a stack of PDF invoices to populate a spreadsheet. I suppose you could describe it as reverse database publishing. This customer had originally licensed Mako to convert XPS to PDF, and later used it to generate CMYK bitmaps of the pages, i.e. using it as a RIP (raster image processor).
With this additional application of Mako, the customer observed that Mako was “like a Swiss Army knife” as it offered so many tools in one – converting, rendering, extracting, combining and processing, of pages and the components that made them up. And doing it not just for PDF but for XPS, PCL and PostScript® too. His description struck a chord with me as it seemed very appropriate. Mako does indeed offer a wide range of capabilities for processing print job formats. It’s not the fastest or feature-richest of the RIPs from Global Graphics Software – that would be Harlequin®. Or the most sophisticated and performant of screening tools – that would be ScreenPro™. But Mako can do both of those things very competently, and much more besides.
For example, we have used Mako to create a Windows desktop app to edit a PDF in ways relevant to production print workflows, such as changing spot colors or converting them to process colors. All the viewing and editing operations are implemented with Mako API calls. That fact alone emphasizes the wide range of applications to which Mako can be put, and I think, fully justifying that “Swiss Army knife” moniker.
