Peter Werner

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.

Works fine for me, I only had "Allow JPEG Compression" deactivated on the PDF/X-3 preset, otherwise my settings should be identical to yours. The screenshot shows the PDF re-imported into Affinity and as you can see it consists of a raster image with a clipping path. I made the file by simply creating the S as an ArtText object and dragged the placed image inside in the layers panel. If you are seeing different results, I'd say it is definitely a bug and not a design limitation of the Affinity backend or the PDF library.

Not 100% sure about early versions of InDesign, but I at least don't remember running into any issues in that respect. But you may well be correct since around InDesign 1.5 and shortly thereafter 2.0.X when I started using the software, printers here always still asked for native files and not PDF so back then it wouldn't have been something I would have to worry about. That being said, if I create a shape in any of the Affinity apps, import an image and drag it inside to clip it, it exports to PDF as an image clipped inside a path (tested with the PDF/X-3 setting). The edges are sharp and not pixelated no matter how much I zoom in (tested in Apple Preview and by placing the PDF into an InDesign document, can't try Acrobat Pro right now because the updater corrupted my installation once again). Re-Importing the PDF into Affinity retains that path as a clipping mask for the raster image. Ergo the Affinity backend as well as the PDF library it is using (apparently PDFlib + PDI) are perfectly capable of outputting bitmaps with clipping paths, they are just not doing so in the case of the effects in the original poster's case for whatever reason. One possible explanation is that the partially transparent raster image on the left that is overlapping the lines somehow triggers rasterization of the objects below if any effects are applied, which to me looks like a bug.

I cannot possibly imagine that the Serif team would choose a PDF library that cannot clip a pre-rendered raster image into a path, that's pretty much as basic as it gets.

My apologies, I must have used different wording when searching for existing threads. Thanks for the replies!

I have a document with a few two-column text frames. On the left pages of two double spreads, the column resizing double arrow mouse cursor appears in the wrong spot, either two the left or to the right of the column gutter. On the right pages of the spreads, the hotspot is centered on the right column gutter guide (rather than the center of the gutter as one would expect). The feature can still be used since the offset remains constant if the user clicks and drags. One just has to find the right spot inside the text where the phantom handle appears. In that area, clicking to place the text caret is not possible since the column resize behaviour "steals" the mouse events. I have not tested if this is related to that particular document or not, but just in case, I have made a copy of the file where I encountered the bug that I can provide staff with if the issue cannot be reproduced otherwise.

These effects should still export as raster images clipped inside of the corresponding paths and not raster images only, so there is clearly something wrong here beyond just the resolution of the effects. Whether this is by design or a bug I cannot say.

I can assign F1 through F16 for paragraph styles, but pressing the corresponding key with a text cursor in a text frame has no effect. Assigning other shortcuts, say, Ctrl+Y, works as expected. Tested with German keyboard layout on English language setting of Publisher, USB keyboard connected to MacBook. OS is 10.11.6 (El Capitan). Curiously, pressing any F-keys hides the transform controls and frame/column outlines temporarily until the mouse pointer is moved. If this has to do with certain F-keys being taken over by OS shortcuts like launching Dashboard etc., I would expect Publisher to check for that and display a corresponding warning when assigning the shortcut.

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.

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.

Agreed, masks are still quite quirky. I have to admit that as much as I love the software, I was quite surprised back when Photo went from Beta to Release without addressing these. The Dodge/Burn tools seem to do nothing (or rather, happily operates on the blank RGB data, leaving Alpha alone), the brush tool ignores blend modes, adding adjustments with a mask selected doesn't add them to the mask automatically and requires dragging them into the right place manually and selecting Alpha from the drop-down manually (both things take extra clicks and are almost impossible to discover for a new user/Photoshop convert without research), while some filters work because they affect both RGB and Alpha (eg. Motion Blur), others simply seemingly do nothing since there is no RGB data to operate on instead of treating Alpha like RGB like in Photoshop, layers/adjustments nested into Mask layers sometimes seem to not be displayed in the layers panel (might be a display limit for nesting depth), and even though there can be multiple masks affecting one layer, there is no way to combine them in Pathfinder-type operations since the layers panel only offers the regular layer blend modes that are useless in a mask context. The Photo team also has unfortunately copied Photoshop's nonsensical 1990ies limitation that features like Color Range selection are destructive commands outputting a selection and HSL qualifiers are limited to the HSL dialog box instead of working like non-destructive adjustment layers that can be used as mask layers for any type of layer or adjustment (or in case of the latter at least allowing them to be used to generate selections). But while I hope we'll see some workflow, feature and usability improvements in these areas in the future, for now, the most essential features are there at least. And while they're far from intuitive, they are at least usable and have the potential to be really powerful. Already, we can do things that are impossible in Photoshop, such as applying non-destructive adjustments to masks, using multiple masks on a single layer and so on. By the way, in addition to any Channel Mixer workarounds, Grayscale layers can be converted to masks by selecting Layer > Rasterize to Mask, and the reverse can be done by selecting a Mask layer, right-clicking the "Mask Alpha" channel in the Channels studio panel and selecting "Create Grayscale Layer".

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.