Having images stored in CMS is a great benefit that web-to-print provides for it keeps images centralized. However, image originals are big and tend to add up quickly so hosting disk space may become an issue. We came up with following options
1) Only web version of image and the name of original file are stored in CMS. The original itself is stored offline in some predefined directory. While generating export XML to be used by InDesign, CMS uses the name of original image and inDesign gets it from its offline location.
2) Both web version and original version of image are uploaded to CMS. After the export XML gets generated, a person manually ftp to the server, moves the original files from the web server offline to predefined location, thus saving space and making them available for InDesign.
Which of these approaches looks more promising (less risky, etc) to you? Or, may be some other way?
Your advice is much appreciated.
Comments
A limitation of the first
A limitation of the first approach is that you'll be asking people to submit their images in two places: offline and in Drupal. Nobody likes double work. And the second approach requires manual work as well. With storage becoming ever cheaper, are you sure the space savings are that important? Having your original images both online and offline gives you flexibility and a backup - which is worth a lot.
The solution I'm considering (as I'm building a photo archive myself) is sort of like your second idea, but automated: all uploads are handled in Drupal (mostly jpegs from digital camera's), but a module also creates a 300dpi cmyk tiff file that is uploaded to a local server so that (a) Drupal still has your originals and (b) those huge tiff files that you only need for print use anyway don't crowd your webspace, but are available on your local server for use in InDesign or any other programme.
Of course, no two problems are the same, these are just some thoughts :-)
How we are doing it at Sun Journal
We are just rolling out a solution for our newspapers now. The original images are managed by Drupal.
We have a SAN that is mounted on the webserver. The 'files' directory is located there. That drive is also mounted on the local paginator machines.
I wrote a script for Indesign that talks to Drupal and generates the xml on the fly so there is no need to export the xml manually from drupal. (the script makes an xmlrpc call directly from Indesign, this way there is no actual xml file). The script then automatically generates the xml structure from the returned results directly in Indesign. It also automatically specifies the appropriate path for the photos based on the mounted 'files' drive.
xml-rpc
Sounds nifty. Do you only use that to get to your images or also to get additional content (byline and attribution) from Drupal?
xml-rpc
I'm using the xml-rpc call from Indesign to retrieve all the story information (headline, subhead, byline, photos, graphics, sidebar info, etc).
The indesign script then programmatically creates the xml structure.
It's all done using Indesign's scriptable interface using Javascript (or ExtendScript as they call it).
So when a paginator opens an Indesign template they can click an "Import Stories" button within Indesign and have all the stories for that particular publication pulled in.
Did you find the InDesign
Did you find the InDesign DOM as quirky and the documentation as lacking as me? :-)
One advantage to working with XML files is that InDesign alerts you if a newer version is available, and you can choose to refresh all the imported content. Have you been able to replicate that functionality? And the obvious question: will your scripts remain proprietary?
Anyway, kudos!
Quirky DOM
I haven't had too many problems with the DOM. But yeah, the lack of examples out there made it slow going.
I did consider the advantages of working from a file, with regard to alerting you if newer versions are available.
However, I am centrally hosting the administrative sites for 7 newspapers at various locations.
So they would have to export the xml files to their local environments which wouldn't get updated anyway.
Well, I could have setup some sort of automated ftp but I wanted to keep it simple. This way, a paginator can work from home or anywhere with requirements other than indesign and an internet connection. They don't even need to have access to the cms.
Right now the paginators can just click a "check for updates" button in Indesign which will then grab any updates and flag them as so in the xml structure.
I'll be cleaning up the script over the next two weeks. After that I'll post it up somewhere (though you're welcome to it sooner if you want it).
Very interested to learn more about your methods!
Hi akempler!
We are very interested to learn more about your methods ... for our own process over here.
What version of ID would you most recommend? Would your script work with InDesign CS or would it need CS3? (I have CS3 but the rest of the company has CS. We would upgrade the others if necessary, when it comes to the crunch:)
Also, what versions of Drupal would your script work best with? We are currently at 4.6 but DO want to go to 6.3 in the very near future.
We can in the meantime start playing around with a test site ... we are eager to experiment with using your script.
Currently we have everything on a central server (XServe & Raid) that is mounted on all the editorial staff's computers, as well as the paginators.
Is your approach "web first" where stories first get written directly to the web and then pulled into InDesign?
Currently we write everything into text files, those text files are then:
1. Placed into InDesign and the pages are laid out for our print publication and
2. Handed over to the web guru who copies the info and places it on the web.
All of our images live on the server at high res. These are:
1. Placed into the InDesign layout for our print pub and
2. Repurposed for the web and placed with the stories on the website.
Thanks a lot & best regards:)
Christine
Re: Quirky DOM
Hi akempler,
Did you happen to post your script somewhere for sharing? Thank you...
Eric
Ah, our xml files are
Ah, our xml files are available on a share on the webserver that the designers can connect to via VPN. That's not zero-config, but at the time I just didn't feel like diving into indesign scripting to get things done :-)
I'm quite curious to take a look at your approach, but I'll just wait a few weeks.