davidagnome

If I export an artboard individually from the Design Persona and File > Export, checking Include Bleed, my document's bleed is respected no matter which artboard that I select. If I export to JPG, PNG, and TIFF -- each artboard en-masse -- it doesn't export with a bleed despite using Include Bleed under the export options for each. Mac OS Sequoia 15.5 Mac Mini 4 Pro w/ 24 GB RAM Affinity Designer 2.6.3 - MacOS version

Bumping. This improves workflow speed dramatically for magazine, newspaper, and textbook layouts.

Yes please. Span and split columns, overriding the parent columns. Manually placing them is so 1990s.

Still requested. This is a great feature to simplify workflows

I installed last night's MacOS v13.4.1 and the recent Affinity Publisher update to v2.1.1 I was reorganizing files with SVGs, AFDDESIGN, and JPEGs linked (not embedded). While cleaning folders last night, I accidentally moved a folder from the desktop that contained all three file types in my project. When opening the file it causes hard memory fault crashes to desktop UNLESS I immediately click the prompt remap the file locations in the Resource Manager. I was able to reproduce it this morning by moving the folder again. Same crash errors unless I remapped in Resource Manager before it tried loading the rest of the files.

This would be so useful. My workaround is breaking the flow manually, directing it to a text box with wrapping -- but this can cause reflow issues if anything changes in a revision pass. I will send the finest Irn Bru to the offices of Affinity if they add this.

It's awesome to automatically flow content to the next column, frame, even/odd page, etc. Can Serif add column span (esp. a span all columns on a page) to Affinity Publisher? This would help improve layouts with sophisticated headers.

Now that performance has improved: +1 for this. I have some nice chapter and section headings in a book I'm working on and it's a bit wonky to figure out.

Bug Using either the . or delete keys on the iPad Pro/iPad Air 4 attachable Magic Keyboard return (null) when entering a form field for an attribute (I.e. document dimensions, transform tools, stroke size, etc.) The expected result would be 10.4 instead 10(null)4 centimeters when entering a value into the transform or other tools. Delete doesn’t remove text either. For example, if I enter 10.5 and hit delete the then 4, the output should be 10.4 but the systems renders it as 10(null)5(null)4. Temporary Workaround Can be corrected only by using the touch interface to use the calculator’s . And <x| Virtual key. Devices Used: iPad Air 4 (2020) on iPadOs 14.2 Magic Keyboard

Could inner/outer shadow paragraph decoration be added? The idea is boxed decorations is great, with a wide variety of strokes and endcaps. However, dropshadows would add options to emphasize text (i.e. a boxed paragraph).

We may have discrete Sections available as Fields but running footers/headers making use of specific paragraph types (i.e. Heading 1, which might have Flow break to the top of the next page). Ideally, we could configure which paragraph styles are accessible in View > Studio > Fields. My suggestion would be to have it user-configurable from right-click the "Edit <Paragraph Style>" Paragraph > Field Options Available as Field? First or last available? On Page or Spread? (see relevance of first/last in previous question) This would make for some really robust footer/headers on master pages, esp. in education or technical materials with dense, structure order to their contents, allowing us to guide the read through. The Field referencing the other Paragraph style occurring in the main document could be styled by any existing paragraph style as expected.

Same thing for me. That unhandled exception due to graphics in Master Pages is a known bug in .58 -- hold off for now and test on the next build

Background Added an EPS file, exported from Affinity Designer, for use in Affinity Publisher. Dragging into the document is fine, especially once it's resized. The issue comes into play with a massive performance hit *after* applying wrapping around an object. It's a round vector image with transparent/hollow interior sections. The performance hit brings my machine to crawl but I'm using a fairly powerful rig: AMD Ryzen 2700 (8 Core, 16 Thread) 32 GB of DDR4 Ram @ 2933Mhz AMD Radeon RX 580 w/ 8 GB GDDR5 Potential Causes Regardless of wrap style chosen: square, tight, inside, or edge, there's a massive performance hit. During this, background objects are sometimes selected as well (but I can't reproduce this reliably). This leads to applying the setting on an element that wasn't selected due to UI response issues.

Have you tried applying a master page style for the first and last page (i.e. exterior cover) of the document that adds the additional gutter needed for the binding? You'd probably want to create a second master page for the interior, if any text is on the interior side of the cover.

Will be testing the below error and updating above: