The InDesign standard import filter for RTF or Word is imperfect. With Word and InDesign, the “file-centric” point of view makes the cloud somewhat difficult. A home-built XML authoring solution, for example, has no challenges related to asset management: it is quite easy to move to the cloud. Both InDesign and Word were built pre-cloud, thus the support for connectivity is less than ideal. Even if the import were perfect, or (the real-world success we sometimes see) the authors adhere to some guidelines, clever people need to be involved to map Word and InDesign styles. In contrast, the most successful authoring tools we’ve seen have been XML editors, or more recently HTML editors: in other words, tools with limits, unlike Microsoft Word. The Word document format has traditionally allowed users absolute free-form ability to do anything with a document. The reasons we were so dead set against this combination are: And we’ve happily avoided any strong commitments related to promising that the two will interoperate. Silicon Publishing gave up on Word/InDesign after about 12 years, so by 2012 our default answer had become “no we don’t support that, go find someone who thinks it will work” (there are always many who think it will…). We have spent literally years attempting to get the two to play nicely together, and have developed a nuanced understanding of the challenges associated with the default behavior of InDesign with respect to Word. One painful point of awareness is the very difficult and cumbersome historical interaction between Microsoft Word and Adobe InDesign. The Word/InDesign combination has tended to fail 
So you could say that I know way too much about InDesign.
I have been automating InDesign for 17 years, and I work with the people who created it in the first place, some of whom created PageMaker before that. Disrupting Editorial Workflows with Box, Word, and InDesign
0 kommentar(er)
