Posts tagged "creative suite"

Launching external apps from a DPS folio

Posted on April 5, 2013 by James Lockman | Comments (2)

Inter-app communication is a frequent request from my DPS customers. For instance, they would like to be able to launch Mail with a message already populated, or send a tweet, or post to LinkedIn. While it could be possible to do that within a Web Content Overlay, often times it is preferable to send a request to the native application or service on the device.

iOS applications have a method to allow apps to talk to each other called a Custom URL Scheme. Not all apps make use of this feature, though; it is up to the developer to implement it properly. This method is documented at Apple’s Developer Connection, and I have an article in the Adobe Developer Connection that uses the Custom URL Scheme method to navigate within a DPS folio using JavaScript and HTML. This article will discuss communicating with external apps via the Custom URL Scheme.

Some Custom URL Schemes are well understood and have been part of the HTML consciousness for a long time.

mailto:

and

tel:

are used frequently to send emails and dial a telephone, for instance. I have an article in this blog that talks about using the mailto: Custom URL scheme. How, then, can we use similar methods to communicate with other apps? First, we need to determine the Custom URL Scheme that is registered to an app. Some apps make their Custom URL Schemes well known, like Google Maps. Others do not. You can search for apps and get some help with how to craft a URL at Magnatron’s handleOpenURL site. Searching that site for Twitter, for instance, I can see that the native Twitter app uses the “twitter:” scheme and some directives to start the Twitter app and have it so something. Here are some of the commands:

twitter://user?screen_name=jameslockman
twitter://timeline
twitter://mentions
twitter://messages
twitter://list?screen_name=jameslockman&slug=abcd
twitter://post?message=hello%20world

It’s clear that if we know how to properly phrase our request, then we can easily create integrations between DPS apps and other native apps. Armed with the Custom URL Scheme, I decided to try to use it for a specific use case.

I had a request from a customer who needs to launch a Connect meeting on their iPad from a DPS application. The customer wants to provide eLearning content in DPS for offline use, and then provide a button in the DPS folio that will launch Connect Mobile and pre-populate the meeting room information.

I asked around internally, and the Connect Mobile folks were kind enough to provide me with the following Custom URL Scheme for Connect Mobile:

connectpro://https://connect.server.address/connect.room.path

OK, I thought, I’ll just make a button in InDesign and set it to go to the URL. Unfortunately, when I tap the button, the colon (“:”) after “https” didn’t pass over to Connect Mobile, so the URL got passed as

https//connect.server.address/connect.room.path

In addition, DPS launched an empty Web Overlay so that when I returned to the folio, I had to tap the “Done” button to close the overlay. Not very elegant, and not exactly what I was looking to accomplish.

After some back and forth with a few people on the Connect side (Props to David Knight, Vincent Le Quang and Minh Huynh for taking time out of their busy days to help diagnose the issue) and a lot of trying and failing with variations on escaping the colon character, it dawned on me that the solution was easy and should have been obvious.

When we create a button or hyperlink in InDesign, that button’s or hyperlink’s URL target gets passed out of the folio and to the Content Viewer, which then passes it on to iOS. This is two steps, and the special character was getting decoded and then left behind, which makes sense. The answer is to use a Web Content Overlay, which provided only one step to iOS as it is a native iOS Webkit Overlay.

I made an HTML snippet, escaped the problematic colon character with %3A, and inserted the HTML (Object>Insert>HTML) into my folio:

<a href="connectpro://https%3A//connect.server.address/connect.room.path">tap here to go to the meeting (%3A escaped)</a>

InDesign recognized the inserted HTML as a Web Content Overlay, so all that’s left to do is to set the Web Content overlay to auto play. Now, when I tap the link in DPS, my Connect Mobile app launches, the meeting URL is filled in, and all I need to do is tap Next to log in to the room. Once the session is running, I can use the 4 fingered swipe to switch back and forth between the DPS app and Connect. Pretty neat!

In most cases, you should be able to use Custom URL Schemes on buttons and hyperlinks directly from InDesign. However, you may need to put that URL into a Web Content overlay in order to allow special characters to pass out to iOS, and ultimately to your external app. Of course, it is possible to use JavaScript to dynamically compose a Custom URL Scheme request, so expect some more interesting examples from me in the future.

Share on Facebook

Single Issue vs Multi Issue Viewers for Enterprise customers

Posted on July 30, 2012 by James Lockman | Comments (2)

DPS customers have access to tools for creating and managing custom versions of the Adobe Content Viewer that can be distributed through iTunes (like the Wired or National Geographic apps). Additionally, Enterprise DPS customers can build apps for private distribution using an MDM service like MobileIron or Air-Watch. Only Enterprise DPS customers can build apps for Enterprise distribution models, and I have provided an earlier post about that process.

One of the options for the custom viewer is a Single Issue Viewer, in which one folio is embedded directly into the viewer. Single Issue Viewers have no library mode, so they are used by many of our customers who want to use MDM solutions to manage the distribution of specific folios to specific people. However, we have other customers who use MDM to distribute Multi-Issue Viewers to their managed devices, and then use our Restricted Distribution infrastructure to leverage LDAP or other authentication to control access to specific folios in that one viewer app. There are IT advantages to either approach, and I’d like to explore the differences.

In order to use an MDM system to manage apps on an iOS device, each app needs to be created using a specific unique identifier known as a mobileprovision file. Customers make these in the iOS Provisioning Portal, which is part of Apple’s iOS Developer Portal. In the Single Issue approach, each Single Issue Viewer needs a new, unique mobileprovision file from the iOS Provisioning portal. MDM solutions leverage a property of iOS whereby each app must have its corresponding mobileprovision file on the device in order for the app to run. MDM solutions can remove a mobileprovision file on a managed device, rendering the app unusable. When a customer makes a new Single Issue viewer, it must repackage this app to include the new, unique mobileprovision file in a process called resigning. There are several ways to do this, but a popular method is to use iresign from Google. This workflow is very effective because it gives IT fingertip control over each and every app on a managed device, and it allows IT to move DPS Folios in and out of circulation by wrapping them in Single Issue Viewers.

Let’s face it, though. Managing all those apps and mobileprovision files is annoying IT overhead. In the Multi-Issue approach, there is only one mobileprovision file because there is only one Viewer. Content delivery to the Viewer’s Library is based on credentials and is managed by a business user, not IT. The business user can associate content to users or groups in a portal without having to call IT to issue a new mobileprovision file. This portal can be built and managed by corporate IT using sample code from our Developer Center. Derek Lu, for instance, provides detailed instructions and sample code for integrating LDAP with Restricted Distribution. There are also commercially available servers such as Portico from MEI to enable Restricted Distribution workflows in an Enterprise without IT having to develop a backend solution from scratch.

Which method is right for your company? That depends on how you want to manage content. If you want IT to manage everything, then the Single Issue approach might be just what you need for DPS. If you want to reduce the burden on IT and shift content management over to the business users who file the IT tickets in the first place, then Multi-Issue with Restricted Distribution fills the bill. DPS is flexible: your designers create their engaging tablet content in InDesign, IT puts the apps on the devices, and either IT or business users manage the flow of those folios to users. Either way, you can use your MDM system to manage DPS viewers on your company’s tablets.

Share on Facebook

Using Adobe CQ5 as a repository for Acrobat Shared Reviews

Posted on November 28, 2011 by James Lockman | Comments (0)

Acrobat has a great feature called Shared Reviews, which allows an Acrobat Pro user to send a PDF to one or more people for their comments while allowing each of the reviewers to see all of the comments that had been made by all of the other reviewers. While the default method in Acrobat 9 and X is to use Acrobat.com as the repository, it is possible to use another server, such as Adobe CQ5, as the repository.

In a shared review, Acrobat needs two things: a PDF that has been prepared to receive comments and share them with other reviewers, and a network location that all of the reviewers can access for storing the comments. In a Shared Review, the comments are stored in a comment repository that is disconnected from the PDF itself. Acrobat uses this methodology so that it can always check with the repository to determine whether there are new comments that have been added to the PDF while you were away from it. It is very important that the repository be in a network location that is accessible to everyone, and that means using a WebDAV server. Why WebDAV? WebDAV shares use a path that looks the same on all operating systems, which is not the case for a SMB, AFP, or other operating system specific file system protocols. In addition, it is not necessary to mount the remote volume in order to communicate with it, since WebDAV has a number of file system access features that can be used through standard web calls. Acrobat knows this, so it does not need to mount the repository in order to use it for shared reviews.

To begin, we need to create a folder in CQ5 that will act as the repository for reviews. It is important that this repository be somewhat obfuscated to the casual user, so it is good to put it inside of a universal access folder that sits inside of an admin access folder. For instance, if I made a top level folder in the DAM called acrobat_reviews and inside of that another folder called repository, I would set the permissions on acrobat_reviews so that only the administrators can see it, and I would set the permissions on the repository folder so that everyone can read and write. You can also create a folder elsewhere in the repository that’s not in /var/dam. This is handy because it prevents Adobe Drive users from seeing the repository at all when they mount CQ DAM through Adobe Drive. Of course, you will want to consult your CQ system administrator to ensure that your repository location and permissions abide by your corporate policies.

Create a new folder in CRXDE LiteLet’s create a folder outside of CQ DAM and use it as our repository for Acrobat shared reviews. You will need a CQ5 Author instance to which you have administrative access and Acrobat X or a version of Acrobat that supports shared reviews. First, open up CRXDE Lite. You can create a folder other ways, but using CRXDE Lite is quick and only requires a web browser.

Navigate to the root of your CQ system, right-click on the root, and choose Create>Create Folder.

Name that folder acrobat_reviews. Right click on “acrobat_reviews” and choose Create>Create Folder again, and then name this new folder “repository”. The path bar should now show /acrobat_reviews/repository.

You’re not done yet, though, because the changes to the repository haven’t been written. You must click the “Save All” button to save the repository changes.

Now, let’s set permissions for the folders. Recall that we want to forbid access to the acrobat_reviews folder but allow access to the repository folder. In this example, we will use the user known as anonymous. You might want to use your LDAP or Active Directory groups to govern access, for instance, assuming that you have connected your LDAP or Active Directory system to your CQ instance. To set permissions, we need to use the CQ User Manager, otherwise known as CQ Security. Return to your CQ author instance landing page and click the User Manger. Double click the Anonymous user and click the Permissions tab.

Click the plus sign to the left of acrobat_reviews to show its subfolders. Leave the permissions on the acrobat reviews alone, and set the permissions on the repository to Read, Modify, Create and Delete as shown.

Click the Save link above the Path column heading to save the permission changes.

Now, we’re ready to use CQ as a repository for our Acrobat X Shared reviews.

In Acrobat X, open a PDF you want to send for Shared Review and click the Comment button to open the Comment Pane. Click the Send for Shared Review button, and then choose “Automatically collect comments on my own internal server” and click Next.

Choose the Web Server folder option. Enter the full URL to your repository. In my example, my repository is operating on my laptop and is running on port 4502. The URL to the repository is therefore http://localhost:4502/acrobat_reviews/repository. You will need to know your server URL and active port to the author instance in order to enter your own information, though. Click Next and Acrobat will prompt you for your credentials to access the repository. I used the Anonymous user, so I enter anonymous (lower case “a”) for the user and leave the password blank. If you click Save this Information, then the userid and password will be saved in Acrobat’s keychain. Each user who accesses the review will have to enter their own credentials. For groups, therefore, it makes sense to use groups to control access to the folder and therefore provide at least userid and password access to the reviews. Acrobat will create and delete a test file on the server, after which it will prompt you to choose how to send the review notification to reviewers.

You can choose to send the file with your default email application or send it later. If you are on a Mac, Acrobat looks for Microsoft Entourage, so if you aren’t using Entourage, then you might have trouble sending email from Acrobat on your Mac. In that case, save the file to attach to email later. On Windows, Acrobat supports more email clients. In any case, test to ensure that Acrobat supports your email client. If you decide to allow Acrobat to create the email, there are two options. You can choose to send the PDF as an attachment or as a link in the email message. Pick one, click Next, and then enter a name for your Server Profile. This will allow you to reuse these settings when you start Shared Reviews later.

Once you send the file to someone for review, they will need to be able to access the server, so be sure that the server URL is accessible to all of the reviewers. When a reviewer opens the PDF, they will login to the server, add comments, and then post them to the repository for other reviewers to see.

Because of its built-in WebDAV and easy to configure security, CQ5 is a great technology for Shared Review and Forms Data Collection workflows.

Share on Facebook

Fonts and Where Can I Use Them?

Posted on June 6, 2011 by James Lockman | Comments (1)

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

Posted on February 14, 2011 by James Lockman | Comments (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