I've worked with data merge with .csv files and that is good, but the limit of one source document only solves one small part of this. I've looked into XML, but I can't get the raw data into an XML format without tons of manual effort.
I'd really suggest that you look at building a CSV file from a variety of sources. For instance, taking an Excel workbook that draws from multiple sheets and then export to a single sheet to CSV.
I really appreciate both of your input. The inCatalog software has real potential because we use an Access database to capture a lot of our information. The only problem might be the pricetag but I'm looking into it and hopefully I can at least offer the solution to my upper management. The cost of talented designers doing data entry rather than real design should pale in comparison to a couple of measly software licenses.
I'm pursuing the option of the .csv file in the interim. I have found a way to populate about 70% of my fields using a combination of 2 files. The few clicks to combine the two files is still faster than the data entry.
Again, thank you so much for taking the time to help me out!!!
First, let me ask: exactly how is the raw data currently stored?
There should be a way to get the data into XML format without a lot of manual effort. If your raw data has any structure whatever, a script and possibly XSLT may be your answer (you may need some help here). Alternatively, you might even consider exporting Excel spreadsheets to XML (Windows only). As you can tell, I favor XML. Adobe's support for XML in InDesign is super.
Alternatively, you might even consider exporting Excel spreadsheets to XML (Windows only). As you can tell, I favor XML. Adobe's support for XML in InDesign is super.
Not sure what planet you're on.
I'm going to have to strongly disagree.
Adobe's support for XML in InDesign is not super, and very limited. If you are writing custom scripts, then of course you can read in the XML and do whatever you want.
But if you'r enot, XML is not suported by Data Merge, which has a friendly UI. And the process of importing an XML document and autoflowing it setting up the tag mappings is very painful, and also very limited. If you can't express what you need with anchored objects, you are stuck.
That said, great if it works for you. And even better if you can help others use it effectively. But I recommend you check out some of the problems people have in the InDesign General forum. Most people have a lot of trouble.
I'm going to have to strongly disagree with your stong disagreement...
Shirley pointed out the likely need for some XSLT and script work. If you are willing to get your hands dirty with script driven XML import, it's probably the most efficient and flexible way to import large amounts of data into ID.
Shirley is the person who got me to look at the xml import capabilites a few years back. Before then, my opion was simlar to yours. Together, we did some stuff in catalog layout that would blow your mind.
Thanks, Bob, it's good to have a lively disagreement...if you have a moment would you check out Bug #2925372?
The original poster, jen2638, explained up front that she is "not a developer and I do not know scripting." Any solution that requires her to learn scripting is probably a non-starter, and similarly so for XSLT.
I would also say that because pretty much any use of InDesign's native XML import requires the use of XSLT, that tautologically makes it "not super." That is, XSLT is a tool to transform arbitrary XML into other arbitrary XML. Because InDesign's XML import is extremely rigid, the only way to get it to import most kinds of XML is to transform that XML (such as with XSLT).
But I agree. If you can write scripts and XSLT transformations (or other kinds of XML transformations), then using XML with InDesign is extremely powerful. Unfortunately that cuts out 95% of the population, and leaves much of the remaining 5% tearing their hair out.
It is far easier to do any kind of manipulation in Excel and export to CSV and then use Data Merge. (Or to use a purpose-built catalog plugin).
Those will work for this problem, and do so handily (at least, to the extent that I understand the problem).
It's definitely more powerful to do it in InDesign. But it's not friendly; it's not easy; it's not for non-developers; and, in my considered-but-nowhere-near-humble-opinion, it is nothing close to "super."
I guess some of this can be alleviated by good cookbooks, and I think there may be a few of them out there. But.
I love a good debate so I thought I would further clarify my original question. I too thought that XML would be a good solution but wasn't sure it fit my particular problem. What I am creating is a 4 page document that captures information from multiple sources. I create displays that are instore and for every display we create, we make a sell sheet that has all of the nitty-gritty information about the program. SO, I'm pulling product information from a customer supplied Excel document, pallet pattern information from a CAPE program, imagery from Photoshop, line drawings from Illustrator, and database information from Access. Traditionally we do all of this manually.
In the last 2 days I've figured out how to export information out of Access and CAPE then combine that information using a macros built in Excel. I'm able to save that new file out as a .csv which I import into InDesign thru Data Merge. About 40% of the tedious work I used to do is captured in this new step. The real driving force behind all of this, is creating a simple workflow that anyone can use. It will need to be easy to explain to others and implement.
My next steps have been to see if InDesign is even the tool we should be using!? The Access database that we use is a wealth of information and I'm wondering if adding even more information to that database and then developing an output from there would be the most efficient way to handle these sheets. Centralizing the information will also probably help alleviate the problem of changes coming through and then we have multiple items to update.
Anyways, hope that is a little more clarification and again, I appreciate your help!
I agree that it would be very nice to kind of normalize all of the disparate data merge and data import features. The problem is how to do that. If the ID team makes a couple of assumptions that would work nicely in one case, it'll be the opposite for a dozen others. That's the fundamental problem.
What I like about the XML import feature is that they gave us (developer type at least) the hooks we need to do serious layout magic. I can take virtually any blob of XML (including XHTML, even "old" html isn't well formed xml) and get a layour formatted to the character level, including anchored frames, image placement, tables, you name it.
It provides power users with development chops the ability to do anything. That's super. That it isn't nearly as powerful for a non-scripter does not lessen the "super-ness" of the solution in my eyes.
Back in the CS2 cycle someone posted a question - "Should I learn scripting?" While I won't write the same tome here, I will categorically state that anyone who is a power of InDesign or any scriptable Adobe CS product should consider learning at least the basics of scripting. Yes, it'll take a lot of effort, but it will be worth every bit of it.
Perhaps I am naive, but I don't see the fundamental blocker to harmonization. Could you expand?
Back in the CS2 cycle someone posted a question - "Should I learn scripting?" While I won't write the same tome here, I will categorically state that anyone who is a power [user] of InDesign or any scriptable Adobe CS product should consider learning at least the basics of scripting. Yes, it'll take a lot of effort, but it will be worth every bit of it.
Oh, I definitely agree. But on the other hand, it's not necessary to solve jeni2638's problem...
I think as developers and experienced users of the product, we also need to ask ourselves, What can we do to make scripting easier? Because it is clearly too hard for a lot of people. I don't have many answers for that one. And all too many people clam up when they hear the words "scripting," as I've been reminded of recently in another forum. Ah well...
I agree with John on all the XML issues. I use InDesign tags written from a FileMaker Pro database combined with Applescript. These systems can definitely be used by less technical personnel, and can even be quickly and easily modified by them as well.
Thanks for the clarification.
It's been awhile since I worked with Access so I can't remember if it will allow you to export as XML. Whether it can or can't, since you have Access, I believe your ideal solution would start there. I will need to poke my head back into Access to see what options you have for displaying the data. One option might be to use SharePoint and web services.
On the other hand, I am an InDesign devotee. One reason I like using InDesign (especially CS5.5) is the number of ways your page(s) can be displayed: eBook, web (HTML5), print, interactive PDF, Flash, etc. That gives you a lot of options for repurposing your data.
Don't let the "nay sayers" let you think that automation is difficult. And, yes, I did assume that since you posed your question to the Scripting forum you would be willing to look at a scripted solution. So the next question is: would you be housing your automated solution on a PC, a Mac, or both? If you are working with Access I would assume your solution would be on PC using either VisualBasic (.Net) or ExtendScript. Have you investigated either to date?