Search the Community

The screenshot should be self-explanatory - the overlap shouldn't be visible when opacity is under 100%. n.b. I know there are workarounds such as grouping or applying linear transparency but I'd prefer this to be fixed - thanks!

Hi, the User variables within the export persona are not working at all. You can add new variables in a slice, but they don't appear in other slices Affinity Designer 2.1 and 2.1.1 Mac Mini M2 Mac OS Ventura 13.5 No recent change in my system Definitley reproducible. Tried everything for hours old documents New document Updated AD (2.1 => 2.11) Tried to manually recreating the variables Tried to copy and pate the slice settings to clipboard => The variables are only valid within a slice Would be great if you could fix that in the near future. This will save me hours of work, since I use the export persona very extensively (with dozens of slices for each document). One of my main (and most annoying) tasks every day is to rename slices in Affinity Designer... (sorry that I recently suggested that as new feature (I just missed it) Best regards, Dave

Affinity Designer 2.1.1 cannot open a svg if the file is encoded in ASCII. When I change the encoding to UTF-8, then it works just fine: <?xml version="1.0" encoding="ascii" standalone="no"?> <svg version="1.1" ... => <?xml version="1.0" encoding="UTF-8" standalone="no"?> <svg version="1.1" ... Is there a reason why Affinity doesn't support ASCII (Inkscape does).

Recently I noticed that Designer 2.x files with artboards get clipped when placed in another document. The placed image has a correctly sized frame, but its contents are not fully drawn. The clipping occurs on the top and left side of the frame. It doesn’t matter how many artboards you have or in which Affinity app you place your graphic. This problem is most noticeable when the artboard fits tightly around its contents. It is not a display issue, as the exported PDF shows the clipping too. This issue only occurs in Affinity versions 2.0 and 2.1. Version 1.10.6 works as expected. Moreover, a Designer 1.10.6 image placed in a version 2.1 document renders as it should. That’s why I think this is a bug. Note that this isn’t about outside strokes that get clipped off because they overflow the frame. I’m using macOS 12.6.5 and the latest Affinity Publisher (2.1). Workaround: Resize the document to the desired size instead of creating an artboard, as the clipping only occurs with artboards. Steps to reproduce: Create a new document in Designer 2.0 or 2.1. Draw a circle, say 50 mm diameter. Give it a fill. The colour doesn’t matter. Don’t give it a stroke. Select the artboard tool. Choose Selection in the context toolbar and click on Insert Artboard. The artboard size is now 50 x 50mm. Save your document. Open any of the three Affinity apps (version 2.0 or 2.1). Create a new document large enough to fit the circle. Import the circle (File > place…) The circle is clipped on two sides, but the frame itself has the correct size of 50 x 50mm. It would be great if the Affinity team could look into this!

Reproduction Steps Create a brush or pick existing one Set dynamics > flow jitter > 100% distance Set custom falloff to image attached draw line and watch the brush fade out set stabliser on and draw another line With step 5 you will see the issue. The line is far shorter so stabliser is messing up the dynamics calculations. These lines should be of equal distance, which they are not.

This effects all three programs: Photos, Designer, and Publisher. When i minimize the program to the dock, clicking on the docked icon does not expand the program to the desktop again. it does however make it the active window. to expand the program i must right click on the docked icon and and select the currently opened file in the program.

A bug in Publisher v1 and v2 causes the table of contents (TOC) layout to go berserk when refreshed because it sponges up unrelated character/paragraph styles from the document. During a TOC refresh, the update function superimposes whatever character or paragraph style is used last in the document on top of the actual TOC styles. This should never happen since Publisher uses independent TOC styles to generate a TOC. For example, if I apply a red character style somewhere in the document and then proceed to refresh the TOC, the entire table of contents will turn red. The same goes for paragraph styles. If I apply a numbered list style somewhere in the document and then go to the TOC to reload it, every TOC entry will start with a number. The TOC only sponges up style settings which are undefined in a TOC style (or its ancestor's TOC style) but defined in the last used document style. With undefined settings I mean unchecked settings or [No Change] settings, anything that can inherit a value. So if I explicitly set the base TOC style to use black text, the unrelated red character style can no longer affect my TOC layout. This workaround works but is impractical for documents that use numerous styles. Since any of these could affect the TOC at some point, you'd need to overrule quite a few settings. Luckily, there's a more suitable workaround, albeit a bit silly. Workaround: Make sure nothing in the document is selected. Go to the Text Styles panel. Set the Paragraph and the Character style to [No Style]. Click somewhere in the TOC to make it active. Refresh the TOC from the Table of Contents panel. The TOC now exclusively uses TOC styles. This behaviour must be a bug. I can't think of any reason why this would be a feature. It appears that forum user Loquos experienced the same issue last November, so I'm pretty sure it's not my setup at fault. Steps to reproduce the problem: Create a new document. Place two regular text frames on the page. From the Table of Contents panel, insert a TOC in frame one. Add a few lines in frame two and apply the default Heading 1 style to each. Go to frame one and refresh the TOC. Edit the TOC style 'Base' and disable the tick mark next to the text colour setting (character fill). Type some text in frame two. Add a new character style and set its text colour to red (character fill). Apply the red style to the text you typed in step seven. Update the table of contents in frame one. The new character style colours the contents red, even though it is entirely unrelated to the TOC layout. When I tried to reproduce the bug in a new document, I noticed that even though the Base style for the TOC is based on [No Style], it is far from empty. Almost every setting in the Base style has a default value. This explains a lot. I tend to defenestrate the default styles when I create a new document. My styles only have values for the settings I need. They don't have default values for unused style elements. This likely caused these daft TOC layouts, but that's beside the point. My approach should've worked just as well. After all, a TOC should never sponge up settings from a random document style. It doesn't make sense, but it is what's going on. I'm using macOS 12.6.3 and the latest Affinity Publisher (2.0.4). I always use the Table of Contents panel to update the TOC. I did not try the Preflight panel's TOC update feature. Hardware acceleration does not affect the issue. Neither does it help to unplug all external hardware. The problem exists in both Publisher v1 and v2. It would be great if the Affinity team could look into this peculiar behaviour and hopefully fix it! Thank you!

When using stage manager on iPad, I am running into important features in Affinity Designer being blocked by the triple dot menu that shows up at the top.

Hey community! The title actually says it all. I've been using this incredibly useful little feature ever since I learned it decades ago (when I was working with Adobe applications), and was very happy to find it right from Affinity’s first ever release (?) in the shortcuts menu: »Set Fill to Black and White«. It's particularly useful in Designer when you need to quickly reset the base colours of your shapes, but also in Photo, especially as all the apps in the suite work so seamlessly together. However, using this shortcut in Photo with an active Fill Layer in the layers panel completely breaks it, like … irreversibly. Not even the »Revert defaults« button (if added in the toolbar) can revive its initial state! ☹️ Steps to Reproduce: Set up a shortcut under Shortcuts → Miscellaneous → Set Fill to Black and White. Note: There's no menu item for this option at all, it's only accessible via a keyboard shortcut, factory default is D. Create a Fill Layer. Select Fill Layer (if not already active) in the layers panel. Use the designated shortcut previously assigned to Set Fill to Black and White. Expected Behavior: I’m actually not sure what I expected. 😅 Probably a reset to white? But I'm not sure about the stroke, since a fill layer is practically borderless. And I suppose that might be the reason why it breaks. Current Behavior: The Fill layer turns transparent and stops responding to any changes of color or other fill. As mentioned, Set Fill to Black and White completely breaks the layer irreversible. You have to delete the layer and create a new one. I'm having the same problem on MacOS and Windows, but as I'm sitting in front of a Mac at the moment (and since the forum is lacking a thread for bugs that affect the application regardless of OS), I'm going to post it here. Can someone verify this? Cheers Dennis aka The Guy With All the Fill Layer Issues 🥲

This one layer is not showing any adjustment layer icons when collapsed. Notice the comparison between open and closed. And other layers. Also, at my current UI font settings, the lower part of some lower case letters are cut off.

I've already seen other bug reports about the transform origin (so I think this is related and you already know), but none on Windows or reporting specifically this. I've met this bug both on Photo and Publisher. Right after resizing an object (be it a vector shape, a pixel layer or a placed image), the transform origin starts to be affected by a fixed offset that makes impossible to put it where you need. I can't screen record my pc now, but it's really that easy to reproduce. To workaround it you need to unselect and reselect the object again. Then the origin point starts to behave properly until a new resize will make it go crazy again. Affinity 2.0.4 on a Windows 10 machine

Whenever you enter the toolbar customiser (for the top as oppose to either of the sides) and try to drag around the existing tools that reside in the tool bar you drag the entire application window around instead of just adjusting the position of the tools in the toolbar. Not sure if it is specific tools or not, in my experience it varies and can be random which it does this with. This happens on Mac OS as of the most recent update, and I believe before that. It also happens in Photo and Publisher, not just Designer. Toolbar Example.mov

Hi there! I came across this picture frame presets bug recently and thought you might be able to help with it. I made a video capture which demonstrates the issue as I thought it would help illustrate the problem better than me just talking about it. https://www.icloud.com/iclouddrive/00cHQ2xz-PQRZMStoIxsNheVQ#PictureFrame_Presets_bug Thanks, Oli ;-)

Eu descobri esse erro quando estava fazendo uma ilustração, e fui usar os pincéis do Frankentoon - Rough Shaders, mas depois dos testes percebi que esse erro acontecia nos outros pincéis também. Fiz o mesmo teste na ultima versão do affinity designer 1, e estava funcionando normalmente. Bem, agora vamos para explicação: Numa folha A4, fiz 3 linhas usando o pacote Fineliner brushes para facilitar nos testes, todas com Butt Cap e tamanho 60 pt Fiz a primeira linha em azul, usando a pen tool, da mesma largura do papel a segunda em rosa na metade da largura da primeira e a terceira em verde na metade da largura da segunda IMPORTANTE: eu fiz as três linhas SEPARADAMENTE, e não copiei a segunda da primeira e diminui o tamanho Usei o pincel Stipple 6 - Anti-stretch, tamanho 60 pt como já dito anteriormente, e é configurado para repetir como mostra na imagem Depois, eu dupliquei o primeiro grupo de linhas Aumentei manualmente a segunda e terceira linha pra ter o mesmo tamanho da primeira E, acontece que, a textura estica mesmo que esteja configurado pra não esticar , mas se mudar pra esticar ele não muda no papel, só no preview dos pincéis. Os mesmos teste foram feitos na versão 1, e estava funcionando normalmente. brush test.afdesign

Hello everybody, the following error already occurs since version 1.x of Affinity Photo and was already described in the respective forum and declared as a bug. When applying an HSL adjustment layer to a 32-bit RGB file, the hue selection does not work correctly. The bug can be reproduced. I am running Affinity Photo 2.0.3 on Windows 10 Pro x64 22H2. Hardware acceleration is active, but the error occurs even if it is disabled. The following step-by-step guide can be used to reproduce the bug and for details about it. The screenshots are from version 1.x of Affinity Photo, but the procedure is the same for version 2.x as well. Start Affinity Photo. Go to "File" --> "New...". Create a new file with the following properties: Place a new image (from file) by going to "File" --> "Place..." on the background. Add a HSL layer. The work area should look like this: Now open the HSL adjustment layer and pick one of the six predefined colors. Since I want to change the red and yellow colors I pick the red dot. Now decrease the saturation to 0 %. First of all, it seems everythings works fine: Now drag the four color dots to another color like blue. The expected behaviour would be that the red colors get saturated again and the blue colors get gray. Since there are no blue colors in the picture the picture should look like the original again. But what is happing actually is, that the red colors are still unsaturated and although the outer ring of the color wheels shows gray "blue" colors nothing has happend in the picture: It does not change anything if you try to use the "Pipette" instead of draging the four dots. When working with an 8 or 16 bit RGB file, the HSL adjustment layer works just fine and as expected. The original posted bug was found on MacOS. I guess the MacOS version is still affected. Feel free to ask me for more information. I hope my findings provide some information on how to deal with this issue and find a solution to it for me, as well.

usecase: stitching A4-like cuts for my wife on our A1 printer - i take PDF, drop in on the paper, select pages and copy them around and move precisely to match the borders. So far so good. then i want to export and all breaks. PNG/JPG previews Fine(1.JPG), when i hit export to PDF, transparent bg shows in export preview (2.JPG). When i export, i got same error as in test.pdf. Nomatter if its PDFs are embedded or linked. Plenty of RAM, plenty of disk space. Cannot publicly add the cut here because of copyrights, but if anyone contacts me from serif, i can send it privately for examination. Also, some times after export in version 2 the whole view f... up and i see only first pages of the PDF allaround as i never changed it to other pages with no possibility to step back. (in version 1 no problem. all exports fine and without problems) To be honest, i think the new export in PDF is somehow broken, i have problems with it all the time, in publisher it crashes often, when im exporting the book, here aswell problems.... test.pdf

写给Affinity Photo的建议信 你好，我是来自中国大陆地区的Affinity Photo的用户， 我使用Affinity Photo已经有两年了， 主要用于对绘画进行图像处理， 很高兴能看到的Affinity Photo 2.0的出现， 我第一时间进行了下载试用。 我有以下的一些建议，用在我的流程上，方便使用： 01.增加图层的显示/隐藏的切换，只绑定一个按键， 而不是两个不同的键。 我经常使用shift+d来检查一个图层的开启效果与否。 02.能给宏设置快捷键， 我自己制作了些对于我的工作流程很高效的宏， 希望能更加高效地使用键盘快捷键调用。 03.能给滤镜插件也设置快捷键， 我经常会使用到nik collecion的插件。 还有我还发现一些bug： 01.在使用BorisFX Sapphire 2023的.8BF插件的时候， Affinity Photo 2.0会直接崩溃。（在PhotoShop2023中正常使用） BorisFX Sapphire是个很强大的后期滤镜， 我希望Affinity Photo 2.0能支持它。 02.在保存了afphoto的时候，只有等到关闭文件的时候才会写入略缩图。 1.0的版本的时候是立刻写入的样子。 我的操作系统环境是 win10 21H2。 ———————————————————— Advice For Affinity Photo 2.0 Hello guys，I am user of Affinity Photo from China. I have used Affinity Photo for 2 years. I always use Affinity Photo for adjust my Illustrations by filters. I am glad that Affinity Photo 2.0 is comming.I try it at a first time. I have advice for Affinity Photo in order to use it for more efficient. 01.add a switch function to hide/show a layer using 1 shortcut,not 2 buttons. I frequently use shift+d to hide or show a layer to check effect. 02.add shortcuts for calling macros. I make some powerfull macros for my workflow, I want to call them using keyboard. There is no way to use them by shortcut, it is uncomfortable for me. 03.add shortcuts for calling filter plug-ins. I offten use "Nik Collection Analog Efex Pro 2" There is no way to use it by shortcut, that also makes me uncomfortable. I have also find some bugs in Affinity Photo 2.0 01.When I using "BorisFX Sapphire 2023"(.8BF plug-in), Affinity Photo will crash immediately.(It works fine in PhotoShop2023) "BorisFX Sapphire" is a great amd powerfull filter plug-in. I hope Affinity Photo 2.0 support it. 02.When Affinity Photo 2.0 saving .afphoto file, Thumbnail will not be saved and refreshed immediately until Affinity Photo 2.0 close the file. Affinity Photo 1.10 will save and refresh.afphoto Thumbnail immediately My OS is Windows 10 21H2. and have a nice day.

When you export to TIFF or JPEG and the keywords are comma delimited only the last keyword entered shows up in the exported file. This same thing happens on iPad with latest updates and Mac running Big Sur OS. This has also been reported in the Mac version portion of the forum. UPDATE: Tried to test on iPad by changing commas to semicolons. In multiple tries the keywords field was no updated after clicking OK. I believe there is a serious problem with the whole keywords module when it comes to editing and exporting. 2ND UPDATE:This morning I tested by exporting a JPG file with several keywords. Like previously when I checked to see if keywords were fully copied to the JPG file only the last keyword in the list was this displayed. However, I then did something I didn't think of doing yesterday when testing, I opened the same JPG in the software NeoFinder and all keywords were displayed. So, there is a problem with the way keywords are being handled but it appears that they are not being lost upon export. Instead it appears to be the display of all keywords in JPG and TIF files generated by AP. Hope this info helps.