dpeters911

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:

This appeared in my document too. I'll try recreating it without master spread graphics and report back! EDIT: Removing graphic from master spreads works. Looking forward to this being patched!

Background I created a 48 page document with a mix of text style, large raster graphics (1-5 MB photos), and vector graphics and two master styles, one for the cover exterior and another for the interior pages. ANSI Letter 5.5 x 8.5 pages in 11 x 8 spreads. I use a second, raster version of each full-spread photo that is blurred and saved to JPEG format. I overlay it to improve contrast. I used the default "prefers embedded files" setting. Attempts to Fix Issue Recreated document from scratch but selected prefer to link to file (much like how I use InDesign), rather than embedded. File size wasn't that different, which surprised me (43 MB for linked vs 47 MB for embedded) Crash still occurs when saving and attempting to reopen the file, throwing this reference: cb9c24ca-1885-41dc-9901-a1bc033de38a Crash occurs before any pages or graphics can load. Further Testing It appears that this is a known issue with raster graphics on Master Spread pages. I recreated the document without graphics on master spreads and it saved and loaded just fine.