Posts tagged "questions"

Fonts and Where Can I Use Them?

I came across a question recently in a developer forum, and I felt it warranted broader exposure.

“What is the legality of embedding fonts in an app for distribution?”

This is a thorny issue. Not all fonts are licensed for use in all places. Arial specifically has a checkered past, as outlined in its Wikipedia page. Nevertheless, it is instructive to look at paragraph 12 of Monotype’s current End User License Agreement (EULA):

12.  You may electronically distribute Font Software embedded in a “Personal or Internal Business Use” document (that is, a document other than a “Commercial Product” as defined herein) only when the Font Software embedded in such document (i) is in a static graphic image (for example, a “gif”) or an embedded electronic document, and (ii) is distributed in a secure format that permits only the viewing and printing (and not the editing, altering, enhancing, or modifying) of such static graphic image or embedded document. You may not embed Font Software in a Commercial Product without a separate written license from MI, and you may not embed Font Software in an electronic document or data file for any reason other than your own Personal or Internal Business Use.

The emphasis in the above paragraph is mine. With that kind of license, how should a developer proceed?

It turns out that Adobe sells a package called the Font Folio, which includes fonts both wholly owned by Adobe and also licensed from other foundries, including Monotype, who owns Arial. The licensing for those non-Adobe fonts in the Font Folio varies from typeface to typeface, and often includes different terms for print vs web vs video vs app inclusion. Those terms may also forbid alteration of the font in any way. These EULAs are written by the foundry and not by Adobe, and Adobe has no control over what the terms of a specific EULA will be for a licensed font. Arial has one of those licenses, by the way. You can read Adobe’s font EULAs here.

Adobe has a subset of the Font Folio called the Font Folio Select (FFS). It consists of the fonts that are wholly owned by Adobe and have the broadest license terms of any fonts in terms of how they can be used. Any font in the FFS can be used in print, in an app, in a SWF online, in video and more. They can also be modified, but there are some specific licensing considerations around modifications that you’ll want to investigate. The short of it is that if you modify a glyph in a font and then deploy that modified font in your company, you are no longer permitted to use the ORIGINAL font. If you want the original version AND the modified version at the same time, then you need to purchase another license for the original.

FFS is available to customers who purchase through licensing programs. It is not available as a boxed product through traditional retail outlets. Customers should contact their preferred reseller to learn more.

So, can you use Arial in your app? That depends on how you acquired Arial and the license that was in force when you got it. It is best in this case to NOT embed Arial in your app, but to allow the operating system to supply the resource. Every modern computer on the planet started life with Arial installed, so it’s a pretty safe bet that it resides on your customer’s computer. For other fonts, look closely at the EULA that came with that font. You may find that there is no limitation and you may find that there are explicit limitations. If you have some old fonts lying around, those EULAs tended to be pretty lenient until recently, because there was no idea of Rich Internet App or mobile app when they were struck. Those EULAs remain in force, so you might have some hidden gold in those old floppies out in your barn.

Share on Facebook

Version Cue and Adobe Creative Suite 5

From time to time, customers ask me how to use Version Cue with Adobe Creative Suite 5. Version Cue is not a platform that Adobe will support going forward, but for now, there is at least a means of using Version Cue CS4 with Creative Suite 5. Drive 2 is available now and is out of beta. Get it here.

Most recently, I had a customer ask about how to migrate their Version Cue CS2 workflow to a Version Cue CS4 and Creative Suite 5 workflow.

To migrate, you’ll need to go from VC CS2 to VC CS3 and finally to VC CS4. There isn’t a direct migration path from CS2 to CS4. You can migrate from CS2 to CS3 from the server administration panel’s Advanced section, and this is best done on the machine where the new server is running.

Once you’ve done that, install Drive 2 on your CS5 machines. Browse to your VC CS4 server and log in to your projects. You will be able to check content in and out from the desktop and from within CS5 apps. In addition, if you would like to use Bridge with VersionCue CS54 then you will need to enable VersionCue support in Bridge. After you install Drive2, you’ll see the following message when you start Bridge:

You can enable or disable Drive2 in Bridge later if you want to. Go to Bridge’s preferences, and disable the Drive 2 Startup Script. Once installed, you will have access to the inspector Panel. The metadata explorer is off by default, but you can enable it in the preferences as well.

Having done that, you will now have a new panel in Bridge that lets you access projects through Drive 2. Click on Drive 2, then click the Connect To.. icon in the Content panel.

Then, enter the URL and credentials for your server.

Once you’re connected, then you can then browse your Version Cue CS4 projects in Bridge CS5. In addition, you can show versions, examine metadata, check out files and check in new versions. You’ll be able to use Version Cue directly from within InDesign, InCopy, Photoshop, and Illustrator. You’ll also be able to view versions and check files in and out from Bridge and the desktop.

To open/check out project files from within CS5 applications, simply browse to them in the Drive 2 folder that will appear on your desktop when you log in to your server.

It is interesting to note that Drive 2 allows you to check any file type into and out of a project, not just Design application files. You can manage versions of Flash Builder files, for instance, or even your Office documents. It’s a very versatile solution for small workgroups.

Share on Facebook

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.

Share on Facebook