3 Replies Latest reply on Apr 20, 2011 7:51 PM by John Hawkinson

    Scripting CS5->CS3

    John Hawkinson Level 5

      I'm not sure what posessed me to read the latest thread about people complaining about the inability to downsave from CS5 to CS3 (over in the general forum), but then I had a goofy thought:

       

      What if someone wrote a script to iterate over a document and dump the whole thing in JSON (JavaScript Object Notation), or whatever, and then import it into CS3?

       

      (Originally I was thinking, I wonder why no one who is concerned about this doesn't sit down and write the horrible bear of an XSLT translation from IDML to INX? It certainly wouldn't be pleasant, and it would be a pain to get all the corner cases right, but it should be do-able...) I wondered if there wasn't a format other than IDML or INX that descrbed reasonably well the format of an InDesign document, and then I realized that the Scripting DOM is basically such a model. And even better, since you can ask InDesign to use an older version of the scripting DOM, you can ensure that you don't give CS3 anything that it shouldn't be able to evaluate.

       

      Now...I'm not going to write this tool, but it doesn't seem like it should be more than a few days of work for someone who is eager and interested (maybe none of those people have CS5? I suppose that's not an impediment though! No need for CS5 to write the code...). You just loop over all the properties of the document recursively ("for (i in app.activeDocument)...").

       

      There are probably a whole bunch of corner-cases that need special handling, And some decisions would have to be made about text...maybe the easiest answer with text would be to export it as InDesign Tagged Text and throw that representation in the file, rather than having to loop over individual characters and determine where overrides stopped and started.

       

      And you'd have to be very careful not to get caught in loops in the DOM. Anyhow, does anyone want to do this?

       

      Remember, only forty-two thousand nine-hundred-and-sixty non-unique page views:

      pageviews.png

       

      p.s.: (Please don't post about this crazy idea in the General forum...I wouldn't want anyone to get the wrong idea...)

        • 1. Re: Scripting CS5->CS3
          [Jongware] Most Valuable Participant

          For:

           

          1. If people complain it misses features (such as GREP styles), they can be invited to write a workaround themselves!

          2. JS is version independent. Well, largely, at least. If some properties in CS6 or '7 change names (again!), it should be relatively easy to update.

          3. JSON is a general format (isn't it? I'd have to look into it) so, finally, the writers of Scribus have something to look into.

           

          Against:

          1. You need the same ID version as the document, because otherwise you cannot open it.

          2. It Won't Ever Work, because (if you read that thread) people who "need" the downsave are expecting way too much.

           

          Neutral:

          1. Does this mean I can stop working on my experimental CSx binary-image-to-INX conversion?

          • 2. Re: Scripting CS5->CS3
            John Hawkinson Level 5

            Oh, [Jongware-22], so your witty foil spurs me on!

             

            > 2. JS is version independent. Well, largely, at least. If some

             

            > properties in CS6 or '7 change names (again!), it should be

            > relatively easy to update.

             

            No, no! (And next up is CS5.5). The beauty is that as long as you set app.scriptPreferences.version to 5.0 before you start parsing the document, then you don't have to wory about name changes. (Of course, that makes it impossible to gracefully handle CS4/CS5 features. But OK, sure, you can set it to 7.0 and handle the CS5 features and not worry about CS5.5/CS7 changing the names...)

             

            >  3. JSON is a general format (isn't it? I'd have to look into it)
            > so, finally, the writers of Scribus have something to look into.

             

            Kind of like saying, "Oh, your script writes its output in UTF-8? Great, no problem!" when it's really UTF-8 but when you look inside its XML. You know what else is XML inside? That's right, IDML! Not that the writers of Scribus couldn't look at IDML. It's 100% documented. [OK, maybe 95%]

             

            > Against:

             

            > 1. You need the same ID version as the document, because otherwise
            > you cannot open it.

             

            Noooo! The key is you give the script to the CS5 user who wants to downsave for CS3.

             

            > 1. Does this mean I can stop working on my experimental CSx
            > binary-image-to-INX conversion?

             

            Wait...are you the reason all these people are reporting corrupt INDD documents? Oh, Jongware!

            • 3. Re: Scripting CS5->CS3
              John Hawkinson Level 5

              I wrote:

               

              I wondered if there wasn't a format other than IDML or INX that descrbed reasonably well the format of an InDesign document, and then I realized that the Scripting DOM is basically such a model. And even better, since you can ask InDesign to use an older version of the scripting DOM, you can ensure that you don't give CS3 anything that it shouldn't be able to evaluate.

              Apparently I was missing a great irony. It turns out that actually, INX and IDML use the Scripting DOM as their model. To quote from the CS2 INX docs (I figured going back in time was useful):

               

              INX is an XML-based format used to serialize and deserialize the InDesign scripting DOM. This format is most useful with the Save Backwards feature of InDesign, which allows you to use an earlier version of InDesign to open a document that was created in a later version of InDesign. InCopy and GoLive also use the INX format. Each of these usages has a different set of valid elements and attributes; this document addresses only the elements used in the Save Backwards feature. However, concepts introduced here also apply to other situations.

               

              So, my idea isn't really new at all. (Worse, I probably read that section of the IDML/INX documentation and just forgot about it).

              It probably also implies that an easier approach might be to write a converter from IDML to JavaScript, since it solves the "What to serialize?" question first.