kimtorch
-
Posts
49 -
Joined
-
Last visited
Posts posted by kimtorch
-
-
1 hour ago, Andy05 said:
Maybe the crop tool needs some improvements, but I can't see how your example takes that much longer in Affinity. Enter the width and just ignore the height. You can move the crop wherever you want on the image and edit the height by using the appropriate handles for it. Doesn't really take longer than drawing your crop onto the image.
You can't ignore the height, you must enter a value if you want to use centimetres. The ONLY way you can have unconstrained crop is using pixels. It's annoying given all other measurements (rulers, transform etc) are all in Cms. It makes no sense to use multiple units when the user has chosen the one they want.
-
Affinity Photo cropping is doing my head in. Here's what we currently do dozens of times a day in Photoshop. Open an image, set a width and a resolution in the crop tool. Leave the height blank. Draw our unconstrained crop box. Double click in the middle to crop. A few seconds, max.
For the life of me, in Affinity Photo I can't find a way to replicate this process:
1) crop to a width only (seems you have to also specify a height)
2) have Unconstrained crop appear in Centimetres despite have Centimetres select as units in Transform panel. If I type 15cm into the Custom Ratio fields it simply reverts it to Pixels.
I can't believe at version 1.9.2 the crop tool - one of the true fundamentals of photo editing - is so pathetic. I'll happily apologise if I've missed something and someone can explain how to do these things. This should be simple!
-
2 hours ago, michalmph said:
To me, the most important aspect of scripting is not about having fancy new design features. It's about reducing the time the humans need to waste on inhumane tasks. Identifying the error-prone, manual, repetitive and labour-intensive tasks, and automating them, so no one has to do them anymore, forever - and instead focus on the more enjoyable and fulfilling parts of desktop publishing and graphical design.
This is the key - Affinity are working on the tools and forgetting about the result (getting the job done). Here's an analogy. I have a really nice Dewalt cordless screwdriver. It's a fantastic tool I enjoy using but if I had to screw in 5000 screws it wouldn't matter how good the tool is the job becomes slow, boring and uneconomical. This is why companies use robotics in manufacturing - it's essentially mechanical scripting.
No matter how pretty and elegant the interface, I don't want to have to have to create 100, 500, 1000 PDFs manually. Or manually place images, create boxes, format text and export to our RIPS. We do these tasks thousands of times a week (literally). This is why Affinity Publisher is just pipe dream for us right now.
- angelhdz12, chessboard and michalmph
-
3
-
It's been almost three years since my original post and not a word on progress or even possibilities from Affinity. Clearly automation isn't high on their priority list.
I'd imagine if there'd been internal discussion at Affinity they would have reached out (maybe privately) to some of the people here who have vast knowledge and experience scripting publishing apps.
Implementation and beta testing for a large scripting environment would be a huge undertaking and if it hasn't started now I have little faith it will be with us inside a couple of years. Sadly, I have little faith it's EVER going to happen.
Looking back on what I said early on, I'd be happy to have ANYTHING - even the bare basics - just as evidence they actually might be doing something...
-
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.
- BennyD, Meztli and angelhdz12
-
1
-
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)?
-
7 hours ago, Bryce said:
So here is what I am getting with the different options:
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.
-
-
3 minutes ago, fde101 said:
Affinity products are not Adobe or Quark products. There is no reason they need to make the same suboptimal choices their competitors are making.
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.
I'm not but note that at least on the Mac this should technically be possible because there are ways to hook Python, Perl and other languages into the underlying OSA framework - even if nothing else they could use the standard command line osascript tool.
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.
Even if the Affinity team steps up their game and makes the programs fully scriptable via AppleScript, there is no guarantee that the specific data model would be even remotely similar to the one used by InDesign
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.
That is not what is happening here. There have been numerous suggestions but they are all for well-established scripting languages, no one here is re-inventing the wheel. I do agree that AppleScript should be supported on the Mac, as I find it rather irritating when Mac apps don't support it (it should almost be required to be considered a "good citizen" on the Mac environment).
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.
JavaScript is another story, as is a kludge of a language to begin with and not a good choice for general application scripting. The only reason it is a "good choice" for web sites is that it is the only one that web browsers universally support. Even people creating web apps are starting to create them in other languages then run translators to convert those languages to JavaScript before deploying them... given that JavaScript was originally designed for use on web sites, that is a fairly good hint that it's not even a good language for what it was designed for, much less for something as different as this.
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.
-
9 hours ago, fde101 said:
most of the other suggestions here are for languages which are frequently hammered into that role but are not designed for it
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.
-
13 minutes ago, beige said:
vote for Python. Just great for string processing, regexes, path management and all other stuff that goes with image and text processing.
So how do you handle these things now in your existing InDesign scripted workflow?
-
9 hours ago, Seneca said:
Not necessarily true.
A number of inDesign scripters asked for Python on inDesign scripting forum. See the post by no other than Peter Karel somewhere in this forum.
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.
-
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?
-
1 hour ago, Zoot said:
Or just good old Python like every other piece of software in the world that isn't InDesign, lol.
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.
-
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.
-
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.
-
On 9/1/2018 at 12:00 AM, Seneca said:
I don't think that a half-harted approach to scripting will do.
We need deep scripting integration in Publisher. While I applaud kimtorch for his basic approach in his earlier post I don't think this will do.
There are number of people here that would be extremely disappointed with that.
Do it properly from the start. We should be able to automate everything. InDesign is a good example here.
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.
-
51 minutes ago, Peter Werner said:
That being said, I'm still hoping for Python instead of or at least in addition to JavaScript. Having written extensions for different software with both languages, I found that writing extensions in Python was always quick, easy, efficient and even fun, and there are tons of great third party libraries available, whereas any kind of JavaScript extensions, particularly for Adobe programs, have consistently been a royal pain.
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.
-
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 layersMost 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.
-
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.
-
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).
-
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.
-
Are there any plans to add scripting support?
I notice there is no Applescript library at all but am interested to know if there are plans to add Applescript or perhaps Javascript support. Virtually everything we do as far as creating PDFs, packaging, placing images and text, formatting, proofing, sending pages to print etc is done via script.
Tagged text goes hand-in-hand with scripting so I think this needs to also be supported.
crop tool problem
in Pre-V2 Archive of Affinity on Desktop Questions (macOS and Windows)
Posted
The problem is exactly what you just described - I can't have an unconstrained crop in centimetres. An unconstrained crop should still be able to have one dimension - as Photoshop has had since I started using it circa 1992.
AP doesn't allow this as it REQUIRES both parameters as detailed in my original post. I get you don't see it as an issue, that doesn't mean it's not an issue for others. It's a basic function which should be available if it expects to compete with PS.