Jump to content

kimtorch

Members
  • Content count

    16
  • Joined

  • Last visited

About kimtorch

  • Rank
    Newbie

Recent Profile Visitors

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

  1. 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.
  2. kimtorch

    Scripting

    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.
  3. kimtorch

    Scripting

    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.
  4. kimtorch

    Scripting

    So how do you handle these things now in your existing InDesign scripted workflow?
  5. kimtorch

    Scripting

    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.
  6. kimtorch

    Scripting

    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?
  7. kimtorch

    Scripting

    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.
  8. kimtorch

    Scripting

    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.
  9. 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.
  10. kimtorch

    Scripting

    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.
  11. kimtorch

    Scripting

    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.
  12. kimtorch

    Scripting

    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.
  13. I'd like to congratulate the developers for what they've done. I'm sure they've spent many a long night trying to mould AP into a product suitable for public testing. You've done a great job getting to where it is now and I hope the sudden rush of bugs and features requests are seen as users desperately trying to help rather than an unscalable mountain of work. Enjoy what you've been able to achieve - it's probably better than I was expecting for a first release - well done.
  14. kimtorch

    Tagged text?

    I hope so. Tagged text is incredibly useful and in many cases can substitute for many formatting scripting commands (style from the tagged text rather than setting text and then applying formats via script).
  15. Is this where you'd like Bug reports? I can reliably crash Publisher by selecting some text and then going to 'Expand' in the text menu - immediate crash with no error other than standard system 'the app has quit'. Happy to provide a crash log if you let me know where to send it.
×