Jump to content


  • Posts

  • Joined

  • Last visited

  1. I'm pretty agnostic when it comes to what language Affinity should select for scripting. That said, I'd rather strongly prefer them to select a fully non-proprietary language. Swift is deeply tied to Apple's ecosystem, and Apple drives that standard. I'd be just as opposed to TypeScript, for the same reasons—they may pretend to be open-source, but they're subject to the whims of those proprietors, and their priorities are always going to favor what's good for the corporation over what's good for the community. After all, many of us really liked AppleScript, and what happened to that?
  2. I do empathize greatly. I've been investing some time in workarounds. One of my InDesign scripts, for example, was a barcode generator. Instead, I'm converting it to a shell script to generate an SVG image, and then I'll just place the image into a Publisher document . . . but it's definitely a substandard workaround. Not having scripting really makes it hard to shift entirely away from InDesign. But I'm also really tired of the increasing random Adobe is demanding just to have access to my documents. (Similarly, not supporting right-to-left text is a major bummer, since one of my projects involves Semitic languages.) I like that it does 90% of my work-a-day stuff, but that last 10% is presently pretty painful.
  3. Sal Sogohian (one of AppleScript's leading evangelists) had his position at Apple eliminated a few years ago, and as Apple has been generally withdrawing its support for AppleScript, I'd say the writing has been on the wall for a few years. JXA is a viable alternative, but Apple hasn't really been clear about what its future is. There doesn't seem to be much enthusiasm for OSA at Apple anymore. It's a real shame, because OSA was a brilliant accomplishment, and it made tying together various applications into a relatively easy, fun exercise. Apple's apparent lack of enthusiasm for AppleScript these days has been leaving a number of developers uncertain, and that in turn is reducing their enthusiasm for providing scripting support as well. Nobody wants to invest in a lot of effort for a product which could just evaporate—and that, in turn, might well prompt Apple to say, "hey, people are supporting this less, let's go ahead and drop it." Which is stupid, of course, but I can't pretend to comprehend the corporate politics at Apple. I never would have thought of gluing the RAM and the disk into hardware just to keep users from upgrading, for example, and alienating their customer base seems to be what Apple is into right now. Now, personally, I think Lua is a fine language for this purpose—as you say, it's designed for this sort of thing. I'm not crazy about EJCaMvAaScript. I certainly wouldn't mind being able to drop import affinity into a Python script, either. But I would like some solution at some point. Of course, this isn't the most urgent wish I have about the Affinity suite—but it's up there, certainly.
  4. First off, I don't think a Windows-only solution is sound. Secondly, if this is "user friendly" but Visual Basic isn't . . . wow. So far, while I work with Python a lot, and clearly don't mind the indentation-structure style of it, I'm resigned to using JavaScript/ECMAScript due to its popularity, or Lua due to its easy embedding. Whatever will work. I'd rather it not have to support an additional REST responder just to provide scripting, as that would slow things down considerably, and in the end be a waste of resources on extra, unnecessary steps. And for those who still wonder what people use scripting for, I use it for Creating barcodes directly in a document; Autoformatting and preprocessing of imported documents; Repetitive placement of elements; and other things as a project requires to save myself time and effort.
  5. Since InDesign came out (and for QuarkXPress before that, back to 1994), I used Perl to generate short AppleScript snippets that would then do the application control. That way, I had the best of both worlds: regexes and lots of libraries around, yet still could control the dang application. I'm really missing my barcode-generator scripts lately.
  6. As long as one can feed scripts into a shell-level program à la `osascript`, I don't really care what language Serif chooses for the purpose. Sure, it'd be nice to have an API one could call, but then, that would put a hard limitation on what languages you could use. As far as I'm concerned, I don't need to write entire programs in whatever language Serif uses; I just need to be able to create objects and have control over all the attributes I'd normally use the UI for. fde101: While I've gotten used to the indentation thing, it still bugs me a bit. I'm not sure Python reminds me of punchcards, though; indentation would have seemed wasteful, and made it much more difficult to shuffle the order of statements if you needed to. . . .
  7. Being able to automate InDesign was one of the main reasons I gravitated to it for so long; I was able to write scripts that would generate barcodes on the fly, populate label sheets from a database with full control over placement, all sorts of things. That said, Adobe's AppleScript support has always been half-hearted, and now Apple seems to be putting AppleScript in the let-it-die department. It's extremely disappointing. So while full AppleScript support would be nice, it might be considerably wiser if there were an independent scripting engine for Affinity Publisher (and Designer and Photo, to be honest). But it'd have to be able to take input from the Unix world (I routinely generate AppleScripts from Python or Perl and use `osascript` to run them, for example; I'd need a similar process for Affinity applications).
  • Create New...

Important Information

Please note there is currently a delay in replying to some post. See pinned thread in the Questions forum. These are the Terms of Use you will be asked to agree to if you join the forum. | Privacy Policy | Guidelines | We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.