Skip navigation
Josh000000 30 posts
Nov 1, 2011
Currently Being Moderated

Other scripting languages legal?

Feb 28, 2012 4:23 PM

Tags: #indesign #legal #scripting #language #ruby

According to this post on stack overflow, it isn't legal to script InDesign using alternate scripting languages like ruby.

 

http://stackoverflow.com/a/7401629/1177119

 

Does anyone know the documentation that he is referring to? It seems to me like it should be legal otherwise no one would be able to develop plugins for InDesign.

 
Replies
  • John Hawkinson
    5,572 posts
    Jun 25, 2009
    Currently Being Moderated
    Feb 28, 2012 4:35 PM   in reply to Josh000000

    He simply means it is illegal to reverse engineer the InDesign file format and then write a program using that knowledge to edit InDesign files. He is not referring to scripting.

     

    I believe that is close to true, but not precisely accurate.

     

    The InDesign EULA prohibits reverse engineering the InDesign software, see section 4.4:

    4. Restrictions and Requirements
    ...

    4.4 No Reverse Engineering. You will not reverse engineer, decompile, disassemble, or otherwise attempt to discover the source code of the Software.

     

    But I do not think that reverse engineering the  violates that restriction, as long as the  is not reverse engineered as part of that process.

     

    Functionally it hardly matters because reverse engineering the file format to that degree is a herculean task, and there are better ways. As he goes on to note.

     
    |
    Mark as:
  • John Hawkinson
    5,572 posts
    Jun 25, 2009
    Currently Being Moderated
    Feb 29, 2012 11:37 AM   in reply to John Hawkinson

    Whoops. I must have replied via email and part of my markup got tossed, making the sentence unreadable:

     

    But I do not think that reverse engineering the  violates that restriction, as long as the  is not reverse engineered as part of that process.

    That should have read: But I do not think that reverse enginering the file format violates that restriction, as long as the Software is not reverse engineered as part of that process.

     

    "Oops."

     

    Makes sense, I was hoping to use apple's scripting bridge to plug into InDesign. I don't think that would be considered "reverse engineering" InDesign although you do access the objective c classes directly... at least with MacRuby

    Scripting Bridge uses the Apple Events model, that's definitely not reverse engineering.

     

    Personally, while I think you can certainly do this, you are going to find that it will be more frustrating than if you use Javascript (or even AppleScript), because you will not be able to leverage the experience of others and will spend a lot of time translating other people's examples into your language of choice. Also, there are occasional rough edges in the Applescript with respect to typing and incomplete dictionaries and whatnot, and working around this will only make your life more difficult.

     

    But either way, please let us know how it works out!

     
    |
    Mark as:
  • John Hawkinson
    5,572 posts
    Jun 25, 2009
    Currently Being Moderated
    Mar 2, 2012 12:00 AM   in reply to Josh000000

    Josh000000 wrote:

    The most annoying thing though is that it takes a long... time for ScriptingBridge to load InDesign's scripting definition. I haven't figured out how to fix this one besides preloading it possibly on start up of InDesign before running the script.

    Well, in AppleScript, a compiled version of the script is saved that caches the numeric equivalents so the scripting definition doesn't need to be saved. I'm not sure how you solve this in scripting bridge.

     
    |
    Mark as:
  • Currently Being Moderated
    Mar 4, 2012 12:51 PM   in reply to Josh000000

    The object model viewer of ESTK uses an XML file, from which you could extract your values if your language has XML support.

    The file will be something like "~/Library/Preferences/ExtendScript Toolkit/3.0/omv$indesign-6.0$6.0.xml" (for CS4)

    Watch out along this xpath: //classdef[@enumeration="true"]//property//value

     

    Of course that file is also pretty big so you'll increase your speed impact that way.

     

    Dirk

     
    |
    Mark as:
  • Currently Being Moderated
    Mar 5, 2012 3:18 AM   in reply to Dirk Becker

    All known enumerations are listed in my version of that same Help file. See http://www.jongware.com/idjshelp.html for the downloadable files (I prefer the CHM versions, on both Mac and Windows, since they are easily searchable); http://jongware.mit.edu/idcsjs5.5/index_Enum%20Suite.html for the on-line version, courtesy of the gentleman with the green avatar.

     
    |
    Mark as:
  • John Hawkinson
    5,572 posts
    Jun 25, 2009
    Currently Being Moderated
    Mar 14, 2012 9:40 PM   in reply to Josh000000

    For clarity, all the work is Jongware's. I just host the exploded zip files on a web site with available bandwidth.

     
    |
    Mark as:
  • Currently Being Moderated
    Mar 15, 2012 2:35 AM   in reply to John Hawkinson

    @Jongware & John – just two questions you don't need to answer:

     

    Is a chm-version of the CS5.5 documentation in the works?
    Maybe a souped-up one representing DPS (Adobe Digital Publishing Suite) functionality?

     

    Ok. For DPS scripting I can get along with ESTK's OMV (Object Model Viewer), but if you are accustomed to the chm- or html-versions already published, it's like a slap in the face to return to the OMV.

     

    Uwe

     
    |
    Mark as:
  • Currently Being Moderated
    Mar 15, 2012 4:43 AM   in reply to Laubender

    Uwe, so is there not a CS5.5 specific CHM yet? (Checking...) Gosh. I must have slapped the HTML together real fast, cursing Adobe for bringing it out so fast after CS5. I still have to integrate Basic Javascript and ScriptUI in CS5 as well, because I rarerly script "for" CS5 but when I do I find I'm missing those!

     

    Is there anything special about scripting for DPS for it to have an OMV section of its own? That's news to me. I'll look into it, see if I can hunt down the XML base help file for it.

     

    (By the way, don't expect anything on Very Short Notice. I've been quite busy with other stuff that's a real energy drain on every single neuron. As it is, I might as well wait for CS6 'cause then I'll have to start over again. (Let a man have his dreams; perhaps CS6 finally has an OMV that works fine for me.))

     
    |
    Mark as:
  • Currently Being Moderated
    Mar 15, 2012 6:27 AM   in reply to [Jongware]

    @Jongware – there is nothing really special to DPS from a scripting point.

    The one "problem" is, that if you have not installed the plug-ins, which is a separate installation apart from the usual InDesign CS5 or CS5.5 range of features, you have no access to its DOM objects and therefore they will not appear in your documentation.

     

    The other "problem" with DPS is, that every two months or so a new version of DPS will come out apart from the usual publishing cycle of CS (right now we are on v19.1 of DPS) and objects, methods and properties available by scripting may or may not vary from version to version (how to handle this I don't know; how would you separate these objects from the usual stuff available? Compare one set of objects with the other and go for a seperate documentation for DPS only?)

     

    Uwe

     
    |
    Mark as:
  • John Hawkinson
    5,572 posts
    Jun 25, 2009
    Currently Being Moderated
    Mar 15, 2012 7:01 AM   in reply to [Jongware]

    (By the way, don't expect anything on Very Short Notice. I've been quite busy with other stuff that's a real energy drain on every single neuron. As it is, I might as well wait for CS6 'cause then I'll have to start over again.

    It sounds like there are too many manual steps in the generation of this HTML and CHM! How can we make it more automated, Jongware, so it is just a single click? Maybe I could put up an upload CGI script so people with goofy third-party plugins like DPS could upload their omv$indesign*.xml files and get back a canned package?

    Let me know :)

    [ for "hack value," we could write this automation in InDesign. From a web server perspective that would be horrible, then we'd need an InDesign Server license. ]

     

    (Let a man have his dreams; perhaps CS6 finally has an OMV that works fine for me.))

    You realize that what might be your dream is to a certain extent our nightmare? Even a perfect OMV wouldn't be web-linkable or CHM-searchable, and then maybe if you were so happy with your new souper-douper OMV so you didn't produce the other variants? "Oh noes!"

     
    |
    Mark as:
  • Currently Being Moderated
    Mar 15, 2012 12:03 PM   in reply to John Hawkinson

    John, the size of the XSLT to produce either a set of CHM-compilable files (including the TOC and Index!) *or* the exploded HTML is rapidly approaching that of ID's XML file :-) At present, it accepts the original omg$%#!!.xml file that ID (and its not-very-related Creative Suite relatives) as input and spits out all that's required -- up to and including a color-coded CSS. So that's not a problem.

     

    But I found the OMV Help writers sometimes take some, uh, "liberties" -- for example, they forget to include linked stuff as proper links (the ScriptUi OMV XML is rife with it), or they suddenly use other tags than the one I have been interpreting (the Base Classes XML), or they introduce entire new levels of complexity (AI's XML does not use the "regular" Class/Enum distinction, or so its seems). So there is an amount of tinkering required to make the existing XSLT work with "new" files.

     

    In addition, I tried to plainly add both Base and ScriptUI files to the main ID one; only to find out it suddenly contains lots of duplicate OBJECTS! "Button", "Group", "Window" and the like. I manually prepended "SUI" to the ones I find, but it's a tedious job. The more for the slight coding oddities I encounter along the way.

     

    On the positive side: I *am* aware of the fact that the "real" OMV is smart enough to rebuild itself when it detects changes in the Object Model. That's definitely not a trick I can duplicate. Hence it carries the warning (somewhere) that if you cannot find a class or method, you should check against the OMV's built-in function.

    Good for the DPS script users, as they will always have access to the Very Latest, not so good for an externally constructed file as mine is.

     
    |
    Mark as:
  • John Hawkinson
    5,572 posts
    Jun 25, 2009
    Currently Being Moderated
    Mar 15, 2012 12:38 PM   in reply to [Jongware]

    John, the size of the XSLT to produce either a set of CHM-compilable files (including the TOC and Index!) *or* the exploded HTML is rapidly approaching that of ID's XML file :-) At present, it accepts the original omg$%#!!.xml file that ID (and its not-very-related Creative Suite relatives) as input and spits out all that's required -- up to and including a color-coded CSS. So that's not a problem.

    Given that the omv*xml files are only a few megabytes, that's no problem. I'd be OK with gigabytes.

    If the XSLT is that huge it sounds like maybe you could use some help with it?

    But really, what's the problem?

     

    But I found the OMV Help writers sometimes take some, uh, "liberties" -- for example, they forget to include linked stuff as proper links (the ScriptUi OMV XML is rife with it), or they suddenly use other tags than the one I have been interpreting (the Base Classes XML), or they introduce entire new levels of complexity (AI's XML does not use the "regular" Class/Enum distinction, or so its seems). So there is an amount of tinkering required to make the existing XSLT work with "new" files.

    Yeah, you need an automated fixup pass. Duh!

     

    . I manually prepended "SUI" to the ones I find, but it's a tedious job.

    No more tedium! Automate!

     
    |
    Mark as:

More Like This

  • Retrieving data ...

Bookmarked By (0)

Answers + Points = Status

  • 10 points awarded for Correct Answers
  • 5 points awarded for Helpful Answers
  • 10,000+ points
  • 1,001-10,000 points
  • 501-1,000 points
  • 5-500 points