Posts tagged "DAM"

InDesign Server questions and answers

Customers often ask me about InDesign Server. InDesign Server? Yes, it’s true. InDesign is available as a server, which makes document automation possible for many kinds of businesses. It offers InDesign functions as a service, accessible through SOAP or other communication protocols. It is not the desktop version of InDesign available in a browser.

Companies have successfully used InDesign Server as part of workflows that:

  • Make greeting cards
  • Produce mutual fund documentation
  • Generate personalized mail pieces
  • Assemble and print on-board schedules on a cruise ship
  • Render InDesign documents as PDF for online delivery
  • Layout quarterly catalogs for industrial parts suppliers

These are but a few of the use cases for which InDesign Server is appropriate. In all cases, InDesign Server is part of a larger business process, usually driven by a web site or a Digital Asset Management (DAM) solution such as Adobe Experience Manager (AEM) Assets. InDesign Server is also included as a component of many commercial Variable Data Publishing (VDP) and Print on Demand (POD) solutions, but those servers are licensed only for use with those commercial solutions. You can learn more about InDesign Server partners at the InDesign Server Partner Guide.

InDesign Server is a service, really, that responds to questions like:

  • “Hey, InDesign Server. If I give you this InDesign template, can you merge this XML file onto it and then give me back a print-ready PDF?”
  • “Hey, InDesign Server. Here’s an InDesign Document. Can you extract all of the text frames as RTF files and re-link them back to their original frames and then save InDesign file as a new document with _relinked added to its name?”
  • “Hey, InDesign Server. Can you make a new document, import the style sheets from this other document, then import all of the images in this folder, each on a new page, and apply the object style ‘image’ to each image and put a metadata caption with the copyright data in the lower right hand corner of each image, and then export each page as a new PDF with the file name corresponding to the filename of the image placed onto it?”

Of course, those questions must be written as scripts in one of four languages: Adobe ExtendScript, JavaScript, AppleScript or Microsoft Visual Basic. AppleScript and VisualBasic are only available when the server is running in an Apple or Windows operating system, respectively. There is an SDK and many examples available at There’s really no limit to what you can do with InDesign Server, so long as you have coders who can ask the right questions and so long as you have enough capacity to process the volume of jobs you expect to handle. There are many companies who use InDesign server to build photo books and greeting cards from customer-supplied photos, for instance. They create web sites to help customers design their books and cards online, and the actual print-ready files are made by InDesign Server. They process thousands of jobs per day, so they need to have enough capacity to keep up with their demand. How, then, do you architect an InDesign Server application from the perspective of the servers themselves?

Here’s three questions you need to ask to help scope an InDesign Server application, and then some more detail about InDesign server.

  1. Will your use case allow internal and external users to access the InDesign Server directly? If you use InDesign Server to render an InDesign document as a jpg or pdf and then post the jpg or pdf on your web site, the end user does not have direct access to InDesign server. If you make a web form that lets your end user customize a document and deliver it to them on demand, they do have direct access to the InDesign server.
  2. What is your failover or disaster recovery requirement? The deployment architecture allows for both multiple dedicated servers as well as multiple instances on servers with multiple cores. The licensing will depend therefore on how you mix dedicated servers and instances on those servers.
    The deployment architecture will also depend on maximum expected throughput. We usually look at the peak demand per minute or quarter hour or hour, depending on the use case, as well as the end user tolerance for delay between requests and results.
  3. How do you plan to support development for InDesign Server applications? Deployments typically have one or more development instances, and then two or more dedicated production servers with multiple instances available on each server to provide fault tolerance.

InDesign Server is available as an add-on to a managed services instance of AEM. Customers can also purchase InDesign Server on their own from their channel partner or from Adobe directly, depending on their relationship with Adobe. 60-day Trials are available at

InDesign Server is licensed based on use case and deployment architecture, and it is available as an annual subscription like Creative Cloud. Enterprise customers can license in three year terms as part of an Adobe Enterprise Term Licensing Agreement (ETLA). Other customers can purchase annual subscriptions from their favorite Adobe reseller. Consult the Indesign Server Buying Guide for more information.

Across the use case axis, there is Limited and Premium.

  • Limited allows a customer to use InDesign Server for an application that only their employees can access. It does not allow the customer make an interface that exposes the InDesign Server to any external user. They would purchase Single- or Multiple-Instance licenses depending on how many documents they would process per day, hour or minute.
  • Premium allows a customer to use InDesign Server for an application that external users could access as well as internal users. Consider the photo book use case where they have a web site that allows customers to upload their photos and buy a photobook. The book is made using InDesign Server driven by a web application. Again, volume would determine whether you would choose Single- or Multiple-Instance licenses.

The deployment architecture axis has two options as well: Single-Instance or Multiple-Instance.

Single-Instance allows one instance of IDS per server per license, and Multiple-Instance allows multiple instances of IDS per server per license. There is no CPU counting required, as the Multiple-Instance license includes an unlimited number if instances on the same server hardware. For instance, if a customer has a 16 core dedicated server with 32 GB of RAM, they could use one IDS Multiple-Instance license and kick off 15 simultaneous instances of IDS at a time (InDesign Server is single-threaded and uses a single core per instance and ideally 2GB of RAM). Other customers choose to deploy many Single-Instance servers on different hardware for fault tolerance and disaster recovery. InDesign Sever has a job queue manager, but many customers choose to build their own queue manager and load balancer. Adobe Experience Manager includes an InDesign Server load balancer and queue manager as part of its integration with InDesign Server. Some customers choose to deploy many Single-Instance servers, while others choose to deploy few Multiple-Instance servers, based on their requirements and available server resources.

How do you decide whether to choose Single- or Multiple-Instance architecture? It is common for high volume use cases to have at a minimum of two Multiple-instance servers, each that can process multiple simultaneous jobs. Two servers provides for fault tolerance, but it does not account for disaster recovery, which would include another instance in a different data center. The number of servers is usually determined by the typical job characteristics measured in seconds to process a typical job, divided by the number of available instances, and compared against the maximum number of jobs that are expected to be processed in a meaningful time interval, usually one minute to an hour. If you are running a financial services company that is generating three hundred complex proposals per hour, and each proposal takes 15 seconds to process, and you have 3 cores available on your server, then your server can handle 3 jobs/15 seconds * 3600 seconds/hour =  720 jobs per hour. Since you need to process 300 jobs per hour, per proposal type, you have enough capacity. But, if you need to know if you can handle the volume at the end of the trading day, when you only have 15 minutes and not an hour to get the proposals out, then your server will fall short and you should likely add another server or two to the cluster.

The last consideration is how you plan to develop and test your applications. You should have at a minimum of one development server that matches your deployment configuration, and there is a Development license available with the same use case and architecture considerations. Developers use their development tools of choice. It is common to use the ExtendScript Toolkit, which is part of Creative Cloud. Using ExtendScript Toolkit, developers can connect to a desktop InDesign to test and debug their scripts. Once they are satisfied with the performance and results, those scripts would either be moved to the InDesign Server Scripts folder or would reside in the web application or DAM, which would send the scripts as part of their job payload.

InDesign Server offers customers document automation capabilities that can provide brand consistency, high volume document creation and even new business opportunities. Whether part of a commercial solution or part of a custom application, InDesign Server delivers performance, flexibility and quality to automated document processing.


Share on Facebook

AEM Assets workflow for automatic PDF generation from InDesign files

Many of my Enterprise customers ask how they can use Adobe Experience Manager (AEM) to automate the production of common derivative files from their InDesign files. Derivative files, you ask? InDesign files often represent the “source of truth” for many business documents, from manuals to data sheets to publications and many more types. These documents must be transformed from InDesign into something else (hence the term derivative) in order to be made available on a web site, for instance. The usual method is to export a PDF from InDesign and then upload the PDF as a new asset into the repository. This puts added burden on the author of the InDesign file as well as introducing the possibility of error due to incorrectly set PDF job options. This gets even more complicated if the author must make versions suitable to send to a commercial printer as well as a version that’s optimized for reading online as a PDF. This article provides techniques to automate the production of a web-optimized and print-optimized PDF from any InDesign file that appears in AEM Assets.

This article assumes that you have access to Adobe Experience Manager Assets and InDesign Server. In this example, I use AEM 6.1 and InDesign CC Server 2015, but the technique should work with AEM 5.6.1 and higher and ID Server CS6 and higher. You need to ensure that you have configured your AEM Author environment to work with InDesign server according to the documentation found here. The foundation of any successful integration (beyond configuration!) is the combination of Scripts, Workflow Models, and Workflow Launchers.

You can download a package that contains the scripts and a workflow model you can use today. When you install the package, you will have new scripts located at /etc/dam/indesign/scripts and /etc/workflow/scripts. You will also see a new Workflow Model located at /etc/workflow/models/dam/. The Workflow Launcher must be reconfigured, since I didn’t want to disrupt your existing workflows after you install the package.


Scripts tell AEM or external applications what to do, and they form the basis of any InDesign Server-based solution. There are two sets of scripts used here: one set for InDesign Server to generate the PDFs and the other for AEM to move the resulting files. First, let’s look at the JavaScript to tell InDesign Server what we want it to do and how we want it to respond to the request.

There are a number of InDesign Server scripts included in the basic AEM installation, and I’ve modified /etc/dam/indesign/scripts/PDFExport.jsx to request specific kinds of PDF from InDesign Server.  In addition, the script writes the new PDF files into the InDesign file’s /renditions node. These two scripts are located at /etc/dam/indesign/scripts/PDFExport_Print.jsx and at /etc/dam/indesign/scripts/PDFExport_Web.jsx. I could have easily combined these two operations into one script, but I wanted to leave you the option to easily enable or disable each one according to your requirements. You can also combine them yourself or make them fancier, responding to properties you set on the InDesign file in AEM (via XMP) and read out with InDesign Server. Here is the code for PDFExport_Web.jsx, which is almost identical to PDFExport_Print.jsx. The difference is in the value of pdfExportPreset in line 31, the filename set in line 56, and the function return value set in line 57.

// Export any Indesign document as PDF

//==== get soap arguments ====
if (app.scriptArgs.isDefined("credentials")) {
 var credentials = app.scriptArgs.getValue("credentials");
} else {
 throw "CQ host credentials argument is missing";
if (app.scriptArgs.isDefined("cqHost")) { 
 var host = app.scriptArgs.getValue("cqHost");
} else {
 throw "cqHost argument is missing";
if (app.scriptArgs.isDefined("resource")) { 
 var resourcePath = app.scriptArgs.getValue("resource");
} else {
 throw "resource argument is missing";

try {
 //==== create a temporary folder under InDesign server tmp directory to fetch and export ====
 // added randomness to the folder name
 var exportFolder = new Folder("tmp-" + (new Date().getTime() - Math.floor((Math.random()*10000)+1) ));
 fileName = resourcePath.substring (resourcePath.lastIndexOf ('/'), resourcePath.lastIndexOf ('.'));
 var sourceFile = new File(exportFolder.fullName + fileName + '.indd');
 var outputFile = new File(exportFolder.fullName + fileName + '_web.pdf');
 var pdfExportPreset = "[Web Preset]" // Set your PDF Web-ready Export Preset (joboption) here.
 // You can use any joboption file installed in InDesign Server

 app.consoleout('Fetching resource from CQ: '+resourcePath);
 fetchResource (host, credentials, resourcePath, sourceFile);

 var document =;

 with (app.pdfExportPreferences) {
 viewDocumentAfterExport = false;
 var myPDFExportPreset = app.pdfExportPresets.item(pdfExportPreset);
 document.exportFile(ExportFormat.pdfType, outputFile,myPDFExportPreset);

 // close the document
 //==== remove the original resource and send the export back to CQ ====

 //==== send file to CQ ====
 var target = resourcePath.substring (0, resourcePath.lastIndexOf ('/')) + "/renditions";
 app.consoleout('Posting this file to CQ: '+outputFile);
 app.consoleout('Posting to location: ' + target);
 putResource (host, credentials, outputFile, fileName + '_web.pdf', 'application/pdf', target);
 returnValue = "PDF for Web exported and posted successfully";
} finally {
 //==== remove the temp folder ====
app.consoleout('Finished PDF for Web export using '+pdfExportPreset+' joboptions');

To use these scripts, you need to have a PDF Joboptions file installed in InDesign Server to export your PDF. When you install the package, you will find a new folder at /content/dam/InDesign Server joboptions that contains two PDF Export Presets for InDesign Server. Move these two files to Applications/Adobe InDesign CC Server 2015/Resources/Adobe PDF/settings/mul and then restart InDesign Server to load the new settings.

Now that we have the InDesign Server pieces in place, let’s look at the AEM script. This is an ECMA script, which is very much like JavaScript, and it’s located at /etc/workflow/scripts/move-pdf-renditions.ecma. I’ve written it as a function that’s called twice, once for each PDF rendition, so it’s easy to add or remove other renditions as you see fit. This script will be called from the Workflow Model, which we’ll look at next. Here’s the script code.

var renditionExtension = "pdf";
var mimeType = "application/pdf";

var workflowData = graniteWorkItem.getWorkflowData();


function movePDF (renditionPostfix) {
 if (workflowData.getPayloadType() == "JCR_PATH") {
 var path = workflowData.getPayload().toString();
 var resourceResolver = graniteWorkflowSession.adaptTo(;
 var resource = resourceResolver.getResource(path);
 if (resource !== null) {
 var asset =;
 if (asset !== null) {
 var name =, ".");
 var renditionName = name + "_" + renditionPostfix + "." + renditionExtension;
 var rendition = asset.getRendition(renditionName);
 if (rendition !== null) {
 var renditionResource = resourceResolver.getResource(rendition.path);
 var stream = renditionResource.adaptTo(;
 var targetPath = asset.adaptTo( + "/" + renditionName;
 var assetManager = resourceResolver.adaptTo(;
 assetManager.createAsset(targetPath, stream, mimeType, true);
 } else {
 log.debug("rendition " + renditionName + " cannot be found on asset " + path);
 } else {
 log.debug("Item is not an asset: " + path);
 } else {
 log.debug("Item does not exist: " + path);

Workflow Model

There will be a new Workflow Model in your Workflows list called DAM Update Asset with PDF move located at /etc/workflow/models/dam/update_asset_pdf/. It is similar to and derived from the standard DAM Update Asset workflow that comes with every AEM installation. I have changed one existing step (Media Extraction) and added a new step (a Process step called “Move PDFs from Renditions”).

These two workflow steps are different from the standard DAM Update Assets workflow

These two workflow steps are different from the standard DAM Update Assets workflow

The Media Extraction step is designed to convert InDesign documents to other formats required by AEM Assets for a number of key functionalities. These include generating sub-assets (images that are embedded within the InDesign file), page images, extraction of text, and metadata synchronization, among other things. Media Extraction sends the script (and a pointer to the InDesign file) as its payload to InDesign Server. InDesign Server then runs the script and returns something to AEM. It is important that you do not remove any of the existing scripts that Media Extraction launches, but you can always add additional steps. Here, we added two additional scripts to the workflow step: PDFExport_Print.jsx and PDFExport_Web.jsx

The Print and Web PDF Export scripts have been added to the Media Extraction Workflow Step.

The Print and Web PDF Export scripts have been added to the Media Extraction Workflow Step.

Immediately after Media Extraction, I added a new Process step that executes an ECMA script in AEM. For many users, they will access AEM Assets via their desktop using the AEM Assets Companion tool or the Creative Cloud Desktop tool, so this workflow ensures that they get the renditions they need in a place that’s easy to find. Also, users of AEM Assets will be able to search for these PDFs like any other asset under management. This script copies the PDFs from /renditions as new assets adjacent to the InDesign file. It is best to leave the PDFs in /renditions so that they can be used by components that might offer the PDF as a download, for instance.


The new Process step executes an ECMA script that copies the new PDF files so that they are accessible on the desktop.

Workflow Launcher

Lastly, it is necessary to change the Workflow Launcher that is triggered whenever a file appears in the repository or whenever a file is modified in the repository. I did not include this change in the package so that you can install the package with no impact on your running system. When you are ready and have tuned the scripts for your workflow, then you can enable the Workflow in the Workflow Launcher panel.

In your AEM Author instance, click on Tools>Workflow>Launchers or visit http://localhost:4502/libs/cq/workflow/admin/console/content/launchers.html (of course, point at your Author instance!). Select the /content/dam(/.*/)renditions/original that has no condition on it (see screenshot below) and click on View Properties, and then on Edit.

Select the proper Launcher and view its properties

Select the proper Launcher and view its properties

The Launcher is designed to run a workflow when a specific condition is met. This workflow looks for any file that appears in the repository and then runs the DAM Update Asset workflow on it. You need to change the workflow to DAM Update Asset with PDF Move and then Save the changes.

Change the workflow that is triggered by the Launcher

Change the workflow that is triggered by the Launcher

Once you’ve saved the Launcher, you are ready to test. Upload an InDesign document into AEM using your preferred method. You can use drag and drop in a Browser window, AEM Assets Companion, or CC Desktop Tool. If you happen to catch the InDesign Server console, you will see new entries that report on whether IDS was successful at exporting PDF renditions. In a short while, your new PDF  files will magically appear next to the InDesign file. Now, go ahead an edit that InDesign file and save it back to AEM Assets. Again, the workflow will run and new PDF files will replace the existing ones, ensuring that you always have access to the latest versions. And, since they are assets under management, you can always revert to earlier versions of the PDF by looking at the asset timeline in a browser.


This new workflow and the scripts that support it expose a new behavior for AEM Assets. While convenient for the user, since it automatically generates useful and necessary derivatives of the source InDesign asset, it enforces known good business processes by encapsulating approved PDF Export settings into he workflow. It also reduces errors by automating a task that otherwise would require several configuration steps in InDesign before they could export the PDF.

I hope that you find this useful, and that you use it as a starting point for further InDesign Server automation using AEM Assets.

Share on Facebook

Fixing Adobe Drive after Yosemite upgrade

Like many Mac users, I upgraded my Mavericks machine to Yosemite. While the upgrade should be smooth for most things, Adobe Drive requires an update due to changes in the way that Yosemite manages file systems. Since Drive provides low-level file system services and the hooks to those services changed, the old installation needs to be removed and reinstalled in order for Drive to work properly.

The process is simple. Browse to the Adobe Drive Installation Page and download two things: Adobe Drive and the AdobeDrive5UninstallUtility.dmg. Mount the AdobeDrive5UninstallUtility.dmg, and then follow these steps:

  1. Open Terminal
  2. Type “sudo ” (include the space after sudo)
  3. From the mounted AdobeDrive5UninstallUtility.dmg volume, drag to Terminal so that your command in Terminal looks something like:
    sudo /Volumes/AdobeDrive5-UninstallUtility/AdobeDrive5-UninstallUtility/
  4. Hit enter
  5. Enter your computer’s admin password
  6. You should now see something like the following in the Terminal:
    OSX 10.10.3 release made changes to a few systems calls.
    Manually altering Adobe Drive's Installer Hooks to be compatible with new release...
    Done with file replacements!
  7. Quit Terminal

You can now mount AdobeDrive5_0_3-mul.dmg and install Adobe Drive successfully.

Customers who use Adobe Drive with Adobe Experience Manager may also need to install a package to ensure compatibility with Drive 5.0.3. Specifically, if you are using Drive with AEM 5.6.1, AEM 6.0, AEM 6.0 SP1, AEM 6.0 SP2 then you need to install a patch on your AEM server. The patch is delivered as an AEM Package, and you can install it on your Author instances as necessary. If you use AEM 6.1 or higher, then you do not need to install this package.

One last thing: if you will be using Adobe Bridge CC in the workflow (and who doesn’t?), ensure that you keep Adobe Bridge CC up to date to avoid unexpected crashing issues. If you are in a managed deployment environment, then contact your system administrator to ensure that you have the latest Adobe Bridge CC installed.

Share on Facebook

Creative Workflow Specialist seeking data on, well, creative workflows!

I recently became a Creative Workflow Specialist here at Adobe. In this role, I spend a lot of time working with customers, helping them understand how Adobe’s diverse technologies knit together as an end-to-end content development to syndication to monetization to measurement platform. I also spend time learning about how customers have developed their own workflows using our tools, and that is the subject of this post.

In almost every meeting I attend, Bridge appears as a critical part of the workflow. This was the intent of Bridge when it was released back in the day, but it amazes me at how differently people use the same tool. Some use it simply as a file browser. Others use it for managing metadata on assets. Still more use it to interface with their Digital Asset Management (DAM) system. I have even encountered customers who built custom plugins for Bridge to allow users to interface directly with the company’s project management and product lifecycle management solutions. Wow!

I want to thank everyone who responded to the survey that I had posted here earlier in the year. We have completed our information gathering and have presented our findings in another blog post. To all of you who responded (and there were a LOT of you who responded), thanks for your insights, and keep on being creative!

Share on Facebook

Using content from InDesign documents in CQ5.5

When Adobe acquired Day Software, it got not only a revolutionary Web Content Management system, but also a revolutionary Digital Asset Management platform based on CRX, Day’s implementation of the Java Content Repository. Quick to recognize its potential as a binding agent for an end to end Adobe workflow that included asset creation and management, campaign deployment, measurement and targeting, and campaign refinement, CQ quickly jumped to the forefront of many of our minds here at Adobe.

Adobe Drive 3 can connect to a CQ DAM and provide version control for Creative Suite assets. While this functionality existed with CQ5.4, in CQ5.5, there are some built-in examples of how CQ can extend an InDesign workflow to the Web. CQ5.5 ships with a couple of workflow scripts designed specifically for InDesign Server, which is required for them to function. Without InDesign Server available to CQ, what follows won’t happen. If you are a CQ customer and would like to try this for yourself, download the InDesign Server trial and install it on the same server where you keep CQ5.5. Otherwise, read on and you’ll get a sense of what’s possible with CQ DAM and InDesign Server.

InDesign server must be running and servicing requests on port 8080. On my Mac, I issue the following terminal command to fire up ID Server prior to starting CQ. I assume that it’s similar on Windows:

/Applications/Adobe\ InDesign\ CS5.5\ Server/ -port 8080

Once it’s running, it’s safe to start CQ in author mode. We’re looking at an author instance, not a publish instance, from this point forward. Once it’s running, you can mount the repository with Drive 3. Open Drive 3 and connect to your DAM. In my example, I’m running CQ on my local machine, hence the localhost connection.

Once connected, I can browse content in the DAM as if the DAM were a filesystem. CS apps such as Photoshop, Illustrator, InDesign, InCopy and Bridge understand that when CQ DAM is mounted via Drive, they can check files into and out of the DAM and access versions of those files in the DAM. This article isn’t about version control, though, it’s about repurposing content from InDesign in CQ5.5.

When I drop an InDesign file into the DAM via Bridge, Bridge creates a version and checks the file into CQ. In CQ, the appearance of that InDesign file fires off a series of workflow steps that, with the help of InDesign Server, create previews of that file, extract an IDML rendition of that file, extract text and images from that file, and assemble those items into a Page node in CQ. It’s this page node that’s the really, really cool product of ingestion.

Page nodes are reference-able in CQ using a reference component. Normally, when you place a reference component onto a page in CQ, you double click it and browse to the page you want to reference. Unfortunately, when CQ and InDesign Server make the page node of your InDesign file, it places that page into the “renditions” folder, which is a reasonable place to store it. Unfortunately, the Reference component doesn’t know how to look into the Renditions folder for this Page note. Fortunately, a colleague on the Chinese Solutions Consulting team, Joseph Lee, figured out a simple solution that allows us to use this page node as a source of content for other pages on our CQ site.

In the diagram above, the selected page node needs to move up two levels in the hierarchy so that it is at the same level as the jar:content node, just below the InDesign file’s primary node. We can drag it up there in CRXDE Lite, but that’s pretty “dirty,” as Joseph was quick to point out. Looking at the workflow, however, he identified a single modification that puts the page node into a place where it can indeed be found by a reference component. Note that it will no longer appear in the Renditions tab when you browse to the InDesign file in DAM, however. I think that the trade-off is worth it, though.

The change we need to make is in the DAM Update Asset workflow. Browse to your workflows console and double click DAM Update Asset. At the bottom of the workflow, there’s a step called Page Extraction. This is one of the new steps that’s included in CQ5.5. You need to change the Page Root Path to “/.” (do not include the quotes) just like below. This will instruct the workflow to create the page node directly below the InDesign file’s primary node. Once you’ve made the change, click OK and then Save in the upper left hand corner of the window. Now, you’re ready to reuse content from your InDesign files in your CQ pages.

To see this in action, let’s look at what the reference component will see after this workflow change, and after we either ingest a new InDesign file or make a change to it and check it back into the DAM, either of which will trigger the InDesign Page Extraction workflow and fix the page node location. Once you do this, you can now browse to it from a reference component.

In the figure above, I have selected a story that’s present in my InDesign document. Here it is in InDesign:

Now, here it is on my CQ page.

Now, here’s the really, really cool part. Nowhere in this process was I required to send my InDesign document overseas for XML extraction in order to get its content back into my Web Content Management system. Ingestion took literally seconds and allowed my authors to use the text and images from my InDesign documents immediately. In addition, when a user makes a change in InDesign and checks the document back into the DAM, the text will update in my CQ Author instance so that I can gracefully publish it to the Publish instance when I am ready.

Thanks again to Joseph Lee for his elegant but powerful suggestion to expose the page rendition to reference components.

I know that this workflow is a demonstration of capabilities, but what an amazing demonstration it is. A capable developer could develop components and workflows which would allow a CQ user to edit that same referenced copy, and then would fire off a workflow to re-inject that content back into the InDesign document. How about the situation where a CQ user mocks up a page layout and then pushes a button to tell InDesign Server to build an InDesign document using a specific template and the text and images from the repository. The possibilities are endless.

I firmly believe that CQ5.5 and its ability to drive InDesign Server heralds the beginning of a new era in multi-channel communications. Already the lines between print and web and apps are blurred. With InDesign Server and CQ5.5, those lines disappear entirely. Now, content truly becomes independent of presentation, which frees the marketer or publisher to extend their reach in existing channels and expand their businesses into emerging channels.

Share on Facebook