macOS InDesign challenge!

[superscape]

Hi,

I run up against this particular dead end every few years but never quite solve it. I wonder if anyone has any clever ideas?

I have an InDesign file and I want to know what plates will be printed. That's to say, if exported the file as a PDF (for print) and looked in Output Preview, I'd want to know which separations actually have anything on them. That last bit is the problem.

I've tried reading the Colorants field in the XMP using exiftool, but it doesn't seem to contain CMYK inks other than, confusingly, black.

I've tried using AppleScript to get the documents inks, but if there is any CMYK color (e.g. just cyan) in the document then it always reports cyan, magenta, yellow and black - even if there's nothing on those separations.

So, does anyone have a better idea? I'd ideally like to do it by parsing the InDesign file in Obj-C, without opening the document. But if I have to open it in InDesign and read it in AppleScript then so be it.

I've attached a sample InDesign and PDF file. I'd want to get the result:

Cyan
Magenta
Test Swatch

...for this file.


I'll be very grateful for any ideas anyone may have! I'm stuck!

s.






For the record, my previous solution involved outputting postscript then poking around in it's contents. It worked but actually generating the postscript took forever with big documents.

 

[chown33]

After just a bit of googling for the INDD file format, I came across the IDML file format.

IDML is an XML markup format. Adobe provides documentation for it here:
https://www.adobe.com/content/dam/Adobe/en/devnet/indesign/cs55-docs/IDML/idml-specification.pdf

Chapter 8 says:

When you export a document as IDML, InDesign creates a Zip archive containing multiple XML files. These files use IDML markup to represent the significant parts of the InDesign document.

We split the content of the InDesign document into separate files so that you can work on specific parts of the document—the stories containing the text in the document, for example—without disturbing other document content, such as colors or imported graphics. This compartmentalization makes it easier for automated processes to work on the parts of a document in parallel. It also makes it easier for you to store and re-use fragments of InDesign documents.​

So I'd start this challenge by making an IDML export and peeking at the XML files therein.

There are lots of tools for manipulating XML. There might even be some that are specific to IDML or its component files.

Even if you end up using Obj-C and its XML parsing classes (NSXMLParser), that's still going to be a lot simpler than trying to reverse-engineer an INDD file.

I did peek in the posted INDD file using HexFiend (google it), and it looks sufficiently complex and non-obviously structured that reverse-engineering could take a very long time. Especially when compared to IDML, where the entire content is right there, as a documented XML file set.

 

[superscape]

Thanks for your thoughts!

Yeah, I'd thought about reverse engineering the file format but after a quick look it looked pretty impenetrable.

If I take the IDML route then I'll have to open the file with a script and export it, which I'm trying to avoid having to do. I'm rapidly coming to the conclusion that I'm going to have to do that though.

If you look in the design_map.xml file (see attached expanded idml) then you can get a list of swatch colors in the document, but they're not necessarily used by any objects. Looks like you need to look at the spread xml files, object by object, and cross reference them to the design_map.xml file. Nasty, but doable.

An alternative might be to export each page as an eps.

More things to try after Easter...

Have a good one!

 

[chown33]

Thanks for your thoughts!

Yeah, I'd thought about reverse engineering the file format but after a quick look it looked pretty impenetrable.

If I take the IDML route then I'll have to open the file with a script and export it, which I'm trying to avoid having to do. I'm rapidly coming to the conclusion that I'm going to have to do that though.

If you look in the design_map.xml file (see attached expanded idml) then you can get a list of swatch colors in the document, but they're not necessarily used by any objects. Looks like you need to look at the spread xml files, object by object, and cross reference them to the design_map.xml file. Nasty, but doable.

An alternative might be to export each page as an eps.

More things to try after Easter...

Have a good one!

Without having looked at the IDML yet, the thing that occurred to me was that a very simple parser may be all that's needed.

You don't have to render any of the objects on any of the pages. All you have to do is take note of their presence, and their color. So the presence of any text, line, rectangle, ellipse, whatever on the page is handled the same. Simply note that something exists and what its color is.

 

[superscape]

Without having looked at the IDML yet, the thing that occurred to me was that a very simple parser may be all that's needed.

Yeah, you'd hope so...

I suspect that colours solely in linked images might not show up. One way to find out, I guess! I'll have a try and see what happens.

Thanks for your input so far!

 

[chown33]

I suspect that colours solely in linked images might not show up. One way to find out, I guess! I'll have a try and see what happens.

I'm not sure what a "linked image" is. I'm guessing it's something like a #include in C, where one file incorporates another file by reference.

If there's a file incorporated by reference, and you can't parse its content for colors, you could treat its color as "Unknown". That is, make a specific color called "Unknown". If something is drawn on a page, but you can't parse what color it is, then the "Unknown" color will be listed in the output of colors on the page.

If "Unknown" is too confusing, invent a color name, or use an invented name, like "grue", "bleen", or "vorpal". Here's a whole list of fictional color names:
https://en.wikipedia.org/wiki/List_of_fictional_colors

 

[superscape]

I'm not sure what a "linked image" is. I'm guessing it's something like a #include in C, where one file incorporates another file by reference.

Hi,

Yeah, sort of. It's more like the html way of doing things. When you're working on the document in InDesign you can place an image from your hard drive. It's not incorporated into the document, but a link to it is held in the InDesign document.

Linked images have been the deal breaker. I've ended up printing the document as postscript and parsing that. It seems to be the only way of getting reliable information from the linked images. Its irritating because it means I need to open the file to script the creation of the postscript, plus it can take a while to save with hefty InDesign files.

It seems to be CMYK linked images that cause the problems and necessitate this approach. I may optimise my approach by only using this clunky method if I detect linked CMYK images...

Thanks for your thoughts so far. Handy to have someone to bounce ideas off!

 

[cruisin]

In Illustrator I can print to Acrobat Pro, tweak a setting, and it will make a pdf of all the separations. Assuming InDesign can print to Acrobat, it should work the same way.

Or you can do a preview:

• Choose Window > Output > Separations Preview.

• For View, choose Separations.

https://helpx.adobe.com/indesign/using/preparing-print-separations.html

A linked image is essentially a reference so that someone else can work on the image separately and the image updates everywhere it is used. You should be able to open the file and change it to be an included file.

 

[superscape]

In Illustrator I can print to Acrobat Pro, tweak a setting, and it will make a pdf of all the separations. Assuming InDesign can print to Acrobat, it should work the same way.

Hi,

Thanks for your thoughts.

That's essentially what I'm having to do in my script, although instead of going InDesign->Postscript->PDF, I go InDesign -> Postscript then have a nosey in the postscript file. At least I get what I need.

The annoyance is that I need to open InDesign to do that saving as postscript. That means that a user of the script needs InDesign installed and also has to wait while the file is opened and postscript saved. Not the end of the world, but it can be time consuming, especially with big files.

With an Illustrator file I can just look at the XMP metadata using exiftool without having to open the file. InDesign's metadata (Colorants field) seems unreliable, or at any rate doesn't give me the separations I know will be needed. I was hoping there was some other way of getting the separation names without opening the file, but it seems not.

So I'm stuck with the postscript method. Ah well, at least it works!

 

[cruisin]

Illustrator files are essentially pdf, so it isn't really a fair comparison. If you save an ai file as pdf using the default settings, you can then open the pdf in Illustrator and continue editing.