Advances in Adobe’s XMP Specification (PDF, Part 2 — Additional Properties) means by-and-large the Cumulus DocWatch plugin for InDesign can go away! Adobe CS5 applications (verified for CS5 but CS4 has most of the required elements) can take advantage of newer properties, most notably in the Media Management Schema.
All of this beg’s the question: What the heck do we an InDesign Plugin for, anyway?
I think the answers is: Not much.
XMP has matured to the point were Canto can (almost) ditch the Cumulus DocWatch Plugin for InDesign CS5 and above, possibly CS4 too.
Let’s start by looking at what Canto says the plugin actually does and how it makes working with InDesign Documents in Cumulus a more enjoyable experience. Open the Cumulus 8.6.1 Online Help Documentation, and click on the Index tab. Find or jump to the “I” section and the “InDesign Plugin” topic. We need to read between the lines a little since the documentation hasn’t been updated in a while. It still talks about the plugin making TAG files and does not reference InDesign CS6 at all.
For reference, Cumulus 8.1.2 updated the InDesign Plugin (at least CS3 and above) so that it writes into the document’s XMP and does not generate .tag sidecar-files. For any place in the online documentation that says “TAG File”, rewrite that in your head to “Stored in XMP as a really large binary field”.
Canto says the InDesign Plugin captures the following information for use in Cumulus:
- Document Text
- Font Names
- Image Height
- Image Width
- Number Of Pages
- Number Of Layers
- Preview/Thumbnail of the first page (InDesign version 2.0 or later)
- Preview/Thumbnail of all pages (InDesign version CS2 or later)
- Software
- Related Sub Assets (called ’Contained Assets’ in versions prior to Cumulus 7)
Further, Canto states the information is stored in the document’s XMP.
The Cumulus Plug-in for Adobe InDesign enables Cumulus to embed the metadata of an InDesign document into the XMP (EXtensible Metadata Platform) part of the document. The Cumulus InDesign Filter and InDesign AssetStore can make use of such metadata and capture information on InDesign documents when cataloged or previewed. The InDesign AssetStore requires such metadata to extract pages in order to provide separate records for these pages.
Going through captured information in no particular order
Let’s walk through the things Canto’s DocWatch plugin capturers and see what InDesign already writes to the XMP.
Software
XMP Basic Properties
xmp:CreatorTool
Page Information
XMP Basic Properties
xmp:PageInfo, is a RDF Seq element container with sub members for each page (xmpTPg:PageNumber) and stores a thumbnail (xmpGImg:image) for each in the XMP.
Font Names
XMP Paged-text Properties
xmp:TPg:Fonts, is a RDF bag container element with each sub-structure element members providing font information. This includes stFnt:fontFace, stFnt:fontFamily, stFnt:fontName, and stFnt:fontType to name a few.
Color Swatches
XMP Paged-text Properties
xmp:TPg:Colorants, is an RDF Sequence Container with sub-structured elements defining every swatch in the document including Name, Type and the individual CMYK Values
Placed Images
My favorite, the XMP Media Management Schema
xmpMM:Manifest, an RDF bag container with elements for every placed or embedded. Note: Don’t be confused with the xmpMM:Ingredients, these are not the droids you’re looking for.
The Manifest maintains the file path to the placed asset as a URL (stRef:lastURL) along with the asset’s effective resolution and width / height are captured too.
It also records the placed asset’s Instance ID (stRef:instanceID) and Document ID (stRef:documentID). These elements have a different name then the typical Document ID (xmpMM:DocumentID) and Instance ID (xmpMM:InstanceID) fields in the Media Management Schema. (Which, I’ll add, are standard catalog fields in Cumulus since version with 8.5.0 — You should really add them to your catalogs if you haven’t already.)
With the asset path and the MM DocID / Instance IDs there’s enough information to uniquely identify assets in the catalog and enable AXR to catalog items not in the catalog.
Document Text and Number of Layers
XMP isn’t gonna help here as this isn’t stored in XMP as far as I can tell.
I never understood what knowing the number of layers in an Indesign Document was gonna do for you, to be honest. I would imagine it would be much more helpful to know the name of the layers.
How to put the XMP to use?
Since InDesign writes all of this information into the XMP without any outside help, in order to make use of it, Canto should extend the InDesign and XMP filters in Cumulus so that they can natively parse the information to the required fields in the catalog. At that point the only thing missing would be document text and number of layers. Also, I don’t think the XMP notes what page a linked asset is on. So if that information were captured natively by Cumulus, it would at least tell you what assets are linked at the document level, but not page level.
The DocWatch Plugin may still be needed for now, but one thing is for sure: There’s a heck of a lot of information ripe for the parsing into Cumulus with no plugin required.
But what do you think? Leave your DAMaged comment below.
The post Can XMP Let Canto Ditch The Cumulus DocWatch Plugin for InDesign? appeared first on DAMagedWorkflow.