Jump to content


  • Content Count

  • Joined

  • Last visited

About kimtorch

  • Rank

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. I've given up on Affinity. I started this thread over two years ago with great hope of replacing CC but there's been zero input from Affinity regarding progress on scripting which gives me little confidence anything will be coming. It seems the primary market for Publisher, Designer etc is smaller agencies who might not benefit greatly from scripting. I continue to tweak our InDesign scripts and software every few weeks and I just can't see how we could survive doing everything manually. I'm retiring from the trade next year so it's not going to be relevant to me anyway, but it's a shame it doesn't seem to be on the radar of important features.
  2. We produce several hundred pages each week of the same size with the same columns (newspaper pages). I've made a custom sized page and created a preset but I can't see any way of applying column guides to the preset. Am I missing something or can you not have column guides on a custom page (preset)?
  3. Not much to add except "me too". It's actually the first thing I've tried on Affinity Photo and I had to go straight back to Photoshop bcause I was getting almost identical results to you with Invert.
  4. I'm curious why they have this behaviour. We will often drag an image to the pasteboard before placing it properly. It seems totally counter-intuitive and I can't think of any other application that does this.
  5. It's not about making sub-optimal choices, it's about competing with the duopoly market leaders. It's no point having a 'unique' product that no-one wants to move to. This is what is frustrating to me. People espouse their personal favourites but no-one has yet demonstrated it in action (and I've already asked a couple of times in this discussion). Saying it's technically possible and making it both user friendly and efficient are entirely different things. Do you really think the average designer who fools around with a few scripts wants to be digging into CLI tools and 'underlying frameworks'? Both javascript and AS are relatively accessible for non programmers. At the moment, any discussion beyond Applescript and Javascript are mythical because no-one's actually doing it. Absolutely, but it would be naive to be building a competitor, which uses almost identical functionalities and building blocks, without considering the possibility of a similar DOM. I certainly hope this is not the first time they are considering the scripting implementation because if it is I'll likely be retired before we see it. It is actually. People are dreaming of ways to port their favourite language to work. Bridges, conduits, patches, extensions - they are classic examples of 'hammering it to fit' as someone mentioned earlier. I think many underestimate the inter-application operability that comes with AS. IF Affinity simply want automation of their own apps - without inter-app capability - they would be far better off just building a macro engine with a simple language. As they would have absolute control it would be quicker to implement and very complete. I absolutely agree with Applescript being part of a 'good citizen' Mac app. This is exactly the benefit of javascript. Multi platform with a large existing user base where it's used for related workflows. With the proliferation of web/digital integration, being able to use the same language for both - regardless of its syntactical quirks or omissions - would be a huge advantage. We have both web designers and Indesign operators sitting within arm's length of each other. Some do both.
  6. This is the most frustrating part of this discussion for me. The established languages for scripting InDesign and Quark are javascript and Applescript yet people are talking python, perl, C# or any other language they can think of. For all those suggesting python, how many of you are currently scripting InDesign with it? How many of you are interacting between apps like Filemaker and InDesign with python? Show me some working code and convince me. Affinity need to take users away from Adobe and making well established users learn a new language isn't going to help. We use over one hundred scripts here in a production environment. The longest Applescript is now over 1200 lines long. Modifying these scripts slightly wouldn't be an issue but rewriting the entire process in a new language just wouldn't be worth it. This is why I think it's crucial to adopt a similar object model to InDesign. It's great to think outside the box and dream of a new way to script, but there are millions who are already doing it successfully with javascript and Applescript and I'd humbly suggest they're the ones with the best idea of the way forward rather than people who aren't currently doing it. The current 'professionals' are the people Affinity have to win over, unless their target market is going to be solely consumers and backyarders.
  7. So how do you handle these things now in your existing InDesign scripted workflow?
  8. I haven't had a lot to say here because - to be frank - we don't need Affinity Designer. I WANT to change to Designer, but we already run successfully with the Adobe products and can continue to do so. The point I'm trying to make is that Affinity need to persuade or entice existing ID scripters with a compelling reason to move. They're not going to do that by trashing everything they've invested in either Applescript or Javascript with ID. The other issue that people keep ignoring is inter-application scripting. I don't just want to script Affinity Designer - I want to talk to Filemaker, Mail, Capture One, Acrobat and any number of other scriptable applications. Just targeting your own app would b very shortsighted and really misses the point of what can be achieved with lateral thinking.
  9. Just because Adobe's implementation isn't great doesn't mean Affinity's won't be. This aside, the major thing that you're missing is the integration with other applications. For example, I can't use Python to access a Filemaker database and script that into AP (or ID). I can't easily tap into my Mail program or Capture One or Excel or my own apps. People tend to forget the cross application integration that Applescript allows. I'm not for a moment suggesting Applescript or Javascript (with which I have little experience) are perfect, but they *are* extremely practical and Applescript in particular allows far greater inter-application functionality than any other available language. This is something Affinity should consider - are they just going to script AP or are they going to allow functionality to be greatly extended with access to non-Affinity apps?
  10. lol indeed. Having used Macs since day one I'm not aware of any standard Mac app which supports python but literally thousands that support Applescript. I'm all for open discussion but I'd prefer it be realistic. As much as my preference is Applescript, I think the most practical would be javascript due to its cross platform nature. I believe either of these would be openly accepted by current InDesign scripters who already script in these languages. I believe Python would turn existing ID users off - it certainly would me as I don't want to learn yet another language. If Affinity do the syntax and object model right, a lot of existing ID code could even be reusable/transportable which would be a HUGE consideration to switching.
  11. Whilst I applaud 'thinking outside the square', I'm not sure whether this is applicable. Firstly, it appears to be Mac only which eliminates at least 50% of the potential audience. Second, it appears to still require the existance of Apple Events built into the appication (in which case it's already Applescriptable) and third, I'm not sure the sort of people who have the option to write apple or java scripts will be interested in writing them in Obj C. I'm not familiar with scripting bridges at all so might be completely wrong in my assessments but from briefly reading the supplied links this is what I was left with. The key point I came out with is that the application has to be inherently scriptable before the bridging can exist. But once again, maybe I have that wrong.
  12. I don't have a horse in this race but the company I work for has been printing/publishing for 98 years and stopped using picas around 25 years ago when we dropped hot metal. I'm not going to suggest AP shouldn't have 'traditional' publishing measures, just that I believe much of the printing/publishing world has moved on.
  13. I'm not suggesting for a moment they shouldn't do a full and complete library of scripting functions. I'd be disappointed if it was JUST basics. I'm simply saying a good starting point would be the fundamental functions I detailed above. I would, however be extremely disappointed if scripting was delayed because they were trying to build every obscure and little used functionality in before releasing it. Get some basic functions out early and build upon that. Getting AP to the level of a genuine ID competitor will take years but I certainly don't want to wait that long for scripting support. We are simply no chance of changing from ID to AP without scripting - it would cripple our workflow. If we could get the fundamentals I stated above we would be half a chance to move quite early.
  14. I have no experience with python but have extensive experience with Applescript and PHP scripting. I've written numerous standalone apps in BASIC plus we wrap a lot of scripts in BASIC apps so we can pipe data directly from mysql to Applescript. My preference would be Applescript but I understand they're not going to want to support two scripting methods for multiple platforms. My second choice would be BASIC but I think javascript makes the most sense. The best thing about choosing JS is that anyone with existing ID scripts will have a head start when looking to port them to AP. Our longest Applescript is 738 lines and I wouldn't look forward to rewriting it into a new language with a new object model. I would be happy to have a concise, targeted set of logical commands rather than trying to support every single feature of the app but making the scripting unnecessarily complex.
  15. I'd like to offer some brief suggestions of what I believe would be a good start for scripting support. Clearly both InDesign and Quark have extensive scripting libraries but I think with some basic fundamentals a lot can be achieved. I believe the below would allow us to do about 80% of what we need. Ability to create objects (text frame, image frames and rules) of specific sizes at specific co-ordinates using a list of properties. (set myFrame to create frame (x-coord, y-coord, width, height, colour, tint, border, name, columns, inset etc, etc) Ability to populate frames with text or images with ability to fit or scale as required (set story 1 of frame 1 to "myText.txt") Ability to assign styles to objects (set paragraph style of text frame 1 to "Heading 1") Ability to create new pages with properties for size, bleed, numbering, spreads etc Ability to reference selections (set border of selected frame to 0 - set style of selection to "Bold") Ability to export using defined PDF Presets (export to myPath with PDF Preset "My Preset") Ability to address (or loop through) all objects on a pages (set background of all text frames on selected page to "Transparent") Ability to test for missing or broken links to assets Ability to create colour swatches, character or paragraph styles, PDF Presets Ability to create and manipulate layers Most importantly, the ability to query for any property related to an object (set myProperties to properties of my selection -> list of all available properties) This is incredibly useful for writing and debugging.
  • Create New...

Important Information

Please note the Annual Company Closure section in the Terms of Use. 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.