PDF – Global Graphics Software blog

April 11, 2023July 17, 2023

Actino and Mako boost efficiency of PDF file management for German crane manufacturer

Recently I was talking to one of our Mako™ partners, Actino Software, who are based in Germany. Actino have successfully built many document solutions for their customers with Mako, and a recent example was for a large German crane manufacturer with subsidiaries worldwide. The design, manufacture and maintenance of cranes requires a lot of documentation, and the company estimates they manage around 100,000 documents, mainly in PDF.

There are numerous challenges to managing such a large corpus of documents, and one of those is the quality of those documents. I’m not talking here about the content, but rather the way in which the PDF was produced. Many different authoring and PDF creation tools are in use, some going back decades, resulting in a wide variation in the way PDFs are constructed. This is where Mako comes in.

For this project, Actino Software built centralized services that analyze and optimize the PDFs and prepare them for secure delivery. Mako can do this quickly, processing 400 MB files with many thousands of pages, fast. The analysis function identifies the number of pages, bookmarks, fonts, embedded attachments and other features, including document metadata (title, subject etc). The optimize function removes invalid hyperlinks, changes named destinations into working hyperlinks, and resaves the file to a reduce file size. In this particular case, Mako reduced the file size by more than 50% thanks to image resampling. Mako’s built-in font optimization (eliminating duplicate fonts and merging of font subsets) is another way it can reduce file size.

This work supports two DRM (Digital Rights Management) workflows:

Distribution via a portable storage device such as thumb drive, supported by a plug-in to Adobe Acrobat Reader that talks back to the company website for authentication.
Download from a secure website, for which small file size is a must.

Actino were able to meet the customer requirements with a rapid development schedule, based on their understanding of document workflows and their familiarity with the Mako Core SDK. Their customer chose the Actino solution over an Adobe DRM solution, which was considered too expensive and rigid.

Find out more about Mako.

About the author

To be the first to receive our blog posts, news updates and product news why not subscribe to our monthly newsletter? Subscribe here

Follow us on LinkedIn, Twitter and YouTube

February 2, 2023February 23, 2023

Digital watermarking in print workflows – Part 2 – When to add a digital watermark

In this second post about digital watermarking in the print workflow, author Martin Bailey explains the stages when it’s possible to add a digital watermark.

Digital watermarking is an emerging technology, part of the latest step on the evolution of product identification. Global Graphics Software has partnered with Digimarc, a leader in digital watermarking and a member of our Partner Network, to explore this topic and future developments.

Adding a digital watermark during the design stage

In some workflows the designer may apply digital watermarks to a design by, for instance, using a plugin to an application such as Adobe Illustrator. This is equally appropriate for both steganography and an artwork masking layer, and gives the maximum opportunity for approval of the design with the digital watermark in place, and for any rework to the design that might be requested to realize the greatest benefit from using that watermark.
It will not normally be appropriate for the digital watermark to be added by the designer if each instance of the print requires unique data to be encoded in it; variable data composition is usually performed later in the workflow.

Application of digital watermarking has different advantages and disadvantages at various stages in the design and production workflow.

Adding a digital watermark in composition/prepress

In other workflows adding the digital watermark may be a function of a variable data composition or prepress department. Just as for application by the designer, this is applicable for both steganography and an artwork masking layer. There is a reasonable opportunity for approval of the design with the digital watermark in place. But it would be slower and more expensive to rework the design if that is required at this stage than if the watermark were added by the designer.

If the digital watermark is added in prepress then it can carry both static and variable data. As discussed above, however, variable data is best suited to use of an artwork masking layer rather than steganography, if only because of the amount of data that must be generated and then incorporated into a PDF file when steganography is used for a significant number of unique codes.

But applying even an artwork masking layer in prepress does bulk up the resulting print-ready PDF file with many copies of that layer, each one carrying different data. And it can also slow down processing in the Digital Front End (DFE) for a digital press. An overprinted graphic covering large areas of each piece of output in the PDF file can make it harder for the variable data optimization in a DFE to break the design apart so that it can minimize the total amount of processing required to read, color manage, render and halftone screen the job. (See Global Graphics Software’s guide: Full Speed Ahead: How to make variable data PDF files that won’t slow your digital press.)

Late-binding in the Digital Front End (DFE)

A new development in the application of digital watermarking is to add the marks right at the very last minute before the data is printed. In our SmartDFE™, for example, this can be done in parallel with or after the color management and rendering.

Applying the watermarks in parallel with color management and rendering (in the RIP) allows full access to all color channels for the output, while also removing the need to generate a fully resolved “optimized PDF” or PDF/VT file containing all of the variable data further upstream. In turn, this can reduce the overhead of optimizing variable data processing in the RIP. The final result is increased throughput, both in composition/prepress and in the DFE.

Applying marks after the RIP enables even higher performance through the DFE, with the added benefit of providing a more predictable processing speed because the amount of processing required is more deterministic than is rendering PDF. This might restrict the watermark to be painted in only one color channel, though.

Increasing speed and predictability in the DFE allows the use of lower cost hardware in those DFEs, or assists with printing at full engine speed for a larger proportion of jobs.

Late-binding application of digital watermarks will also always occur in an environment where the characteristics of the press that will be used to print the items are known, including resolution, bitdepth etc.

These benefits make this the optimum choice for highly efficient printing workflows for variable data digital watermarks, driving digital presses at full engine speed. The trade-offs are that it’s a little harder to review and approve proofs of the output, and that use for images with steganography is not usually appropriate.

This is an excerpt from the white paper: Optimizing Digital Watermarking in Print Workflows. To learn more about digital watermarking download your copy:

DOWNLOAD YOUR COPY OF THE WHITE PAPER

About the author

Martin Bailey, CTO, Global Graphics Software

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. 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.

Streamline your PDF files for optimal press performance

Are you confident that all your print jobs can be printed at full press speed? How do you know at what speed the press can be run for a given combination of print job – RIP / RIP – PC etc.

In his presentation at the recent FuturePrint Tech Digital Print for Manufacturing, David Stevenson explains how, using Streamline™ and the help of machine learning, we can analyze a PDF file and intelligently estimate how long it will take for that file to run through the press. But it doesn’t stop there: David explains how we can then optimize the file to ensure it will fly through the press without compromising quality or color integrity.

New guides for best practice in creating print files for variable data printing

Best practice in creating PDF files for Variable Data Printing — 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.

Over the years since we’ve updated and extended the guide. The rework in 2020 was sufficiently significant that we renamed it to “Full Speed Ahead: How to make variable data PDF files that won’t slow your digital press”.

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/.

DOWNLOAD
BEST PRACTICE IN CREATING PDF FILES FOR VARIABLE DATA PRINTING – DESIGNER EDITION

BEST PRACTICE IN CREATING PDF FILES FOR VARIABLE DATA PRINTING – DEVELOPER EDITION

About the author

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.

OpenXPS support in the Mako Core™ SDK

I’m excited to announce that Mako 6.6 will support OpenXPS (OXPS) as both an input and output!

But Mako already has lots of inputs and outputs – so why is this one so exciting?

Mako in Printing

Mako, in my opinion, is the premier SDK of choice when it comes to meeting challenges where performance, reliability and accuracy are required. This is particularly so with many printing use-cases.

These use-cases can include handling multiple page description languages (PDLs) from upstream workflows including PDF, PostScript, XPS, PCL, IJPDS and PPML. The only other PDL that was missing, until now, was OXPS.

The exciting part is that having this final PDL puts Mako in a unique and enviable position, as it now supports all common print PDLs, with a single, simple, consistent and clean interface and document object model (DOM).

Mako benefits

Consolidate multiple SDKs for each required PDL.
Requires less developer downtime to learn multiple libraries and interfaces.
Offers a single point of contact and support for all your common PDLs from a trusted company with years of industry experience.

If you’re interested in hearing more, please get in touch with us and see how we can help with your software challenges.

If you fancy taking a look at some code samples to see what Mako can do, feel free to head over to our developer documentation.

About the author

To be the first to receive our blog posts, news updates and product news why not subscribe to our monthly newsletter? Subscribe here

Follow us on LinkedIn and Twitter and YouTube

July 18, 2022August 1, 2022

Keeping up to date – how the car analogy may no longer be relevant in the printing world

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, in Full 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

Follow us on LinkedIn and Twitter

May 31, 2022July 25, 2022

A nostalgic look back at the ISO PDF/X standard

In this blog post, Martin Bailey recalls his days as the first chair of the ISO PDF/X task force and how the standard has developed over the last 20 years.

Over the last few years there has been quite an outpouring of nostalgia around PDF. That was first for PDF itself, but at the end of 2021 we reached two decades since the first publication of an ISO PDF/X standard.

I’d been involved with PDF/X in its original home of CGATS (the Committee for Graphic Arts Technical Standards, the body accredited by ANSI to develop US national standards for printing) for several years before it moved to ISO. And then I became the first chair of the PDF/X task force in ISO. So I thought I’d add a few words to the pile, and those have now been published on the PDF Association’s web site at https://www.pdfa.org/the-route-to-pdf-x-and-where-we-are-now-a-personal-history/.

I realised while I was writing it that it really was a personal history for me. PDF/X was one of the first standards that I was involved in developing, back when the very idea of software standards was quite novel. Since then, supported and encouraged by Harlequin and Global Graphics Software, I’ve also worked on standards and chaired committees in CIP3, CIP4, Ecma, the Ghent Working Group, ISO and the PDF Association (I apologise if I’ve missed any off that list!).

It would be easy to assume that working on all of those standards meant that I knew a lot about what we were standardising from day one. But the reality is that I’ve learned a huge amount of what I know about print from being involved, and from talking to a lot of people.

Perhaps the most important lesson was that you can’t (or at least shouldn’t) only take into account your own use cases while writing a standard. Most of the time a standard that satisfies only a single company should just be proprietary working practice instead. It’s only valuable as a standard if it enables technologies, products and workflows in many different companies.

That sounds as if it should be obvious, but the second major lesson was something that has been very useful in environments outside of standards as well. An awful lot of people assume that everyone cares a lot about the things that they care about, and that everything else is unimportant. As an example, next time you’re at a trade show (assuming they ever come back in their historical form) take a look and see how many vendors claim to have product for “the whole workflow”. Trust me, for production printing, nobody has product for the whole workflow. Each one just means that they have product for the bits of the workflow that they think are important. The trouble is that you can’t actually print stuff effectively and profitably if all you have is those ‘important’ bits. To write a good standard you have to take off the blinkers and see beyond what your own products and workflows are doing. And in doing that I’ve found that it also teaches you more about what your own ‘important’ parts of the workflow need to do.

Along the way I’ve also met some wonderful people and made some good friends. Our conversations may have a tendency to dip in and out of print geek topics, but sometimes those are best covered over a beer or two!

About the author

Martin Bailey 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.

XAML-icious graphics in Mako Core

Creating discrete graphics in Mako Core™ with XAML

It’s not often that one is inspired by the introduction of a new feature in an SDK, but that has happened with Mako 6.3.0 and support for something rather drily known as Abbreviated Geometry Syntax. The inspiration arises because this way of describing geometry – curved and straight lines that form a shape, sometimes filled, sometimes not, that can be added to a page – derives from Microsoft’s XPS (XML Print Specification). But crucially it also appears in XAML, the language used by Windows to describe user interface (UI) designs.

Why is this significant? Some time ago I wrote a Mako sample that would take a regular PDF page, expand it then adorn it with printers’ marks. You know the sort of thing – tick marks that indicate the trimmed size of the page, or the edge of the bleed, and colour bars or gray scales that enable a printer to see a patch of 100% of an ink color, or the gradation from white to black. It also included small targets printed with all inks to help spot registration problems. The graphic itself was simple, but how to generate it with code? The APIs in Mako were somewhat unwieldy when it came to drawing on the page, so much so that I found it easier to copy content from another document.

Having created many discrete graphics in XAML to be used in a Windows application, such as a button or an indicator of some sort, I thought then it would be great to be able to convert a XAML snippet into Mako DOM objects that I could add to a PDF page. At the time, that was too much work. But with this new feature, it’s very straightforward, particularly in C# as there is great support for parsing XML. I began experimenting.

Draw a sample
The first step was to create a graphic to test with that wouldn’t be too challenging but at the same time cover the principal elements found on a XAML canvas – the <Canvas> element itself then paths, rectangles and text blocks with their attendant properties for fill, stroke, color, font etc. Thus was born Funny Robot that you can see here in a screengrab from Visual Studio (VS). .

Figure 1: My funny robot and the XAML that draws him

I often use VS for creating XAML graphics graphically; as you do so, the XAML is written for you. Plus, you can edit the code and immediately see the result in the preview window. Besides Visual Studio and its sibling Blend for Visual Studio, there’s Microsoft’s Expression Design 4. Unfortunately, Microsoft now consider it defunct, but there are those that think as I do that it is a very useful tool and have made it available for download. You will find it easily with a web search for “Expression Design 4”. This tool can import an Adobe Illustrator graphic which is an incredibly valuable feature, one not found in Visual Studio

Coding the solution
The C# that I wrote for this first loads the XAML code as a .NET XmlDocument, then creates Mako DOM object(s) for each XAML element it finds, which are added to a Mako IDOMGroup. Once parsing is complete, that group of objects can then be added to a page, positioned and scaled as required. For the purposes of the example, I simply add the group to a new blank page and save it as a PDF.

The complete code can be found on the MakoSDK GitHub page, alongside the Funny Robot XAML.

Compliance, compatibility, and why some tools are more forgiving of bad PDFs

We added support for native processing of PDF files to the Harlequin RIP® way back in 1997. When we started working on that support we somewhat naïvely assumed that we should implement the written specification and that all would be well. But it was obvious from the very first tests that we performed that we would need to do something a bit more intelligent because a large proportion of PDF files that had been supplied as suitable for production printing did not actually comply with the specification.

Launching a product that would reject many PDF files that could be accepted by other RIPs would be commercial suicide. The fact that, at the time, those other RIPs needed the PDF to be transformed into PostScript first didn’t change the business case.

Unfortunately a lot of PDF files are still being made that don’t comply with the standard, so over the almost a quarter of a century since first launching PDF support we’ve developed our own rules around what Harlequin should do with non-compliant files, and invested many decades of effort in test and development to accept non-compliant files from major applications.

The first rule that we put in place is that Harlequin is not a validation tool. A Harlequin RIP user will have PDF files to be printed, and Harlequin should render those files as long as we can have a high level of confidence that the pages will be rendered as expected.

In other words, we treat both compliance with the PDF standard and compatibility with major PDF creation tools as equally important … and supporting Harlequin RIP users in running profitable businesses as even more so!

The second rule is that silently rendering something incorrectly can be very bad, increasing costs if a reprint is required and causing a print buyer/brand to lose faith in a print service provider/converter. So Harlequin is written to require a reasonably high level of confidence that it can render the file as expected. If a developer opening up the internals of a PDF file couldn’t be sure how it was intended to be rendered then Harlequin should not be rendering it.

We’d expect most other vendors of PDF readers to apply similar logic in their products, and the evidence we’ve seen supports that expectation. The differences between how each product treats invalid PDF are the result of differences in the primary goal of each product, and therefore to the cost of output that is viewed as incorrect.

Consider a PDF viewer for general office or home use, running on a mobile device or PC. The business case for that viewer implies that the most important thing it has to do is to show as much of the information from a PDF file as possible, preferably without worrying the user with warnings or errors. It’s not usually going to be hugely important or costly if the formatting is slightly wrong. You could think of this as being at the opposite end of the scale from a RIP for production printing. In other words, the required level of confidence in accurately rendering the appearance of the page is much lower for the on-screen viewer.

You may have noticed that my description of a viewer could easily be applied to Adobe Reader or Acrobat Pro. Acrobat is also not written primarily as a validation tool, and it’s definitely not appropriate to assume that a PDF file complies with the standard just because it opens in Acrobat. Remember the Acrobat business case, and imagine what the average office user’s response would be if it would not open a significant proportion of PDF files because it flagged them as invalid!

For further reading about PDF documents and standards:

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 news updates and product news. Why not subscribe to our monthly newsletter? Subscribe here

Follow us on LinkedIn, Twitter, and YouTube

April 13, 2021September 8, 2022

Live coding with Mako Core

Last week, my colleague David Stevenson and I ignored all common sense and ran a live coding demo using Mako™. What could have gone wrong!?

Mako is a software development kit that can be used to add a variety of functions into software products, which is why it’s often referred to as the software engineer’s Swiss Army knife.

During the demo we showed how to use Mako to modernize your print infrastructure in three simple ways:

Firstly, we looked at modernization through library consolidation and showed how you can operate on multiple PDLs including PDF, PCL, PostScript® and XPS, all using a single Mako SDK library. We then looked at adopting automated workflows with Mako and demonstrated how to analyze and redact text automatically in a PDF, using Mako’s layout analysis and text search capabilities. Finally, we showed how you can make the most of print infrastructure-as-a-service by integrating Mako with Microsoft’s Universal Print, including modifying and redirecting print jobs.

Thankfully, nothing did go wrong and if you missed it, don’t worry. We recorded everything and you can watch the recording above on demand.

Also, feel free to watch some of our other past webinars on our YouTube channel to find out more about the Mako SDK.

For more information about Mako, visit globalgraphics.com/mako

Tag: PDF

Actino and Mako boost efficiency of PDF file management for German crane manufacturer

Further reading

About the author

Digital watermarking in print workflows – Part 2 – When to add a digital watermark

Adding a digital watermark during the design stage

Adding a digital watermark in composition/prepress

Late-binding in the Digital Front End (DFE)

About the author

Further reading

Streamline your PDF files for optimal press performance

Further reading:

New guides for best practice in creating print files for variable data printing

About the author

Further reading

OpenXPS support in the Mako Core™ SDK

Further reading:

About the author

Keeping up to date – how the car analogy may no longer be relevant in the printing world

About the author

A nostalgic look back at the ISO PDF/X standard

About the author

XAML-icious graphics in Mako Core

Compliance, compatibility, and why some tools are more forgiving of bad PDFs

For further reading about PDF documents and standards:

About the author

Be the first to receive our news updates and product news. Why not subscribe to our monthly newsletter? Subscribe here

Follow us on LinkedIn, Twitter, and YouTube

Live coding with Mako Core

Further reading

About the author

Follow us on LinkedIn, Twitter, and YouTube