Posts tagged "proofing process"

Considerations for using Secure Content with DPS

In Release 30 of the Digital Publishing Suite, Adobe introduced a feature for Enterprise customers that lets a publisher encrypt folios. This feature arose out of many requests from Corporate customers who wanted to use DPS for sensitive content but believed that the DPS Service did not offer robust content protection for folios in the Distribution Service or in flight between the Service and a Custom Viewer. While Device Content Protection is an effective method of protecting content on the device, it does not offer protection for content in the DPS Service. In Release 30, a publisher can now opt to publish encrypted folios to the Distribution Service, which satisfies many customers’ requirements for using DPS to deliver sensitive content to their tablet-enabled workforces. Enabling encryption impacts the content creation, publishing, and reading experiences, however. This article will explore the changes to each of those experiences.

Enabling Secure Content

The DPS Help Document for Secure Content provides instructions on how to enable encrypted folios. It’s not just about folios, as you’ll discover when you read that article. Your app must be built to enable the device’s Secure Content mechanism, which means that you will need to rebuild your existing app. My Protecting content on an iOS Device with DPS article in DevNet outlines the hows and whys of enabling secure content on your iOS device. Of course, your custom Viewer needs to be at R30 or higher to use encrypted folios, so you can use this as an opportunity to update your Push Notification tokens as well as add in some other App features like the Welcome Screen.

In conjunction with updating  your Viewer to R30, you also need to enable Secure Content in your Application Account. This requires administrative access to the Account Administration tool.

Enable Secure Content in DPS Account Administration

Enable Secure Content in DPS Account Administration

Once enabled, the account will now have some limits applied to it, which we will explore in some detail.

Limits enhance security for content creators

Secure content has some important implications for workflow. From the content creation side, customers expect that it should be hard for content to escape the control of the Enterprise. For content creators, it means that they will be restricted in how they can proof or share secure articles.

Preview options for Secure Content

Preview options for Secure Content


Proofing folios in a Secure Content account is limited to either desktop or tethered proofing. This means that in order to proof a folio, you need to either test it on the desktop from InDesign or connect your iPad to your Mac and turn on the Content Viewer. Once connected, you can click on the Preview… menu in the Folio Builder panel and choose your iPad. For customers using the Media Publisher in Adobe Experience Manager or another Web CMS for managing folio content, this presents a unique challenge.

When publishers use Media Publisher or other CMS, the expectation is that all folio creation is done in a browser and that InDesign is not usually part of the workflow. It is not uncommon for there to be hundreds of contributors in a large organization, and those contributors tend to be business users or knowledge workers with no access to InDesign. For accounts without Secure Content enabled, this presents no problem, since content creators can always push their content to the Folio Producer, turn on their iPad, open Content Viewer, and sign in with the Application Account credentials to proof content.

One potential workaround is to create content using a “dummy” account that does not have Secure Content enabled. This “dummy” or staging account can be an Application account or an individual contributor account that will never have an App associated with it and will only be used as a staging account for the Secure Content. As a best practice, the Enterprise should develop a policy around these staging accounts so that content will be auditable by appropriate regulatory or brand authorities within the Enterprise. In addition, the Enterprise should establish review and approval workflows within these staging accounts and a workflow for migrating content from the staging account to the deployment (Secure Content) account. Authors will create and proof their content in the staging account. Once ready for review and approval, the author would start the review and approval workflow and reviewers can review content on their iPads with Content Viewer. In cases where the Enterprise does not want any content to be viewable unless on a tethered iPad, then authors and reviewers will need access to InDesign on their desktop machines in order to proof their folios.

Article Sharing

All article sharing from a Secure Content account will be disabled. This means that if you currently share content between accounts, you will need to consider the flow of that content. It is possible to share an article from an account that does not have Secure Content enabled to a Secure Content account, though, as described in the previous paragraph in the staging account workflow. The expectation is that content in a secure account should remain in the secure account, and limiting sharing from that account reduces risk. As stated above, customers may need to adjust their workflows to consider the secure account as an endpoint for content rather than a source of content in situations where folio sharing is common.

In order to publish shared content in the secure account, a person with appropriate authority will need to log into Folio Producer and copy the shared article. Once copied, the original folio can be deleted from the Secure Content account, which will break the sharing relationship with the staging account. Unless there is a reason to keep the original shared folio in place, it may be best to remove the shared folio to reduce confusion and clutter in the Folio Producer.

Publishing encrypted folios

Enable encrypted folio upon publishing

Enable encrypted folio upon publishing

Once approved, it’s time to publish the folio. Once all of the required metadata is in place, you can push the Publish button in Folio Producer. You will notice a new checkbox: Encrypt Folio. This needs to be enabled for your folio to be encrypted in the Distribution Service.

In addition, there is an expectation among Enterprise customers that secure content needs to reside behind authentication. As a result, readers need to be entitled to any secure folios in order to view them in a Custom Viewer. This means that all encrypted folios need to be Retail folios, and the Custom Viewer needs to leverage Direct Entitlement or, more granularly, Restricted Distribution. The Enterprise will need to manage the relationship between the authenticated reader and published folios in its Entitlement solution. Once you configure the folio as Retail and enable Encrypt Folio, you can Publish the folio.

Reader experience for Secure Content

Having reviewed how Secure Content constrains the content creation workflow, let’s turn to the reader experience. From the reader’s standpoint, they should not be able to tell the difference between an encrypted folio and an non-encrypted folio. While this is generally true, there are a few differences that readers may notice when using Secure Content.

Complete download required

In a traditional workflow, DPS offers progressive downloads for content. This feature allows a reader to begin reading an article while other articles are loading. In a Secure Content workflow, the entire folio needs to be present on the device in order for it to be decrypted. As a result, secure folios may appear to take longer to download. You may want to adjust your strategy with respect to folio organization if you routinely make very large folios if the download experience is disruptive. For most Enterprise customers implementing Content Protection, this delay should be communicated to users so that they are prepared for longer wait times when they first download a folio.

Once downloaded, the folio is ready for reading and will behave like any other folio, with the exception of Social Sharing.

Mitigating social sharing risk

One of the ways that content can escape the control of the Enterprise is through a reader socially sharing the article. When you enable Secure Content, any encrypted articles will not be able to be socially shared, regardless of the settings in the Application Account. This also means that no Web renditions will be created from any articles in encrypted folios, regardless of whether they are Protected, Metered or Free. It is a best practice, therefore, to disable Social Sharing in App Builder when making apps for Secure Content accounts. For many Corporate use cases, social sharing is inappropriate, since the content in the app is usually intended to be viewed in the secure context of the Custom Viewer. If it is necessary to mix Socially Shareable articles with encrypted articles, then the user may be able to generate a “dead” URL for the encrypted article by tapping on the Social Share button, which would be a jarring user experience. In that instance, it is best to warn the reader that an article is protected and that it is not intended to be Socially Shared.

Use cases for Secure Content

Secure Content is inappropriate for most traditional publishing use cases, and it was not designed as a Digital Rights Management (DRM) scheme for folios. It is intended to offer Corporate publishers a method of protecting sensitive content while that content is in the Folio Distribution service and to limit the pathways for that content to escape the control of the Enterprise.

Common use cases for Secure Content include manuals, Board of Directors packages, regulated content, proprietary documentation, sales material, and other sensitive materials. Knowing that all encryption is susceptible to attack, Adobe uses very powerful encryption technology to protect the folios in the Distribution Service. Nevertheless, each Enterprise needs to evaluate whether its content requires this level of protection. For many customers, unencrypted folios are perfectly acceptable. For others, encryption will be a requirement. Encrypted content expands the reach of the DPS service for Enterprises and offers those customers a pathway to distribute sensitive content to tablets.


Color Management in a Nutshell

A friend of mine, Margie Dana, runs a group called Boston Print Buyers. On occasion, she forwards questions from members. Here’s one that I thought I should share.

Recently we had 2 incidents where our designers’ monitor did not match ours or the vendor’s proof. This was discovered at the proofing stage of our printing process. The proof obviously did not meet the expectation of our designer since it did not match their monitor. With that said, I have been assigned the task of finding out more about calibrating our monitors so we are all looking at the same thing.

Can you answer the questions below or point us in the right direction of finding a source that can help us?

  • Should we have our Mac monitors color calibrated?
  • If so, how often?
  • Is there a preferred method across the industry?

We do have technical support for our Macs. Should we let them do it or is this something we can do ourselves?

You’ve cracked a complex issue here. It’s not just the monitors, it’s the entire proofing workflow. In short, each stage of the proofing process, from scanner/camera to monitor to proof to press needs to be in sync. This happens through two mechanisms: linearization and characterization.

Linearization is the process where we ensure that a press or proofing device gives us what we expect. Our RIP will have a lookup table that says something like: when you ask for 30% cyan in my file, I need to put down 33% cyan on my plate because the press is off a little bit and we’ll compensate.” OK, it’s really a matrix of numbers without personality, but you get the idea. The RIP looks in the table to see how it should adjust each color in order to get output that matches the expectation.

Characterization is the process of determining what happens when we ask a device to produce a certain color. For instance, if I ask my monitor (an RGB device) to produce a CMYK mix of (2,57,33,5), what happens. Using this information about devices, I can make color transformations that allow me to simulate one color and how it will appear on a specific device on a completely different device. We encapsulate characterization in ICC profiles.

Now, let’s make this into a proofing workflow.

First off, not everyone linearizes. While I’d recommend it as a best practice for any printer, they don’t all linearize on a regular basis. There are at least two variables in the linearization process: the plate maker and the press itself. As you can imagine, it’s difficult to guarantee that press conditions are the same every day and on every sheet of paper. For this reason, most presses will linearize once or infrequently and depend on characterization.

Every device in the design to print workflow should be characterized. Cameras often have embedded ICC profiles that they will attach to images when they take them, but other devices need to have some measurements taken in order to get a profile. There are many different devices on the market to help produce an ICC profile. I am partial to Xrite’s family of devices, including the i1 and the Pulse. The Pulse is out of production now, but the i1 is current. These devices can make ICC profiles of monitors and printers, and provide very good results for representing color. These are not the only devices that do this, and I’ll leave it to the reader to explore more options for devices that can make ICC profiles.

Tube-based monitors used to go dim after a few years of continual usage. Also, the color would shift as the electron guns in the set would decay over time. Modern LCD monitors do not suffer from color degradation, but they do dim over time. In a working environment, it remains a best practice to set the monitor’s brightness to lower than maximum, so that you always have somewhere to go when the monitor begins to dim. Some shops measure their monitors daily. Others do is less frequently or once and forget it. I tried to adhere to at least monthly measurements, once I moved to LCD monitors.  I would try to measure Tube monitors weekly.

We characterize a monitor by using a device like an i1 to measure how the monitor presents colors. The characterization process is a mixture of manual steps and automated steps. The manual steps might be steps like : set your monitor’s brightness and contrast settings to specific targets. Having done that, the machine can take over and make measurements. The user hangs the measuring device against the screen and the profiling software reads hundreds of color combinations directly off of the screen. Knowing the colors that the monitor does produce allows a profile to be created. The profile shows how the monitor responds to specific requests and allows your proofing software (Acrobat? Photoshop?) to accurately display color by using the profile.

Knowing how the monitor responds isn’t the end of the story.In addition, we need to ensure that the environment in which you will view electronic proofs also meets a standard. There are many schools of though on color viewing, but the IDEAlliance and IPA have been working on getting ISO standards for viewing conditions and lighting. Currently, there is no standard viewing condition, but a rule of thumb is neutral gray surroundings with shielding to prevent reflections off of the monitor.

Once we have all of our devices profiled, we can now begin using them for proofing. You need to think about proofing in the following way: I want to use my X to show how my document will look when output to Y. X is usually a desktop proofer like an inkjet printer or a monitor, and Y is usually a printing press. Of course, we can put any device whose characteristics I know (for which I have an ICC profile) in place of X and Y, but these are the most common.

Let’s look at the whole picture.

To proof a file electronically, you need to open it in an application that understands soft proofing. These include Photoshop, Illustrator, InDesign and Acrobat as well as some other applications. In Creative Suite, you need to tell the application what monitor you are using by ICC profile. Then, with your file open, you need to tell the application about the press and the proofer. The statement goes like this: I want to use my monitor to view how a file will print on a Heidelberg press with dull coated paper and the proof is printed on an Epson proofer with semigloss paper. Getting all of the menus chosen correctly varies between applications, but when done right, it’s a great workflow.

So, to answer the questions, yes, you should characterize your monitors at least monthly if they’re LCD and more frequently if they are tubes. You can do it yourself with an i1 or other device, but all the characterization in the world will do you no good if you don’t take into consideration the entire proofing workflow and get all the pieces in sync. If you have a consultant available, use them to help set up the applications for proper proofing and get everyone in your group on board with proper proofing practices.