Peter Werner

This one is probably more for the photo team, but since I've found this in Publisher and haven't had a chance to test the new Photo beta yet I'm posting this here in case it's Publisher specific. Option+dragging a slider in the Levels dialog in the RGB setting always shows a completely black image for me when dragging the black point and a white image for the white point instead of accurately showing the usual clipping preview image with a threshold effect. In LAB mode, Option+dragging the Luminosity slider shows a black image with some of the chrominance information on top. Dragging the slider does not change the clipping preview image at all. Double-clicking a slider to reset it also doesn't work, but I'm not sure if that feature was ever there in the past. Moreover, there seems to be no way to use precise 8-bit/16-bit or floating point values in the numeric input fields, only a percentage. This might be required when images need to comply to a precise standard such as broadcast limits, old-school screen printing processes that don't work with ICC profiles, or when performing operations that need to be reversed exactly by a layer on top (say, when trying to preserve detail when using a third-party 3D LUT that has an excessive linear contrast operation built in) and so on.

@Chris_K: Oh I see, that explains it – thanks! Got confused by how this works in InDesign. In that case, is there a way to fit a frame to contents? And why does double clicking the handles in text frames fit those to the text, at least vertically? I'm not getting a square frame. I have to say in it's current form, it's a bit confusing with this behave differently between text and picture frames. @PaulEC: Try clicking the "Properties" button in the tool options bar with the Select Tool or one of the Picture Frame tools selected and selecting one of the scaling options. If this doesn't work as expected, it's probably a bug. Works fine for me.

Oh, I see – my apologies, I must have somehow missed that post earlier when I did a forum search on the topic. For quick sketches or design mockups, a simple Shift+Tab is still much faster, but I can live with that in exchange for being able to right-anchor tab stops. The only real issue I see is that once an Adobe InCopy/Quark CopyDesk type editorial workflow is implemented, this is something that will have to be done on the design side, rather than being available to the copy editor by default. Also, a unique right alignment tab character is useful for use in a "nested styles" scenario where everything after such a character can be assigned a specific character style automatically (like in the aforementioned end-of-story marker example where the character can then automatically be formatted with a special font or color).

I don't really think Japanese is officially supported yet. Japanese input (IME) is still severely broken both in the latest Publisher Beta (at least on Mac) and the app store build of Designer/Photo. I guess full support for CJK typesetting would require significant development resources and know-how, which is why Adobe outsources the CJK and middle east versions to third party companies, to the detriment of everybody who has to put up with that mess of different versions and file compatibility. But warichuu in particular is a very useful feature for roman text as well. One great use case is the famous stacked name effect in the billing block on movie posters. Vertical text is sometimes used in western typography, too, so who knows, maybe we'll see these features before full CJK support.

This is a really handy special space character that exists in InDesign. It's a great way for instance to place "End of Story" characters or generally align things to the left and right in the same line of text really quickly without messing with tab stops. Unlike tab stops, it also adapts to the width of the text frame and can thus be used regardless of the column width without having to maintain a whole set of paragraph styles.

Testing with an image dragged into a picture frame object dragged from the Stock panel into a rectangular Picture Frame object. Double-clicking the horizontal and vertical resize handles will snap the Picture Frame bounding box to incorrect positions outside or inside the picture instead of fitting it to its edge, irrespective of the scaling option chosen for the Picture Frame object. Also, double-clicking corner handles currently does not fit the frame to its contents, only horizontal and vertical handles offer that behaviour – I don't really see a reason why fitting a frame to its contents should require two separate actions for cases where the user wants to do this on both axes.

You're welcome!

You can double click each of the resize handles (horizontal and vertical ones, not the corner ones for some reason) of a text frame to fit its bounds to its contents on that particular axis. I think it is supposed to work for picture frames as well, but it seems broken/buggy at the moment. The frame snaps to incorrect places (tested with an image dragged in from the Stock panel).

Except it would be cool if that grid also allowed for subdivisions in the other direction, i.e. not just columns like InDesign, but also rows.

Inkscape is by no means representative of what Python scripting looks like when it is well integrated. Inkscape's Python seems like an extremely crude API that requires you to mess with some SVG DOM, write a bunch of superfluous boilerplate and integrate a bunch of third party libraries to do anything useful. That's by no means the fault of the programming language. I wouldn't want to use that, either. See this example of what a basic script for Illustrator in Python (using COM due to lack of native Python bindings) looks like. Not very different from JavaScript, really. Nothing of the sort would be necessary with a proper embedded Python interpreter. You could of course mess with third party packages if you wanted to. As an example, I'll attach a simple graphic that I generated with Python (using the interpreter that came pre-installed with OS X). The script can render to PNG using PIL (as attached) or write an SVG for use in Designer or Illustrator. Took me a lot less time than doing something like that as a script compared to doing it by hand. I can use any gradient for colors, use an image texture to modulate the size, birth or position randomization of the particles, color the connection lines, and much more. The result can be manipulated in Designer as if it was created directly with its drawing tools. @MikeW: Nothing can be done with a programming language per se except do maths and data manipulation. Scripting always means "extending" the language with an object model. User interfaces (whether on desktop or mobile) are no different than documents, layers, text frames and cat objects in that respect. Some scripting APIs just skip the UI part (or, cough, rely on Flash or HTML), which obviously leads to a rather underwhelming user experience.

Regarding integration with other software: You can access Apple Script interfaces of other applications from Python scripts with Apple's Scripting Bridge. You could certainly talk to FileMaker from within a Python script that way. An Apple Script interface that's basically "tell application Affinity to run the following python code" would also be conceivable for the other way round, though the coding experience that way admittedly wouldn't be great, so some basic Apple Events and COM support (as well as command line switches!) would definitely be useful. Adobe is running a dual-platform strategy, too, with COM/Apple Events in addition to their own ExtendScript. With Python, another great opportunity would be to also allow installed Affinity apps to be used as a scripting library so that it can be used from standalone Python scripts. Autodesk Maya and Toxik as well as DaVinci Resolve offer that option for example. This would allow you to write a script that runs outside Affinity, but generates, uses and manipulates Affinity files using the Affinity engine. That would allow you to solve problems via scripting without the user having to manually open Affinity apps and click around in them. That way you could, say, make a Python script for Resolve that applies an Affinity Photo macro to each frame of a clip for example, or one that automatically loads news graphics and lower thirds from Designer files and allows you to update the text objects contained inside from within Resolve, but have the resulting graphic rendered by Affinity with any effects and complex clipping you might have applied to the text. Or automatically generate catalogs based on your product database and a template, send them to an external designer who is using Affinity Publisher and when they send the finished file, automatically fill in the most recent prices for each product with a second script, all without anybody except the designer having to click around in Publisher. All you'd need would be a license of Designer installed on that machine. Or combine this with something like Flask and you even have a viable alternative to Adobe's insanely expensive InDesign Server that would require only minimal effort on Serif's part because it would just be the regular scripting API packaged into a Python module. One thing we'll have to consider, though, is that Affinity products run in Apple's store sandbox on the Mac and on iOS. This may impose restrictions in terms of what's possible in terms of cross-application communication. Also, the discontinuation of Automator doesn't exactly inspire confidence in the future of the AppleScript platform – I hope I'm wrong, but I have a hunch that AppleScript may not have the brightest of futures.

Having done my fair share of scripting in InDesign myself, I can assure you that JavaScript and the way it is integrated is everything but a smooth experience. You get to choose between half-hearted integration where scripts need to be run from a list on a panel where it runs once and then it's over, and a second scripting engine that keeps the script running, which is necessary for creating your own menu items that can respond to user input at any time. The latter leads to all sorts of craziness and bugs and quirks, especially when the script is run twice (which might happen randomly if you try to load it automatically with InDesign), both engines make it difficult to use shared code between scripts in separate files. Not to mention that at this complexity level, the shortcomings of JavaScript as a language are just painfully apparent (not to mention Adobe's developer tools – ExtendScript Toolkit is an abomination). I found myself cursing more than saving time and resorted to writing only scripts that I absolutely needed and without any of the user friendliness required to share them with other users. I've also written a vector-based particle system in Python that generates SVG files that can be opened in Affinity Designer – everything about that experience was smooth, efficient, and enjoyable, unlike fighting with ExtendScript. The level of control required for writing extensions for a professional graphics or multimedia software differs from small automation tasks that Apple Script is intended for. There is no doubt that one can solve complex tasks in AppleScript of course, but it's by no means well suited nor intended for that type of thing. Remember, we're not just looking for a way to automate quick tasks, otherwise we'd be discussing an improved macro feature. We want a solution that is easy, quick and simple with a low learning curve for simple automation tasks, but scales well for complex tasks that border on a plugin, satisfying the demands of experienced developers and giving the end users a well-integrated experience. If you look at professional film and visual effects software like Maya, Blender, DaVinci Resolve, Modo, TheFoundry Nuke – they all use Python, and their scripting capabilities are way beyond what JavaScript and AppleScript would usually be used for. With Maya, the learning curve for creating, say, a basic script that creates a bunch of objects in your scene is extremely low (for someone without programming experience, I'd say even easier than JavaScript). But if you want to and have the skill, you can also achieve the same level of integration that a C++ plugin would have, or integrate the software with your effects pipeline for the next StarWars or Pixar movie. As much as we would all love this, there is just no way that porting existing InDesign scripts will be that easy. Any developer will tell you that you can't just copy and paste code from one platform to another. The internal object models of Affinity and InDesign are different enough that you'll have to rewrite most of the code anyway. Trying to make the Affinity scripting API as similar to InDesign's as possible would severely limit its usefulness. There is no point in Serif copying Adobe's mistakes for the sake of compatibility that won't be achievable anyway. Not to mention that the Affinity API needs to cover Photo and Designer as well, and InDesign, Illustrator and Photoshop all have very different ExtendScript object models, so which one should the Affinity be modeled after? I would encourage you to take just a few minutes to skim over an introductory Python tutorial – the simplicity is kind of addictive, I think you'll like it!

The one but last setting on the General page in System Preferences is indeed set to "None", but all other native Cocoa apps including Preview, Numbers, Text Edit etc. are showing an MRU list just fine. Also, I tried to test this by changing that setting to something else like 5 items – when I return to System Preferences, the setting is back at "None". System version is OS X 10.11.6.

I assigned a custom shortcut (Option + Shift + P) to Text > Insert Filler Text. When using that shortcut, the option key is interpreted as a modifier key as if I had Option+clicked the respective menu item. That means that instead of pseudo-latin, I'm confronted with a passage of Alice in Wonderland when I use the keyboard shortcut. Since I hadn't been aware that that this command accepted a modifier key so it took some time for me to figure out why the filler text differed between using the menu command and the keyboard shortcut. The Layout persona doesn't seem to include the boolean operations for shapes, so I couldn't check if that command exhibits the same behaviour. I think this could throw some users off. At least some information when assigning a shortcut like that would be useful I think.

I agree that the View menu would be a much more logical place for the Personae menu items. As far as removing them goes, I really don't see the point – my assumption would be that anybody concerned with working quickly would be using the keyboard shortcut (Ctrl+N/Cmd+N) anyway. Besides, by the same logic, all menu items that are not used as frequently as others would have to be removed from the menu, that's clearly not feasible. Menus are an inherently finicky part of user interfaces, especially on Windows where you can't just throw your mouse curser up to the top of the screen and know you're in the menu area like on OS X.