Posts tagged "InDesign Server"

AEM 6.4 and InDesign Server workflows demystified

For many versions, Adobe Experience Manager has included support for parsing InDesign documents via InDesign Server. AEM admins could use pre-built workflow steps to send an InDesign document or InDesign Snippet to InDesign Server along with a set of scripts that InDesign Server would execute against the payload. It was possible to execute multiple scripts in sequence on the same payload, which was handy but not particularly efficient as it would invoke InDesign Server as many times as you had scripts in the workflow. In AEM 6.3, the workflow component matured to make the workflows more efficient, and to include a set of functions that help InDesign Server access content in AEM and to post output documents back to AEM for further processing. In AEM 6.4, the workflow component added a configuration to permit any MIME-type as the payload for InDesign Server, opening up a whole new set of use cases for AEM and InDesign Server.

Scripts Deconstructed

The InDesign Server workflow component is called Media Extraction. It began life as a way to extract the text, images and metadata from InDesign documents, and it’s a core part of the built-in DAM Update Asset workflow today. Media Extraction has a lot of power as a workflow ingredient, however, if you know how to use it. Let’s explore how the Media Extraction workflow component works in AEM 6.4.

Media Extraction works by sending a payload to InDesign Server, consisting of a document and a script that InDesign Server executes on the document. As stated above, earlier incarnations only allowed the payload to include an InDesign Document (.indd) or InDesign Snippet (.idms), but 6.4 lets us send any document, as long as it passes our MIME-type filter. You can specify the MIME-type in the Process Arguments section of the workflow step. It helps to know the MIME-type of your content. You can use one of the many resources online to help identify common MIMI-types, but you may want to upload a file of the desired type to AEM and then examine its /jcr:content/metadata/dam:MIMEtype node to see what AEM thinks it is.

MIME Types

Specify the allowed MIME types for your scripts. The default is InDesign and InDesign Snippet.

You will also need to send a script that can process the payload and return the resulting file back to AEM. The Media Extraction workflow component reads and sends .jsx files, which contain the actual script code, to your InDesign Server. The built-in scripts are located at /libs/settings/dam/indesign/scripts/ and you should not move or change them. You can copy them to /apps/settings/dam/indesign/scripts/, or leave them in place and put your own scripts in /apps/settings/dam/indesign/scripts/. The critical thing to know is that the .jsx files are actually script fragments, and that they are designed to be concatenated into one script at runtime.

Scripts are concatenated from top to bottom in the list of scripts specified in Process Arguments

There are four sections in Process Arguments: ExtendScript Library, Init Script, Extend Scripts, and Cleanup Script. It is not recommended to modify the ExtendScript Library, located at /libs/settings/dam/indesign/scripts/cq-lib.jsx, as it provides important functions related to processing the inbound payload and to returning the resulting file back to AEM. Read and understand the helper functions provided by the ExtendScript library; you will be glad you did.

If you look at the default Init Script, located at /libs/settings/dam/indesign/scripts/Init.jsx, you’ll see that it contains an unclosed try {. This try { encloses the scripts indicated in the Extend Scripts section, and it closes in the Cleanup Script, located at /libs/settings/dam/indesign/scripts/Cleanup.jsx It continues with a catch{}, as expected, for error handling. This means that each of the Extend Scripts can leverage the work done and functions defined by the preceding scripts, including the ExtendScript Library and the Init Script, as the workflow component will combine the jsx files into one before sending the single, combined script to InDesign Server.

If you do not specify an Init Script and a Cleanup Script, the Media Extraction component will use the default scripts. Study these two scripts to see how to prepare to handle the inbound payload, how to process errors, and how to clean up the temporary files mess left during your processing. It is a good idea to use the existing Init.jsx and Cleanup.jsx files as the starting and ending points for your solution, so make copies (and name them something that stands out!) in /apps/settings/dam/indesign/scripts/ and modify those for production.

Example, please

Let’s look at an example called IDSBasedThumbnails, that you can download and install from github. The package contains the scripts and a workflow model, which performs the following actions on PDF, AI, PS or EPS files:

  • Sends the file to InDesign Server as a payload
  • Places, scales and centers the document on a new InDesign document
  • Exports the new document as thumbnails (PNG and JPEG)
  • Puts the exported files back in the repository at /jcr:content/renditions/
  • Wipes out the debris and closes InDesign Server

You might be asking why would anyone want to do this? Well, it turns out that AEM doesn’t have native rendering for EPS files, and the default DAM Update Asset workflow uses ImageMagick to generate previews from EPS files. I thought that it would be better to use InDesign Server, as it can handle not only EPS files, but also PDF, AI, PS and a whole set of other asset types. In addition, InDesign can simulate overprints and flatten complex transparency during the export, which makes it a very accurate way to deliver color-managed previews for assets used in printing processes. Think of packaging, where there’s a lot of use of overprinting varnishes and spot colors. Also, InDesign Server is super fast at making these renditions, operates as a dedicated image processing server, and can scale to meet demand without impacting the AEM Server. Let’s dig in to the workflow and see some example output.

MIME-type and ExtendScripts for making thumbnails with InDesign Server

MIME-type and ExtendScripts for making thumbnails with InDesign Server

As you can see above, we have many allowed MIME-types to cover the various assets we want to preview. If you try to run the workflow on a Word document, it will not work, as it won’t pass the initial MIME test. We’ve left the ExtendScript Library alone, but we’ve made new Init.jsx and Cleanup.jsx files that focused specifically on non-InDesign documents as payloads. The bulk of the work happens in EPSThumbnailExport.jsx, and we’ll highlight some of that script here.

The function called exportThumbnail() does the most of the work, and there’s a helper function called myGetBounds() at the end that returns the dimensions of the rectangle contained within the margins of the page. I’ve not included that below. Also, I’ve included comments to help explain what each of the sections of code is doing. Know that many of the inputs of the exportThumbnails() function are defined by the ExtendScript Library and the Init Script, which is why those are so important to read and understand.

function exportThumbnail(document, folderName, fileName, resourcePath, host, credentials) {
var myDocument = app.documents.add();
    //set the margins to 0
    myDocument.marginPreferences.top = 0;
    myDocument.marginPreferences.left = 0;
    myDocument.marginPreferences.bottom = 0;
    myDocument.marginPreferences.right = 0;

    //The following assumes that your default master spread contains two facing pages.
    //We set the margins on the master spread to 0 as well, on the left and right pages
    myDocument.masterSpreads.item(0).pages.item(0).marginPreferences.top = 0;
    myDocument.masterSpreads.item(0).pages.item(0).marginPreferences.left = 0;
    myDocument.masterSpreads.item(0).pages.item(0).marginPreferences.bottom = 0;
    myDocument.masterSpreads.item(0).pages.item(0).marginPreferences.right = 0;
    myDocument.masterSpreads.item(0).pages.item(1).marginPreferences.top = 0;
    myDocument.masterSpreads.item(0).pages.item(1).marginPreferences.left = 0;
    myDocument.masterSpreads.item(0).pages.item(1).marginPreferences.bottom = 0;
    myDocument.masterSpreads.item(0).pages.item(1).marginPreferences.right = 0;

    //We set the page width and height to 319px, with portrait orientation
    myDocument.documentPreferences.pageHeight = "319px";
    myDocument.documentPreferences.pageWidth = "319px";
    myDocument.documentPreferences.pageOrientation = PageOrientation.portrait;

    //One page only
    myDocument.documentPreferences.pagesPerDocument = 1;

    //These settings control how InDesign Server handles black ink.
    //False means that InDesign will attempt to display how the black ink 
    //will interact with the substrate and the other inks in the job.
    //True will use a faster but less accurate model. The faster, less accurate model 
    //is the default behavior in InDesign, which is why we need to change the setting here.
    app.colorSettings.idealizedBlackToExport = false;
    app.colorSettings.idealizedBlackToScreen = false;


    //PNG export options here. 
    //Disable anti-alias to hide boundaries between atomic regions
    //created by transparency flattening
    app.pngExportPreferences.antiAlias = false;

    //All pages must be exported for PNG. We only have 1 page, 
    //but we need to specify the range
    app.pngExportPreferences.pngExportRange = PNGExportRangeEnum.EXPORT_ALL;

    //We want to simutate overprinting. This works 
    //in conjunction with the black setting above.
    app.pngExportPreferences.simulateOverprint = true;

    //We want the color space to be RGB.
    app.pngExportPreferences.pngColorSpace = PNGColorSpaceEnum.RGB;

    //We want a high quality PNG
    app.pngExportPreferences.pngQuality = PNGQualityEnum.HIGH;

    //Resolution set to 72 to generate 319 x 319 preview. 
    //We will adjust for each preview size.
    app.pngExportPreferences.exportResolution = 72;

    //JPEG export options here. The same settings apply for JPEG as for PNG
    app.jpegExportPreferences.antiAlias = false;
    app.jpegExportPreferences.simulateOverprint = true;
    app.jpegExportPreferences.jpegQuality = JPEGOptionsQuality.MAXIMUM;

    //Resolution set to 300 for high quality JPEG for zooming.
    app.jpegExportPreferences.exportResolution = 300;

    //Prepare for the thumbnail files
    var jpegRendition=new File(exportFolderThumbnail+"/"+"cq5dam.rendition.jpg");
    var thumbnail319=new File(exportFolderThumbnail+"/"+"cq5dam.thumbnail.319.319.png");
    var thumbnail140=new File(exportFolderThumbnail+"/"+"cq5dam.thumbnail.140.140.png");
    var thumbnail48=new File(exportFolderThumbnail+"/"+"cq5dam.thumbnail.48.48.png");
    var thumbnail1280=new File(exportFolderThumbnail+"/"+"cq5dam.web.1280.1280.png");

    //Create a new page in the document
    var myPage = myDocument.pages.item(0);

    //Get the page size as an array
    var myBounds = myGetBounds(myDocument, myPage);

    //Create a new text frame
    var myImageFrame = myDocument.pages.item(0).rectangles.add();

    //Make the image frame fill the page
    myImageFrame.geometricBounds = myBounds;

    //Ensure that the placed file will center in the frame and fit proportiionally
    myDocument.frameFittingOptions.properties.fittingAlignment=AnchorPoint.TOP_LEFT_ANCHOR;
    myDocument.frameFittingOptions.properties.fittingOnEmptyFrame=EmptyFrameFittingOptions.FILL_PROPORTIONALLY;
    myImageFrame.frameFittingOptions.properties.fittingAlignment=AnchorPoint.TOP_LEFT_ANCHOR;
    myImageFrame.frameFittingOptions.properties.fittingOnEmptyFrame=EmptyFrameFittingOptions.FILL_PROPORTIONALLY;

    //Remove the black stroke on the frame
    myImageFrame.strokeWeight = 0;  

    //Place the payload into the frame
    myImageFrame.place(sourceFile);

    //Fit the payload in the frame proportionally and centered
    myImageFrame.fit(FitOptions.PROPORTIONALLY);

    //Export the JPEG Rendition
    myImageFrame.exportFile(ExportFormat.JPG, jpegRendition);

    //Export the 319 thumbnail
    myImageFrame.exportFile(ExportFormat.PNG_FORMAT, thumbnail319);

    //adjust the resolution and export the 140 thumbnail
    app.pngExportPreferences.exportResolution = 32;
    myImageFrame.exportFile(ExportFormat.PNG_FORMAT, thumbnail140);

    //adjust the resolution and export the 48 thumbnail
    app.pngExportPreferences.exportResolution = 11;
    myImageFrame.exportFile(ExportFormat.PNG_FORMAT, thumbnail48);

    //adjust the resolution and export the 1280 thumbnail
    app.pngExportPreferences.exportResolution = 289;
    myImageFrame.exportFile(ExportFormat.PNG_FORMAT, thumbnail1280);

    //Close the temporary document without saving
    myDocument.close(SaveOptions.NO);

    //==== send files to AEM ====
    app.consoleout('Posting this file to AEM: ' + "cq5dam.rendition.jpg");
    app.consoleout('Posting to location: ' + target);
    putResource (host, credentials, jpegRendition, "cq5dam.rendition.jpg", 'image/jpeg', target);

    app.consoleout('Posting this file to AEM: ' + "cq5dam.thumbnail.140.140.png");
    app.consoleout('Posting to location: ' + target);
    putResource (host, credentials, thumbnail140, "cq5dam.thumbnail.140.140.png", 'image/png', target);

    app.consoleout('Posting this file to AEM: ' + "cq5dam.thumbnail.48.48.png");
    app.consoleout('Posting to location: ' + target);
    putResource (host, credentials, thumbnail48, "cq5dam.thumbnail.48.48.png", 'image/png', target);

    app.consoleout('Posting this file to AEM: ' + "cq5dam.web.1280.1280.png");
    app.consoleout('Posting to location: ' + target);
    putResource (host, credentials, thumbnail1280, "cq5dam.web.1280.1280.png", 'image/png', target);

    app.consoleout('Posting this file to AEM: ' + "cq5dam.thumbnail.319.319.png");
    app.consoleout('Posting to location: ' + target);
    putResource (host, credentials, thumbnail319, "cq5dam.thumbnail.319.319.png", 'image/png', target);

}

Once this script completes and all of the images have been written back to AEM via the putResource() calls, the Cleanup Script runs.

The result of this script is that all of the thumbnails for the specified Asset in DAM have been replaced with new thumbnails generated by InDesign Server. Here are some before and after images to give you an idea of the difference and why this model could be useful.

Previews without new workflow

Here are two EPS files and one PDF uploaded to DAM. ImageMagick preview has failed to generate a preview of the EPS files, and the PDF file shows no overprinting.

In order to run the workflow, you need to have InDesign Server installed, running, and your AEM instance needs to be configured to use InDesign Server. You can either open the workflow called DAM Update Asset with IDS Previews and run it on an asset from the Workflows panel, or you can open an asset and choose Run Workflow from the bottom of the Timeline panel for a specific asset. As configured, the workflow can’t run on a folder, since the MIME-Type filter doesn’t pass folders, so you need to run it one at a time on each asset. When you do, you will see the following result, and pay close attention to the difference in the PDF thumbnail:

Once the workflow generates previews, the new thumbnails replace the existing thumbnails with color accurate, overprint-simulated previews.

The PDF thumbnail now properly respects the overprint settings in the PDF, as well as in the EPS file. This is critical in managing assets that are designed to support print workflows that make use of overprinting and multi-ink composite colors, such as packaging and book covers. You might be wondering about why the previews for the CMYK Overprints.pdf and CMYK Overprints.eps are cropped differently. This is due to the way that InDesign interprets artwork boundaries when it imports assets. InDesign uses the page boundaries as defined in the EPS file when placing onto the page. PDF files can and often do have a number of boundaries available. InDesign, by default, will select the Bounding Box (Visible Layers Only) if it is available. This box is defined by the authoring application and typically exactly bounds the edges of any visible objects on the page as determined by layer visibility. You can learn more about PDF Bounding Boxes at this InDesign Secrets article.

InDesign defaults to the Bounding Box (Visible Layers Only) when importing PDF. You need to adjust the import preferences in your script if you want to change the default PDF import behavior.

InDesign defaults to the Bounding Box (Visible Layers Only) when importing PDF. You need to adjust the import preferences in your script if you want to change the default PDF import behavior.

The bounding boxes constants are: PDFCrop.cropPDF, PDFCrop.cropArt, PDFCrop.cropTrim, PDFCrop.cropBleed, PDFCrop.cropMedia, PDFCrop.cropContentAllLayers, PDFCrop.cropContentVisibleLayers. You can add a line before myImageFrame.place(sourceFile) to change the behavior to match how InDesign imports EPS files:

app.pdfPlacePreferences.pdfCrop = PDFCrop.cropMedia;

If you make the change, you will need to save the JSX, then reimport the JSX to your workflow, then re-sync your workflow in order for it to become available. Importing the JSX can be a confusing step, so let’s discuss that briefly. The built-in asset browser for JSX files doesn’t let you select a JSX from the file tree. It’s a known issue and it will be fixed in a later version of AEM, but for now, the Search bar is your best friend. Just enter the name of the JSX you want to import, and it’ll appear in the search results. Select it, and you’re all set.

Use the Search bar to reimport your modified JSX to the workflow step.

Use the Search bar to reimport your modified JSX to the workflow step.

Once you re-import the JSX, the change is automatically saved to the workflow, but the workflow needs to be synced to become active. Once you tap the Sync button, you’re ready to go.

Be sure to tap Sync after updating the workflow step.

Be sure to tap Sync after updating the workflow step.

After you update the JSX and re-sync the workflow, the PDF and EPS thumbnails will be similar.

After you update the JSX and re-sync the workflow, the PDF and EPS thumbnails will be similar.

You could also modify the DAM Update Asset workflow to remove ImageMagick and/or the built-in PDF renderers and replace them with a new step. You would likely want to expand the script to handle multi-page PDF and AI files, however. If you’d like to explore this option, here’s a great starting point from Mike Edel for importing multi-page PDF and AI into InDesign via scripting.

Conclusion

Being able to use InDesign Server to generate better previews for EPS and PDF and AI files is a nice new benefit of the new MIME-type options in the Media Extraction workflow. This is a relatively trivial example of what a developer can do with this new capability, however. You could create a workflow that sends a whole package of items to InDesign Server, which would do some action on those items, and then return a new file or other data to AEM. Integrators can develop new editorial and creative tools based on this new capability to enhance existing inDesign documents or create entirely new ones from scratch. We hope you will be inspired to add more InDesign Server to your AEM Assets workflows.

Share on Facebook

Relinking placed content in Creative Cloud applications with assets from AEM

Customers who move from a file system to a Digital Asset Management (DAM) system such as Adobe Experience Manger Assets (AEM Assets) realize many benefits, including but not limited to more comprehensive search, access to augmented asset metadata, and workflows to syndicate content to multiple channels. Assets under management in many DAM systems tend to be locked in the DAM, accessible through a search interface that lets users collect assets for extraction from the DAM. Once the user downloads the assets, however, the “M” part of DAM breaks. This article presents best practices for allowing Creatives to use content from DAM such that DAM maintains control over the asset and the “M” part of DAM is preserved.

AEM Assets, like most modern DAM systems, provides two basic functions: asset and associated metadata storage, and access to those assets through a search interface in a browser. AEM offers a method to mount the repository on the desktop, exposing assets to end users as if they had been downloaded from DAM. When you combine search with the ability to expose assets as files, you get a very powerful combination that will be the subject of the rest of this article. AEM also provides robust workflows that can be activated through a variety of triggers. We will touch on workflows later in this article as a way to extend these core capabilities.

AEM 6.1 and higher has a UI preference to enable desktop actions. This means that if a user selects a file or folder, the user can choose to Reveal on desktop or Open on desktop. These actions are meaningful when you install the AEM Desktop Tool, which is a free application available on Mac and Windows. We will circle back to them in a few minutes.

The AEM Desktop Tool is a client that exposes the AEM Assets repository as an SMB file system. This allows any Creative Cloud desktop application to access DAM content without the need for any plugins or extensions. Download and install the AEM Desktop Tool from the Direct Download page. This page also shows any dependencies that may be required on the AEM side to support the current release of the Desktop Tool. Check with your AEM System Administrator to ensure that the correct packages are installed on AEM before you install the Desktop Tool. Once you have the packages installed and activated, you can install AEM Desktop. Once you install AEM Desktop, you can mount your AEM Assets server as a volume on your desktop. Login using your Author credentials.

Mount AEM Assets action on desktop

Once you login, your AEM Assets repository appears as a mounted volume.

DAM mounted as a volume

To enable desktop actions in AEM, you need to enable a setting in your user preferences in AEM. Navigate to your Preferences page (path varies depending on your AEM version, but is is usually found under your profile image in the upper right hand corner of the screen) and enable Show desktop actions for Assets. Click Accept and you’re ready to go.

Enable "Show desktop actions for Assets"  Additional contextual menu items

Reveal on desktop and Open on desktop actions appear when you navigate to an asset or folder in the Assets interface in AEM. Hover over a folder in Assets to see the Reveal on desktop icon, and hover over an asset in Assets to see the Open on desktop icon. Reveal in desktop is available under the more… indicator. Both of these actions will appear in the rail on an asset details page.

Desktop actions on an asset     Reveal on Desktop on a folder

Now that we have the plumbing installed, let’s turn to best practices.

Updating linked assets from DAM

The most common question I encounter from customers who have moved their assets to DAM is “how do I relink my images in DAM from InDesign?” followed by “How do I relink my images in DAM from Illustrator?” This question arises because when these assets were stored on a desktop computer or on a file server, all of the linked images also resided on the same desktop computer or file server. When the assets were ingested into DAM, they no longer appear in the same path, so InDesign, Illustrator and Photoshop get confused as to where these assets are in relation to the files in which they have been placed. Reveal on desktop turns out to be a deceptively simple solution. Follow these steps to relink your assets from DAM in your layout document.

  1. Open your layout document. For the sake of illustration, let’s use InDesign. InDesign will tell you that the links are broken and that they need to be updated. DO NOT LET INDESIGN automatically update the links. We need to do this manually in order to ensure that we make the right connections.
  2. Select the first image in the Links panel
  3. Choose Relink… from the Links panel. A file system browser will open. Do not browse to a file.
  4. Switch to your browser and navigate to AEM Assets
  5. Open your Search interface
  6. Search for the asset by filename or other metadata
  7. Reveal it on desktop. It will now come in focus in your file browser, and it will be selected.
  8. Drag the file onto your already open InDesign relink… file browser.
  9. Release the file and the InDesign relink… file browser will now have your DAM asset selected.
  10. Click open to relink the image.

If you have other images in the same DAM folder, you can then relink to the folder. When you run out of images to link, repeat the Relink…, Search, drag, Open pattern until your InDesign document has all new links. Once you are done, save the InDesign document locally so that you can make changes. Once your document goes through your approval process, upload it to DAM as a new document or as a new version of one already in DAM.

While this may sound cumbersome, once you get the hang of it, it will feel like second nature. Over time, as you make new documents using images in DAM, instead of starting with Relink…, start with Place… or just drag the found-and-revealed image onto your layout. InDesign will link to the image in DAM, and the next time you open the InDesign file, it will be properly connected. If you’d like to see an example, watch this short video.

 

Share on Facebook

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 adobe.com/devnet. 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 http://www.adobe.com/cfusion/tdrc/index.cfm?product=indesign_server

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

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) ));
 exportFolder.create();
 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 = app.open(sourceFile);

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

 // close the document
 document.close(SaveOptions.no);
 
 //==== remove the original resource and send the export back to CQ ====
 sourceFile.remove();

 //==== 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 ====
 cleanup(exportFolder);
}
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();

movePDF("print");
movePDF("web");

function movePDF (renditionPostfix) {
 if (workflowData.getPayloadType() == "JCR_PATH") {
 var path = workflowData.getPayload().toString();
 var resourceResolver = graniteWorkflowSession.adaptTo(Packages.org.apache.sling.api.resource.ResourceResolver);
 var resource = resourceResolver.getResource(path);
 if (resource !== null) {
 var asset = Packages.com.day.cq.dam.commons.util.DamUtil.resolveToAsset(resource);
 if (asset !== null) {
 var name = Packages.org.apache.commons.lang.StringUtils.substringBeforeLast(asset.name, ".");
 var renditionName = name + "_" + renditionPostfix + "." + renditionExtension;
 var rendition = asset.getRendition(renditionName);
 if (rendition !== null) {
 var renditionResource = resourceResolver.getResource(rendition.path);
 var stream = renditionResource.adaptTo(Packages.java.io.InputStream);
 
 var targetPath = asset.adaptTo(Packages.org.apache.sling.api.resource.Resource).getParent().getPath() + "/" + renditionName;
 var assetManager = resourceResolver.adaptTo(Packages.com.day.cq.dam.api.AssetManager);
 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.

Process_Step

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.

Conclusion

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