From my point of view, if you feel confident with xml import into Indesign, I won't seek further and will stick with it.
However, duplicating a layer for localizing purposes might not be a good idea. If you duplicate layers with tagged frames, ypu will add nodes in your xml structure which will lead to a big mess or at least something you have to plan in the xml you are preparing for Indesign.
So this duplicating technique may be not suitable to xml workflow. My advice would be to keep a generic template and flows localized XMLs into documents based on that template.
If you are searching for more smoothness, you may have a look at some DAM solutions but they can be expensive. Or maybe you can hire some fellows here used with Indesign and databases communications.
Anyway, for now, cheapest and quickest is to master your xml workflow. And regarding of this forum topic, all you can have is a script that could open a new document based on the template, flows a localized xml file into it and then let you go over for fixes. At last I wrote a script that duplicates automatically layers based on an array of languages.
But as I said, I don't think it's a good idea to gather XML & duplicated layers.
Hope it helps,
I've had so much trouble with XML documents recently, that I am hesitant to recommend InDesign XML for anything but simple documents...
Well, I think XML with Indesign is very powerful but it's true it's very straight and has some learning curve.
However, I do think it's a great tool if you master it, especially when used with XSLT. So it's more xml going to you than you going to xml. I like this and do all the time.
But in the end, XML workflow will still looks like a tough cop saying "Hey boy ! Step out the line". No way to cheat, you have to respect the rules. Speaking about rules, it may be time to deal with xml rules, a chapter of the scripting guide I never found time to read yet. Is anyone using them and what's the main point ?
Harbs, what kind of problem did you face with XML, curious?
VERY bad performance problems.
InDesign freezing when trying to execute a Find / Change.
This was in documents with longer stories...
I do trust you with closed eyes on performance issues.
For F/C, I read here that if you try to change some tagged text within Indesign, it crashes it. The problem was due to xml tags that are considered as text elements by Indesign. I got a similar issue trying to get a tag content trough xmlElements.storyOffset.contents.
<tag>TAG</tag> --> XMLElements.storyOffsett.contents.length //5 (xml tag character + tag + xml tag character).
So maybe your F/C issue is due to that ?
But more globally, as we say in France, "On n'apprend pas aux vieux singes à faire des grimaces", which means I won't learn to someone as skilled as you basic things, but is a flowed document really the place for F/C operations ? There is two ways to consider the problem, either the document has to stay dynamic and so the changes have to be done at source (Xml file or better the xml export engine [DB, php...] ) or the document has no longer need to be dynamic, so you can get rid of tagging and then do regular F/C operations.
But As you play with dynamic contents, your F/C operations could be swipped by a xml update, that's why I don't think it's good to modify any contents by hand in a dynamic document.
No it was more basic than that.
doc.findText() and doc.findGrep() froze InDesign.
I've had this on more than one occasion. I had to rewrite a script for a client to get around this problem, and the resulting script took many hours to run instead of the minute or two I would have expected because of the performance issues...
One of the document was so problematic that just trying to untag the XML froze InDesign...
I understand now. It's true that when a large amount of xml datas is loaded, Indesign is just so slow.
I am more and more tempted to use the xml source file and dig into it as either a xml object or file content as string if I am looking as sth special. But of course it doesn't make sense if you have to do sth in the document based on text recognition.
Mmmmm what to do, we have to find a way (which doesn't include yell at adobe guys )
My preferred method for dealing with XML is to process the XML myself in a script (usually a piece of cake!) and have the script place everything...
The only one occasion i was asked to automate the flowing by scripting, I just dropped the root in the first frame. But we set everything at hand first so the xml import was fine. Finally they wanted to demo all the process in one click, so I wrote a desktop snippet that prompted for the xml source file, open the template, loaded the xml and that was it.
More recently, I had to deal with tagged documents to do documents operation (moving tagged frames essentially) but documents wasn't big enough to let me see the performance issues you pointed out.
Nice talking anyway ;-),
>Well, I think XML with Indesign is very powerful but it's true it's very straight and has some learning curve.
>However, I do think it's a great tool if you master it, especially when used with XSLT. So it's more xml going to you than you going to xml. I like this and do >all the time.
I second with Loic. XML in ID is powerful but still there is hell lot scope of improvements. I was/am avid user of few other pagination platforms prior to ID and you can do magic if one is well aware of XML features XPATH, XSLT etc with them. Foe instance, ID still have limitation in terms of using XPATH in XML rules .
This is, of course a scripting forum!
While I do agree that XML is a powerful tool. It pales to what can be done with scripting. E4X allows you to do anything you like -- and very easily. No need to mess with XPATH and the likes!
I was just pointing out that the built in XML is not without its problems...
I also meant ID perform in scripting with XML too. We do lot of XML jobs and for not so long document (chapters, articles) I do not see a significant difference whether its XML or non-XML document (though I should take a note of this and check it myself in terms of performance).
But yes, we really struggle with Index generation/web pdf for whole book in XML. InDesign simply stumped in terms of efficiency. I remember working on Index for a particular book (500) and it took almost 6 hours to get it done and for few other cases ID got hanged :-( . Those were the terrible days.
I have tested few other free tools (indexbrutal, Sonar Bookends InDex Pro etc), which do the magic in few seconds. Definitely something wrong either in our script or performance of ID with XML.
Anyways just my $cent thoughts.
I use FileMaker Pro, InDesign, and Applescript to write and place InDesign tags in this scenario. Filemaker is an actual relational database that can also access sql sources, is networkable, cross-platform, easy to use, unicode-based, and is easily Applescriptable. It can also display formatted text before even placing in InDesign, which also makes it useful for pre-proofing. Since it is a visual database, it is also very useful for indexing, dummying, and providing dashboard-style control interfaces to all your files. I also find InDesign tags far more capable and efficient than XML.