Pyanepsion

Hello, I am working on fine typography in Affinity Publisher. Some high punctuation marks (such as ?, !, ;, etc.) must be preceded by a specific space. I cannot find any way to automate this in the automatic replacement module while typing (menu Preferences > Auto-correction > Replacement), which would allow automatic input without having to go through a long and tedious search. Example with U+2006: <word>? → <word><6/EMSP>? How should I proceed? Thank you for your help.

@Kaizu, The Affinity suite does support BMP files on import, but does not allow exporting to this format. This appears to be due to the fact that BMP is now rarely used, particularly in professional settings. BMP is indeed an uncompressed, bulky format, lacking support for advanced transparency or modern metadata. It has largely been replaced by formats better suited to current needs, such as PNG, TIFF, or JPEG XL. This absence of export functionality therefore necessitates using another piece of software to perform the conversion, which may seem surprising in the context of a suite designed for professional use. → It would thus be helpful to understand the purpose of your request, It might warrant future support. Serif’s position on this decision would also be of interest. P.S.: It is also worth noting that the list of export formats is still not arranged alphabetically, which unnecessarily complicates selection. It is surprising that such a minor detail — presumably easy to address — has yet to be implemented, despite the clear improvement it would bring to everyday usability.

The “Edit Frame Content” command does allow access to the QR code link, but at a cost. It appears to be impossible to restrict the edit to what is actually needed: the link, and nothing else. In practice, this is not true content customization, but a disguised full detachment, which opens the door to user errors and undermines the logic of the master layout. Concrete examples: In a document structured with several types of master pages (chapter starts, left pages, right pages, etc.), you may have 30 to 50 inherited QR codes per page. Having to activate Edit Frame Content on every page — while carefully avoiding any accidental shift, resizing or modification — quickly becomes unworkable in real production settings. → What is really needed is the ability to modify the QR code link directly on the page, while preserving the structure, position and appearance inherited from the master page — just like you can replace an image inside a frame without altering its placement.

Hello everyone, While working extensively with the 3D Layer Effect in Affinity Publisher, I’ve noticed that the current layout of the panel is somewhat confusing — and at times contradictory. It mixes unrelated controls, separates logically linked ones, and doesn’t follow a clear progression from object to light behaviour. To help clarify the interface, I’ve restructured the panel into three functional areas. I’m sharing here a visual mock-up of a proposed reorganisation, along with some terminology refinements and a note on a likely bug. 🔁 Current issues Related parameters (e.g. Specular and Specular Colour) are currently separated. Light source attributes and material reactions are mixed in a flat list. The logic of progression — from object shape to lighting interaction — is not reflected in the current order. Labels such as Add / Remove are semantically misleading. ✅ Reorganisation principles This revised structure follows a logical and ergonomic order: Shape and Volume Defines the object’s physical geometry and depth profile. Light Source Describes the number, position, and colour of the light source(s). Matter (Physical Reaction to Light) Groups the material’s optical properties, including diffuse, specular and ambient responses — with each value paired to its corresponding colour field where applicable. I’ve also renamed Light source Colour (previously just Colour) for clarity and consistency. The mild redundancy is intentional: repeating the term Light source helps visual scanning and reinforces category separation. You can view the mock-up below: The panel is slightly taller, but it’s also much more readable and easier to work with. Grouping related controls and adding spacing between sections brings real comfort — especially during longer editing sessions. ⚠️ Minor bug report The Remove button under Light Source does not behave as expected: while it reduces the number of light sources, the object doesn’t update accordingly in real time. A manual refresh (disabling/re-enabling the effect) is needed to reflect the change. Moreover, the labels Add and Remove are problematic: Add may be confused with Add blending modes or other addition-type operations found elsewhere in the interface. Remove is misleading: it doesn’t delete anything — it simply decreases the number of light sources. To improve clarity, I suggest the following alternative terms: Add → Increment (Inc) Remove → Decrement (Dec) This terminology more accurately reflects the true function: adjusting a numerical count, not performing object-level creation or deletion. 🧊 New order Shape and Volume Profile Remove Profile Radius Depth Soften Opacity Light Source Light Source Colour Light Source Add Remove Direction Azimuth Elevation Matter (Physical Reaction to Light) Specular Specular Colour Diffuse Shininess Ambient Ambient Colour 🧾 Conclusion This suggestion is shared in the spirit of contribution. The 3D effect tool is powerful, but a more structured and readable UI could make it even more accessible — particularly to less technically inclined users. Thanks for your work and for considering this feedback. Best regards,

Hi, @currentuser, I think there's a confusion (which we've all made at one time or another). A 400 × 400 px image gives 160,000 pixels. If you export it at 100 × 100 pixels, it will contain 10,000 pixels. Put another way, you've lost 150,000 pixels of information. And vice versa.

Hello everyone, The QR code creation tool still suffers from several notable shortcomings, despite the time that has passed: Desktop 2025-07-01 06-11-38.mp4 1. No direct background management It remains impossible to apply a background directly to the QR object. To achieve a visually acceptable result, one must manually create a rectangle, place it behind the code QR object, and then group the elements — a repetitive task that unnecessarily complicates the layout process. 2. Functional lock on master pages More problematic still: when a QR code is placed on a master page, its link cannot be modified on the associated pages. Unlike images, the object remains fixed. This limitation forced me to revise around twenty layouts to remove all master-page QR codes, and then reinsert them manually across 190 placements in the document — with, of course, an increased risk of positioning errors or omissions. 3. Ambiguous Icon in the Interface Finally, the same icon (a cross in a circle) is used for two entirely different functions: Enable Transform Origin in the transformation bar, and Visit target URL in the link options. This redundancy undermines interface clarity and leads to confusion. These limitations are difficult to accept in a commercial professional tool. The feature appears to have been rushed to release — and remains uncorrected to this day. qr-tool.afpub

Hello @Red Al First, check both the spread and the individual page settings — they show different things. You should create and see something like this: 📄 Layout: 210 × 297 mm (or 297 × 210 mm), depending on whether your page is in portrait or landscape orientation. 📄 Page settings: If Facing pages is ticked, Publisher displays a spread made of two A4 pages side by side, which equals an A3 width. If it’s unticked, you’re working with a single A4 page, and the size shown will reflect that. So this isn’t a bug — it’s just that the software is showing the spread size, not the size of one page. This is intentional, and useful when working with double-page layouts. You'll then find it in File | Document Setup. Layout (so, A3) Or page (so A4).

→ Not at all! On the contrary, the solution should lie in simplification. The perpendicular constraint should simply be removed. The tab movement should be interpreted only along the main axis of the bar (horizontal in this case), and its position confirmed only upon release of the mouse button. This would prevent accidental detachment while maintaining a simple, fluid, and intuitive behavior. 🙂This is, in fact, the rule followed by most modern software.

The issue becomes more noticeable as screen size and resolution increase, particularly on today's most common displays (24–27"). Tabs detach too easily, even when dragged carefully in a straight line — see the second video (recorded on a 5K screen). This sensitivity makes the behaviour problematic and worth fixing.

@Ali 🙂That’s exactly the issue — the file tab detaches too easily, even with careful horizontal dragging. The second video shows how hard it is to control. Compare it with the first video using another software — there, tab movement is smooth and predictable.

Just to clarify: I’m talking about file tabs, meaning the documents opened at the top of the workspace – not panel tabs like those in the Studio on the left or right. On Windows, when I try to rearrange a file tab in the tab bar, it almost always detaches and becomes a floating window. When I reinsert it, it’s automatically placed at the far right, regardless of the position I intended. This behavior is what I find frustrating and unintuitive, especially compared to editors like Notepad++ (video in first message) or VSCode, where tabs move exactly where you drop them. My explanation was apparently misunderstood. I suspect it may have been due to a poor translation of my original message in French. So this time, I’ve recorded a video directly in Affinity to illustrate the issue more clearly. See at 8s and 25s. Desktop 2025-06-20 06-52-11.mp4

The current behavior of file tab movement is highly counterintuitive and difficult to control. Improving the ergonomics of tab handling would be particularly beneficial. Currently, in the Affinity suite, a file tab detaches as soon as it moves slightly outside the tab bar’s boundary, and when reinserted, it is always placed at the far right, regardless of the intended position. → The current tab management feels outdated compared to modern UI expectations. By comparison, editors such as Notepad++ and Visual Studio Code follow a more flexible and predictable logic: the user clicks and holds a tab, the tab can be moved freely, without strict vertical or horizontal alignment constraints, the button is released approximately where the tab should go, the tab is inserted precisely at the intended position, respecting the order of existing tabs. This behavior allows for fast, fluid, and fully controllable rearrangement, with no unexpected results. Notepad++: moving tabs, and pinned tabs Desktop 2025-06-16 17-56-38.mp4

Thank you for your reply — I completely agree that it’s important to keep this discussion factual and respectful. That said, I feel your interpretation of my remark may have been slightly overreaching. When I wrote that the idea of “rewriting everything” does not hold up, it was not intended as a personal comment. I was simply responding to a recurring technical argument — namely, that the ICO format is too specific or structurally incompatible with Affinity’s current export framework. I maintain that, technically speaking, Affinity already provides the essential export features: multiple artboards or slices, transparency support, automated resizing and batch export. These are precisely the building blocks used by ICO generators. What remains is the final assembly into a multi-image .ico container. It’s not trivial, of course, but it doesn’t amount to a major architectural shift either. Moreover, I respectfully disagree that the user base concerned is particularly marginal. On its own website, Affinity Designer is described as In that context, the ability to produce a finished site or application icon — in .ico format — seems not like a niche demand, but rather a practical, professional feature consistent with the product’s positioning. Many interface designers and web developers — freelance or in-house — reasonably expect their design tool to handle the complete export chain, including favicons. To be clear, I’m not calling for full icon management or executable resource extraction, which would indeed fall under highly specialised and marginal use cases. What I’m suggesting is far more modest: a basic, structured export of a .ico file from square slices — a clearly defined feature, well within the scope of a design-focused suite. I hope this helps clarify where I’m coming from and why this feature matters in practice. Your response gave me the opportunity to clarify my position, and I thank you for that.

Thank you for your comments. Allow me to offer some technical and contextual clarifications, which I hope will help to refocus the discussion. Yes, it is entirely possible to create a .ico file using third-party tools. But that is precisely the point: why should we have to resort to external solutions, at the risk of compromising file security or confidentiality, when the Affinity suite already contains everything necessary to implement this functionality efficiently and natively? An ICO file is not an obscure or opaque format. It is a well-documented, structured, stable binary container, used for more than twenty years. Microsoft provides the official specification here: https://learn.microsoft.com/en-us/previous-versions/ms997538(v=msdn.10) Affinity Already Has the Foundations: Only the Assembly Is Missing. Affinity already allows exporting multiple slices or artboards at different sizes, with transparency, in PNG format, with automated naming. It also supports batch export structures. These are precisely the building blocks required to generate a .ico. What is missing is only the final assembly step — a multi-resolution output format combining several images into a single file. There is nothing “fundamentally incompatible” with Affinity’s architecture in that. It’s not a radical overhaul, but a natural extension of the existing export logic. The idea that this would require “rewriting everything” simply does not hold up — claimed by those who, for reasons one can only speculate about, seem oddly resistant to the idea of ICO support. As if any evolution of the export engine were forbidden or nearly impossible, which is clearly not the case. The .ico format accepts several encapsulated images, all square and homothetic. A typical content example would include: 256 × 256 (32-bit PNG) 64 × 64 (32-bit) 48 × 48 (32-bit and 8-bit) 40 × 40 (32-bit) 32 × 32 (32-bit, 8-bit and 4-bit) 24 × 24 (32-bit) 20 × 20 (32-bit) 16 × 16 (32-bit, 8-bit and 4-bit) Duplicating some sizes at different colour depths ensures full backward compatibility with older environments or constrained systems. Web browsers, Windows systems and shortcut icons still rely on these variants to ensure optimal adaptation. To Sum Up: — The format is simple, clearly defined, and thoroughly documented. — ICO export is technically modest and entirely feasible. — Affinity already has all the required internal tools. — Every competing solution already supports it — some for over a decade. This is neither a niche request nor an insurmountable feature. It is a basic function, long awaited, practical, and entirely aligned with the professional ambition of the suite.

There are, of course, workflows based on CMS platforms — I use them myself — but that can in no way substitute for having native ICO export built into the suite. Let us also recall that this format, still used for favicons and Windows application icons, requires no automation or advanced processing. Its absence remains a genuine shortcoming in a tool aimed at professionals. Creating an ICO file is, in essence, merely a matter of binary wrapping: the images themselves are standard bitmaps or PNG files — both of which are already fully supported by the Affinity suite. In reality, Affinity already contains everything required to implement this functionality efficiently, without the need for new export engines or complex external libraries.