Peter Werner

I can confirm the issues with the Lighting filter being out of place after changing the document DPI. I have a lighting filter on a group of multiple Art Text objects with layer effects (this lighting effect is always missing from PDF exports by the way, but I'm not sure if that's maybe a separate bug). If I change the document DPI in Publisher via the "Document Setup" dialog box, the positions of the Lighting effect, which are apparently resolution dependent, don't seem to be updated. This also messes up the undo stack – it's not enough to undo the DPI change via history to get the Lighting Effect back to its original position. The document in question was probably originally created in 1.7.2. Would be useful, by the way, to be able to directly change the DPI in the export dialog box for raster image formats to be able to render vector elements at higher or lower resolutions than the document was originally set up with. It just allows to set absolute pixel dimensions, but if I have a document that's set up in points or millimeters, that's less useful than a DPI/PPI control. Sending stuff to be professionally printed onto CDs/DVDs, in photo labs, certain sign companies, engraving firms, mug manufacturing companies etc., sometimes necessitates sending designs in the form of rasterized data rather than in vector formats like PDF like a "proper" printing company would accept. Also guys, if at all possible, please move the compressed file size calculation in that export dialog box out of the UI thread –for very large files (such as exporting a 60 cm x 90 cm poster at 1200 ppi to be printed by a photo lab), the hang caused by that can make changing all the export settings a major pain because every keystroke or click causes a 15 second hang. System: Affinity Publisher 1.7.3, MacOS 10.11.6, late 2008 Aluminum MacBook upgraded to 8 GB RAM, NVIDIA GeForce 9400M 256 MB, external Monitor connected via DisplayPort with custom ICC profile Eizo Color Navigator 6/Spyder3.

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.

I'm using an external (Apple) keyboard that does not have an Fn key. Pressing the Fn key on the built-in laptop keyboard does not change the behaviour I described, neither in conjunction with the F-keys on the external USB keyboard, nor using the F-keys on the built-in laptop keyboard. Further investigation shows that furthermore, the shortcut input control in the text style editor dialog box doesn't accept F14 and F15 since these seem to automatically be tied to adjusting screen brightness on the laptop screen. Holding the Fn keys has no effect on this behaviour. I think if all of this was a case of system shortcuts taking precedence, they would just carry out their system function when pressed instead of nothing happening, as they do in case of F14 and F15. By the way, I've come across another oddity: Assigning F16 shows a warning that the shortcut is already mapped to "Zoom Out". Turns out this shortcut actually works for zooming out the document, but in the keyboard shortcuts editor in preferences, only Cmd+- is listed for Zoom Out. Maybe this has to do with the shortcut editor only allowing being able to handle one (probably the first) shortcut per command.

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.

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.