Peter Werner

That would have the following disadvantages: Bigger file size in both Publisher and the PDF (compared to pass through) Does not prevent rasterization happening twice (once inside Publisher and once by the printer's RIP) Will cause triple rasterization if the image is then resized in Publisher after it has already been rasterized to document resolution Does not prevent quality loss if the effective image resolution is very close to document resolution (say, a 300dpi image placed and resized so it ends up at 298 dpi) Breaks link to original image asset file Has to be re-done manually when file is replaced (eg. when client sends an updated version) Will not update if, for whatever reason, the document resolution is changed later The "Rasterize" command has no setting for Nearest Neighbour sampling, so rasterizing an image that requires Nearest Neighbour resampling would just cause it to go blurry one step earlier in the process If I hand such a document to someone else to work on, they would have to be aware of the situation or risk messing it up when making changes I think being able to choose per image whether the data is to be passed through without upsampling (better quality and smaller PDF file size for images like QR Codes, screenshots and pixel art as well as matching InDesign's behaviour) or upsampled to document resolution on export (which, for especially for photos will lead to slightly better quality results) would be a better solution. In my case, I worked around the issue for now by rasterizing all the photos to document resolution (which probably uses bilinear or bicubic sampling) and then setting the resampling in the PDF output settings to Nearest Neighbour. I was only dealing with a two-page document, but if I was working on say, a tech magazine with a mix of screenshots and photographs, that would be rather error-prone and cumbersome, to the point where frankly, I'd just do the project in InDesign instead and not worry about it.

When exporting to press-ready PDF from Publisher, the software always seems to re-rasterize images that have a resolution lower than the document resolution (or the resolution specified in the export dialog box). There currently seems to be no way to just pass the images to the PDF at the original resolution. There is no per-image control over how they are resampled/upsampled. I have a case here where a client has provided me a QR code as a PNG image, with a resolution that is much lower than my document resolution. Exporting with any other sampling than "Nearest Neighbour" will obviously result in an blurry QR code. Exporting with "Nearest Neighbour" will result in all other images potentially getting upsampled using Nearest Neighbour sampling. As a user, I actually may not want images like the QR code re-sampled at all. Re-sampling that image even in Nearest Neighbour will just generate pointless data and the RIP at the printer will re-sample once more at native print resolution, so depending on the image and how close it is to the document resolution, there could be some generation loss, artifacts or even moiré incurred. Ideally, we would be able to have a PDF that has images at their native resolution so they will get resampled only once during the RIP phase at the printer at its internal maximum physical output resolution. InDesign can output such a PDF and in fact will do so by default – it does not upsample images at all. Another use case where upsampling could be undesirable would be when creating PDFs with web graphics for client review. In that case, the client may actually want to inspect the image at a pixel level by zooming in in their PDF viewer. Just passing the images through to the PDF at original resolution would allow for this (though the user would have to use a PDF reader that does not do image filtering when zooming in for this of course). Just imagine someone places a 299 dpi image in a 300 dpi document and exports it to PDF. The resampling result will not look great. But if the native image is passed though, it may actually look great (depending on the zoom level in the PDF viewer). Another use case are screenshots in magazines. If these are resampled like photos, they can become blurry or exhibit ring artifacts when resampling with a filter like Lanczos. Of course one could just export the document with Nearest Neighbour filtering, but that would cause all photos in the magazine that are even slightly under document resolution to become Nearest Neighbour filtered as well. Don't get me wrong, upsampling to document resolution is actually a good idea in most cases as printers in my experience only ever do Nearest Neighbour filtering and you may gain quality. It might be useful to allow the user to control these settings at an object level. For instance, for the QR code in my example, an option not to upsample could be activated. Upsampling of images could be deactivated globally in the PDF export settings. Or, with upsampling activated, all regular photos in the document, except the QR codes and screenshots with upsampling off at object level, would be upsampled on export for slightly better quality.

That settings seems to be unrelated. In fact, I was able to reproduce the issue without creating a symbol, only grouping the text and the line and then applying a constraint to the text layer in the example I am attaching. The arrowheads disappear as soon as the constraint is applied to the text when the enclosing group is implicitly converted from a Group object to a Constraint Group object. Changing the arrowhead end position setting on the line does not remedy the clipping.

Here is how to reproduce: Add a line Add a stroke and extremely large arrowheads to it (eg. the Bar type at maximum size) Add an Art Text layer Mess with Constraints and create a symbol (Constraint Group) from both Now the arrowheads are not taken into account in the bounding box computation and appear clipped. Additionally, maximum size for the Bar arrowheads is capped at 500%, even when higher values are typed into the text input field. In certain instances, this can be too small. Same on both Mac and Windows.

I just ran into this as well and it is definitely an important feature. In my specific case, I'm working on prototypes for DVD boxes and the inlays are to be printed by a photo lab as regular 20cm x 30cm photo prints and then trimmed manually to the exact final size. What's even worse, the workaround I would normally use (going through a temporary PDF) is not an opting this time since there is a bug that prevents the live effects on the type from exporting to PDF correctly in this document. Having the option to include bleed on placed files is very useful whenever something is printed/prototyped on an office or photo printer to be trimmed manually – for me this often happens with prototypes, CD/DVD covers, postcards, small signs/labels etc.. InDesign's "Add Crop Marks.jsx" example script makes this really easy to set up.

I can't seem to find the link right now, but I recall Adobe Photoshop product manager John Nack posting about the possibility of a Linux version of Adobe Creative Suite (at the time) on his blog many years ago. He stated that the reason why Adobe didn't do a Linux port wasn't the size of the potential market for Linux versions at all. Their market research showed, however, that offering Linux versions would not get them a significant amount of revenue from new customers, it would instead only shift a large part of their existing customer base to a different operating system. Serif today is in a very different position – shifting a large part of Adobe's existing customer base to Linux sounds exactly the kind of thing they might be interested in.

Thanks, that's pretty cool, I must have totally missed that feature! Though this of course doesn't fix the problems when it comes to images that have been opened, pasted etc. as well as user created raster layers that have been transformed. But it's still a great improvement for many of the page layout-related use cases.

This is also an issue in Photo where you can non-destructively scale a raster layer. Since there is no "Reset Layer Transform" command other than "Rasterize", which kills your resolution, you may end up painting/cloning etc. on a layer that has vastly different resolution than the rest of your document. Being able to see the scale of a layer may be crucial information in that case. Or you may have opened a raster image, transformed it slightly for a quick test, and now when you create raster layers, they won't match up with the resolution of your base image so you want to reset that base layer to its original size to match up 1:1 with the document pixel grid without losing all your undo stack. I recently had the case where I was quickly throwing together a comp for a client and then had to do more retouching work to an image in the comp stage in context of the final design than I had anticipated. However, the image was transformed non-uniformly to fit a design and now I was required to move everything into a clean 1:1 retouch of that image, but there was no easy way to find the scale factors and/or reset them so I could transform everything back so I could do further work on the image in 1:1 resolution. The only solution I found was to select the base image with the transform tool where it displays the DPI and then work out the inverse scale factor, but that only works for non-uniform scale, not for rotations and the like. In other cases, where I can't just re-import the base image, I'm also worried that this will lead to rounding errors since DPI is only displayed rounded to whole numbers, so I might end up with an image that's half a pixel or so off from 1:1, which is definitely not ideal since then every single pixel will be resampled if I export to a file at my document resolution. And when it comes to Publisher or Designer: In some cases, being able to use exact percentages like 50% or sqrt(2) times the original size is also important, for instance if a design was created for A3 and has to be resized to A4. With the current implementation, I often find myself re-importing the original image in such cases to get it to a guaranteed 100% and then multiply the values accordingly. That's obviously not a good workflow. The only option would be to look up the exact target dimensions in mm for A4 or know them (which I admittedly do, but there are other more exotic formats). Same thing again when I then need to check that the size is correct, where otherwise I could just look at the scale factor in a panel and know it's accurate at first glance. I'd therefore vote for the Transform panel to show the exact layer transform of image and raster layers and also to allow the user to edit, copy and reset them. Moreover, being able to Copy&Paste transform and inverse transform would come in handy in many cases.

Just did a quick test, and It would seem you are correct. You may want to post this in the Affinity Photo bug reports section.

Your comment makes me suspect I'm actually dealing with a bug. I thought I had mixed something up, but checking an older proof PDF I sent out to the client, actually I think the numbering re-started with each story at first and then something caused it to suddenly continue across stories without me linking the text frames. Removing the "Restart Numbering Now" attribute from the first paragraph of the second story causes numbering to continue from the previous story. The text styles were all created from scratch. Maybe it's just a really obvious setting I am missing. I'm afraid I can't share the document in question publicly since it was created for a client, but I would be able to send a copy to the development team if necessary. Still, even if it's a bug, it would actually be really useful to have both options.

The "Restart Numbering" setting currently allows resetting the counter per-document, per paragraph sequence, or manually only. Sometimes it would be useful to have a numbering sequence specific to a text frame or sequence of linked text frames, i.e. per story. This small handy setting would eliminate the need to manually reset numbering at the start of each story and therefore also one source of potential errors since it's quite easy to forget.

I think it is worth mentioning that now with that Publisher has shipped with Studio Link enabled, you can just go to the Photo persona and use the Channels panel to check your separations. For some reason, page/spread borders disappear, but it's still a viable workaround. You need Affinity Photo installed in order for this to work.

Affinity currently lacks a lot of options required for full professional CJK typesetting, including things like Furigana and Warichu, dedicated composition/line break options etc., it's not just vertical text. My understanding is that they are going to get the basic features for roman typesetting done first to make Publisher and the rest of the Affinity range as usable as possible as a layout software for the roman languages and only then add features for full CJK and RTL language support a later point in time, which is completely understandable. At least IME for CJK languages seems to work fine now in Affinity 1.7 after being completely broken in earlier releases. That's already a good indication that this topic isn't ignored by the development team. I hope that one day we will have full CJK and RTL script support in Publisher. The last thing we could hope for is a messy and fragmented situation like with InDesign where you have to install multiple versions of InDesign in parallel, all of them developed by third party companies where you can only hope they don't mess each other's files up.

Running a web server for an API (or a web browser or Flash Player for dialog boxes) is exactly the same type of bloat that we all criticize Adobe for. They, too, are running at least one local node.js web server in the background even if none of their applications are active. You may have noticed it because it occasionally hangs, crashes or blocks system shutdown. Scripting isn't that performant in the first place, and running single command through a full-blown set of script interpreter, API in that scripting language wrapping and parsing the HTTP communication, HTTP server, system TCP/IP stack and what not is such a colossal waste of resources, not to mention it opens up the entire system to security vulnerabilities. If you really have a compelling case why you absolutely must automate Affinity applications over an HTTP API, you could easily implement the relevant parts of such an API yourself, either via a native C++ plugin, or even easier, with a Python script and Flask (a combination which by the way could probably replace InDesign Server with a desktop version of Publisher for quite a few use cases). This is by no means about what is trending, but what makes the moste sense in terms of providing an efficient, robust, powerful, extensible and future-proof scripting workflow. Besides, Python has been a staple of application scripting in the VFX industry (among others) for decades, and for a reason. This is by no means just a "trend" and there is no indication whatsoever that it will go away any time soon. As an established solution, there are a lot of companies invested in it so continued development is pretty much guaranteed for the foreseeable future. Lua is indeed great for smaller quick and easy scripts and easy to integrate in a C++ program, but not that suitable for more complex solutions (hello, Adobe Lightroom Classic mess) and its object-oriented language features are lacking compared to Python. C is not even a scripting language and does not scale too well, which is why it has been replaced by C++ as the language of choice for larger native software projects decades ago. It is also not true that the complexity of implementing one solution in different languages is always the same – it is true for very, very simple code, but as solutions become more complex, some languages, and their ecosystems, are significantly more powerful than others. As someone who has worked with both Python and VBScript I can tell you that there are some things that would be a nightmare to write in VBScript and a five minute exercise in Python. We don't need a hundred haphazardly integrated scripting solutions so everyone can avoid spending 30 minutes to learn a few basic new syntax rules, but one great scripting solution that is well thought-out, seamlessly integrated, simple and easy for basic tasks but powerful enough for the most complex requirements that arise, and interfaces well with the outside world (AppleScript/COM, network/HTTP APIs, third party libraries and applications, native code etc.).

I just came across a workflow stumbling block while working on letterheads with Publisher and delivering them as MS Word templates. There were multiple variations of the letterheads for different departments, which were created as different pages in Publisher in a single document based on common Master Pages My workflow was as following: Design everything in Publisher Create slices of header and footer for export to PDF Iterate on the design in Publisher until approved by client Place PDF graphics of header and footer in Word, recreate text that needs to be editable and text styles in Word, make color Palettes via PowerPoint (due to Microsoft logic) Last minute fixes: Make changes in Publisher, re-export the slices and replace the images in Word Deliver MS Word templates and color palette files To my knowledge, this is a pretty standard workflow for doing branding projects where MS Office templates are required. Since Publisher has no Export persona, I created my slices for my letter header and footer by opening the Publisher document inside Photo. Trouble is, Designer and Photo only support one page. When opening a document, they always just display Page 1. This can be circumvented by opening the file via the File menu in Publisher. In that case they will open the page that is currently active in Publisher. For me that meant that I had to go my target page in Publisher, use the menu to open that page in Photo, create my slices, save, close, re-open in Publisher, go to the next page, create my slices and so on. This is not only very cumbersome, but it also makes it really difficult to copy slices, settings or dimensions to keep them consistent across pages. Imagine that I find that I want my footer slice to be a bit larger after all because one version has some extra elements and I want them to be a consistent size – I'd have to close, re-open the document in Photo via Publisher for every single page and make my edits while remembering the dimensions to type in. The same applies to exporting the slices after a design change – when not using continuous export (haven't tested if that works from Publisher), this workflow also requires closing and re-opening the file for each page I want to re-export slices from. Imagine a change on a master page with slices on a 15 page document. That's a waste of time and unnecessarily frustrating. I guess the limit on page navigation was imposed onto Designer and Photo to prevent people from just downloading blank files with multiple pages and using those instead of buying Designer or Photo. My proposed solution would be to offer page navigation in the Export persona in both Designer and Photo. Then just always return to the default page 1 when going back to the main Photo or Vector persona if Publisher is not installed. Another possibility would be to take it further and globally enable page navigation in Photo and Designer if Publisher is installed, similar to the Vector and Photo personas in Publisher. The last option would be to add the Export persona to Publisher, but I'd say that's probably overkill.

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.

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!

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.