bbrother

Mine samples and applies styles like a charm — unless yours is just shy. → Check out the demo. Not at all, Mike. Just use quadruple click and the paragraph will be selected along with the paragraph break mark. DEMO: Style Picker: Sampling AND Applying? 🤯 Yup — just in case someone’s still unsure.↓ Style Picker.mp4

R C-R, your confidence is unmatched — but unfortunately, so is your misunderstanding of how Style Picker works. It does sample paragraph and character styles — the documentation says that verbatim: Also, in the Settings section: Character Settings—when selected, the currently loaded character styles and local formatting will be applied to text ranges you interact with. Paragraph Settings—when selected, the currently loaded paragraph styles will be applied to text ranges you interact with. So, Yes Style Picker does apply named paragraph and character styles — provided the corresponding settings are enabled and full paragraph (including the break) is selected. Key facts about this tool: It’s not a clone-paste tool, but a sampler and applier. It loads paragraph style, character style (also named) and any local formatting applied at the precise character that is clicked. It applies paragraph style, character style (also named) and any local formatting to selected text To apply named paragraph style you need not only be sure about two things: Appropriate setting is checked in context toolbar The full paragraph (including the break) is selected. You're misinterpreted both terminology and tool behavior, which could mislead others. @MikeTO, great reply — the “trick” you mentioned is the key, but allow me a nerdy tweak: Style Picker doesn’t “copy” styles per se — it “samples” them. Just semantics, but could save someone from assuming they’ll get duplicate styles. @Catshill You might want to update your thread title to: “Style Picker doesn’t apply text styles” That’s closer to the issue, and more useful to others scanning the forum for style quirks.

Calling it 'indoctrination' when people have spent decades working with the only real industry standard sounds weak. For years, there were no viable alternatives, so people built skills within the ecosystem that dominated the industry. Exploring other tools now is not a sign of past blindness, but present-day openness.

Just to let you know, if you’re not happy with your purchase and you bought directly from Serif, you can request a full refund within 14 days of receiving the product. Simply email affinityreturns@serif.com. Otherwise, check the refund policy of the store you bought from.

Can’t argue with that — when shortcut labels get patched and Contour Tool remains broken, ROI starts feeling more like Return on Inconvenience. If v3 lands before those tools are fixed, it’ll just be legacy bugs in a new UI suit. @Patrick Connor I appreciate the effort put into patch 2.6.4 — and I genuinely mean that. Still, when trivial fixes land into the patch while core features remain broken for an extended period, it feels misaligned. Hopefully things can get back on track. Perhaps with the help of new blood in the dev team.

Hi and welcome to the forum! @YMot. Just letting you know I ran some tests to verify what you described: 🧪 My test setup Created a Book file with 4 chapters: Chapters 1, 2, and 4 each have 6 pages (even) Chapter 3 has 5 pages (odd), to trigger a padding case All chapters use Facing Pages and Start on Right System: Windows 11 Pro 24H2 App: Affinity Publisher 2.6.3 (MSI EXE build, not MSIX) 🔍 What I observed Export as All Chapters as Pages ❌ No blank pages were generated. Even with “Merge Where Possible” and “Pad” turned on under the book’s Stray Pages options Export as All Chapters (Spreads) ✅ Blank pages were added correctly ➤ For example, two empty pages were inserted after Chapter 2 so that Chapter 3 could start on a right-hand page 🧩 Is this a bug? I'd agree with your take — since Pad and Merge are Book-level behaviors, as for me they should apply regardless of whether the export is set to Pages or Spreads. And again, great catch! 👍

The Quick FX panel in Affinity Designer is basically used to apply effects using a simplified set of the most commonly used settings for specific effects, rather than the full range available in the main Layer Effects panel. ⚠️Note: I might be wrong but in Affinity Photo and Publisher Quick FX panel is hidden by default—you can enable it via: Window > Quick FX For a basic overview of the Quick FX panel, see: Quick FX panel↓ https://affinity.help/designer2/English.lproj/index.html?page=pages/Panels/layerFxPanel.html&title=Quick%20FX%20panel For more in-depth guidance on how to use and customize effects, including explanations of each setting, check: Using layer effects↓ https://affinity.help/designer2/English.lproj/index.html?page=pages/LayerFX/create_layerFX.html&title=Using%20layer%20effects Below are direct links to individual effect pages: 3D Effect → https://affinity.help/designer2/English.lproj/index.html?page=pages/LayerFX/layerFX_3D.html&title=3D%20Effect Bevel / Emboss → https://affinity.help/designer2/English.lproj/index.html?page=pages/LayerFX/layerFX_bevelEmboss.html&title=Bevel/Emboss Colour Overlay → https://affinity.help/designer2/English.lproj/index.html?page=pages/LayerFX/layerFX_clrOverlay.html&title=Colour%20Overlay Gaussian Blur → https://affinity.help/designer2/English.lproj/index.html?page=pages/LayerFX/layerFX_gaussianBlur.html&title=Gaussian%20Blur Gradient Overlay → https://affinity.help/designer2/English.lproj/index.html?page=pages/LayerFX/layerFX_gradientOverlay.html&title=Gradient%20Overlay Inner Glow → https://affinity.help/designer2/English.lproj/index.html?page=pages/LayerFX/layerFX_innerGlow.html&title=Inner%20Glow Inner Shadow → https://affinity.help/designer2/English.lproj/index.html?page=pages/LayerFX/layerFX_innerShadow.html&title=Inner%20Shadow Outer Glow → https://affinity.help/designer2/English.lproj/index.html?page=pages/LayerFX/layerFX_outerGlow.html&title=Outer%20Glow Outer Shadow → https://affinity.help/designer2/English.lproj/index.html?page=pages/LayerFX/layerFX_outerShadow.html&title=Outer%20Shadow Outline → https://affinity.help/designer2/English.lproj/index.html?page=pages/LayerFX/layerFX_outline.html&title=Outline Hopefully this gives you a useful starting point — and leads to a few more insights along the way. Good luck.

You're absolutely right — I did say I’d leave it there. And I meant it. But when someone publicly questions the authorship of my words and implies I’m not even the one speaking — that’s no longer a debate. That’s a personal insinuation. And I believe it’s fair to respond when the conversation shifts from ideas to identity. So no — I didn’t return to argue. I responded to clarify. My position on the UX topic remains exactly where I left it: clear, reasoned, and open to interpretation by others. Now I’m truly done.

“End of discussion”? That’s not how discussions work. You don’t get to declare them over just because you’ve run out of arguments. This isn’t a courtroom, and you’re not the judge. If your only closing move is to dismiss a well-reasoned position with a vague “AI” accusation and a mic drop — that’s not confidence. That’s retreat dressed as authority. Let me be crystal clear: No, my statements were not generated by AI. Every word, every analogy, every argument — that’s me. My experience, my reasoning, my voice. If it sounds structured and coherent, that’s not because a machine wrote it. It’s because I’ve spent years thinking critically, working with real users, and learning from real design teams. I don’t need AI to sound intelligent. And apparently, that’s enough to make some people uncomfortable. So if you’re done, fine. But don’t pretend you’ve “exposed” anything because you haven't. You've simply run out of counterarguments.. The discussion doesn’t end because you say so. It ends when the arguments stop landing. And judging by your exit line, mine are still standing.

Let’s be precise — because your analogy doesn’t just miss the mark, it misrepresents the entire structure of the interface. You're comparing the “Document” menu — a top-level, structural command hub — to contextual panels and toolbars designed for real-time property adjustments. That’s like confusing the building’s blueprint with the light switch. Font size, leading, blend modes — these belong in toolbars and panels because they’re dynamic, localized, and frequently changed. No one expects them in the main menu bar. But “Document Setup” is not a contextual tweak — it’s a structural configuration. It opens a dialog that defines the document’s core properties: margins, bleed, units, page size. That’s exactly the kind of function that belongs in a top-level menu — and if a “Document” menu exists, that’s the most intuitive place for it. Saying “menus can’t hold everything” is a distraction. No one’s asking them to. We’re talking about a single, high-level function — and placing it where the user naturally expects it. Dismissing UX as a “boondoggle” doesn’t make you sound bold — it makes you sound out of touch. UX isn’t decoration. It’s the scaffolding that holds usable software together. It’s the reason people don’t throw the app out the window — and the reason they come back to it the next day. Ignore it if you want — just don’t expect users to stick around while you figure out why they’re leaving. I’ll let the thread speak for itself. My position is clear. I’ll leave it here and let others take from it what they will.

Thanks for sharing your view @Oufti — and I get it. Habits built over 35 years can feel like second nature. But in UX, familiarity doesn’t always equal optimality. Your metaphor — salt and pepper by the stove — perfectly illustrates habitual placement, not contextual logic. If we redesign a kitchen so the spices live in a dedicated drawer called “Flavour”, would it confuse people? Maybe — but if it’s clearer, faster and used consistently across the entire kitchen, it becomes the new standard. That’s exactly what we’re discussing here. Affinity Publisher has a “Document” menu. That menu isn’t decorative — it's part of the interface hierarchy. When a user wants to set up a document — size, margins, bleed — it's only natural they look in “Document”, not “File”. Why? Because their goal isn’t about files. It’s about the thing they’re working on: the document. The fact that legacy apps placed “Page Setup” in “File” doesn’t mean it’s the right choice today. UX has evolved. Modern interfaces prioritize cognitive flow over legacy conventions. The original poster was confused. That confusion isn’t invalidated by your personal routine — it confirms a mismatch between expectation and placement. And that’s a UX problem. So while your experience is valid, it’s one lens. UX doesn’t design for memory muscle — it designs for task efficiency, semantic clarity and cognitive intuition. If menus like “Document” exist, they should hold document-related actions. If we respect context, not habit, users stop asking why something isn’t where they expect — and simply do what they came to do. That’s not novelty. That’s good UX.

Right — we don't admire David because of the chisel. We admire it because the chisel never stood in the way. Mastery is visible when tools become invisible — but only when they’re precise enough to disappear. Saying “the tools were adequate” isn’t neutral. It’s a choice to accept limits instead of question them. And yes, some professionals can work around those limits. But let’s not confuse “getting things done” with having tools that truly support mastery. Especially when bugs linger, key features underperform, and the development pace stalls. Not every professional wants to wrestle their workflow into submission. Some simply want tools that match the level they work at — without friction, without blind spots. Because real craftsmanship isn’t just about delivering — it’s about delivering with confidence, clarity and control. The best tools don’t just disappear. They evolve. Mastering tools doesn’t define professionalism. But it absolutely reflects it. Because professionals don’t just use what’s in front of them — they understand it, refine it, and remove its limits where they can. You can be skilled and still unaware of what better tools can offer. But true professionals go further: they don’t just work despite the tool — they master it so the tool stops being part of the problem. Knowing the camera isn’t what makes you a filmmaker. But knowing how to make it speak for you is exactly what separates the serious from the casual.

Michelangelo didn’t carve David with his bare hands — and he didn’t pick just any chisel. He chose tools that allowed mastery to become visible. Great work makes us forget the tools — but only when the tools never stood in the way. So no, the point isn’t to discredit anyone using Affinity professionally. It’s to challenge the idea that tools don’t matter — when every professional knows that what they use either sharpens their craft or dulls their edge. You can work brilliantly with any tool. But let’s not pretend it’s irrelevant. If the goal is to get it done — almost anything will do. If the goal is to make it right — what you use starts to speak volumes.

Yes — professionalism begins with the person. But it doesn’t end there. A true professional aligns personal standards with the tools that elevate them. Because no matter how skilled you are, your output is shaped by what you work with. Even the sharpest mind can be dulled by a blunt tool. And those who value their craft often choose instruments that match their ambition. Not because tools make them skilled — but because they refuse to let limitations define their output. After all, if professionalism lives in you, why not let your tools show it?

Thank you for your summary, @Pyanepsion. Let me respond point by point — no metaphors, no packaging jokes — just UX, in its clean, practical form. “Coherence, clarity and predictability remain the foundations of sound interface design — not lexical proximity.” Sounds great. But in reality, it’s language and context that guide the user toward their goal. When they see “Document”, they’re not dissecting taxonomy like container vs content — they click it, because they want to change the document. That’s not lexical laziness — it’s a designed cognitive shortcut, supporting intuition and reducing decision time. In UX, language doesn’t conflict with logic — it drives it. “And that is precisely why, @BBrother, so many professional tools — and so many users — do not follow your reasoning. → And have not done so for nearly half a century.” UX is not a heritage museum. It evolves with users, technology and context. Quoting a fifty-year lineage of menu structures doesn’t validate anything — it simply proves that some tools are still clinging to habits born before human-centered design existed. Today’s UX doesn’t preserve what’s old — it improves what’s useful. Affinity Publisher has a “Document” menu. Therefore, users expect to find document settings inside it. That’s not confusion — it’s behavioral design. “You are now defending the opposite of your own arguments, simply to avoid acknowledging the obvious.” Absolutely not. I’ve been consistent from the start: functions should be placed where the user naturally expects to find them. If “Document Setup” adjusts aspects of a document — and a “Document” menu exists — that’s where it belongs. If the menu doesn’t exist, as in Designer, then “File” is a reasonable home. Simple. Contextual. Consistent — with human cognition, not legacy data hierarchies. And speaking of consistency… I even proposed a clear alternative: rename the “Document” menu to “Pages”, since most of its contents focus on page-related actions. That removes ambiguity. When users see “Pages”, they understand it’s about pagination — and “Document Setup” can reside under “File” without contradiction, just as it does in Designer. That’s true consistency: not duplication, but adaptation to context, serving clarity above replication. “And evidently, you did not grasp the reference to the packet of sweets, nor the one about the banana peel — though both were perfectly clear.” Bananas are tasty, sure — but they’re not an interface design model. And while metaphors can be helpful, they shouldn’t replace testing, behavioral observation or actual UX logic. Yes, I used one too — the misplaced milk analogy. But mine wasn’t decorative or whimsical. It was a functional metaphor, grounded in how users actually behave when searching for something they expect in a logical place. So let’s be clear: I don't argue with fruit metaphors. I argue with any design approach that makes the user stop, think, and wonder if they’re in the wrong menu — instead of simply acting. Because good UX doesn’t entertain. It works. “This is no longer a discussion — it’s a loop.” No — it’s still a discussion. It turns into a loop only when arguments run dry and theoretical positioning replaces practical empathy. UX isn't closed by declarations — it’s guided by observation, adaptation and iteration. UX isn’t about preserving system purity. It’s about designing for human cognitive maps. Your map leads to the file. Mine — to the human. And one more thing: The best UI is the one the user doesn’t notice. If users have to stop, ask themselves where a setting might be, and question whether margins are “container or content” — they notice. And when they notice, the design has failed. And let’s be honest — the structure you're defending leads exactly to that moment. It invites users to second-guess themselves, navigate across mismatched menus, and debate internal logic instead of simply working. It’s a cognitive detour disguised as interface clarity. That’s not clarity. That’s friction, dressed as structure.

**Professionalism isn't a whim — it's ambition encoded into the tool**. And if someone doesn't see that, perhaps it's time to look not just at what works, but why so many people care that it works better. Efficiency and quality aren’t optional upgrades — they’re respect for your own craft. Treating professionalism like a decorative extra is like pretending precision doesn’t matter as long as something technically functions. That might pass in a doodle — not in real work where results, deadlines, and trust are on the line.

🧠 User-first logic: clarity before taxonomy Let’s drop the semantics and focus on human behavior. When users see a “Document” menu and want to change their document’s layout, margins, or size — they’ll intuitively look there. Not under “File.” Not because they’ve read UI documentation, but because humans follow naming and context. This isn’t just about interface tidiness — it’s about cognitive flow. As Steve Krug famously said: “Don’t make me think.” Users aren’t pondering the structural taxonomy of content vs container. They just want to adjust the document — and go where the label takes them. That’s why placing “Document Setup” under “Document” (when such a menu exists) reduces mental load and shortens the decision path. That’s not confusion. That’s good UX. 🗂️ False equivalence: Save ≠ Setup You argue that if we follow the logic i propose, Save/Export/Print should also move under “Document.” That’s a flawed comparison. Those functions are almost universally anchored in the “File” menu — for decades now — and are part of long-standing mental models. They belong there because users expect them there. “Document Setup,” on the other hand, is about changing a document’s core structure. And if a “Document” menu exists, that’s exactly where users will try first. Hiding it under “File” simply adds unnecessary friction. Let’s not confuse long-term convention with forced categorization. 🍌 Bananas and interfaces Thanks for the banana split. I’ll try not to slip. No — I’m not confusing the peel with the fruit. I’m simply saying that users don’t dissect bananas before eating them. They don’t debate whether margins are content or container. They follow what makes sense in front of them. In UI terms: if there’s a “Document” menu, they expect document settings there. It’s not “confusing the wrapper” — it’s following intuition. And good design should meet that intuition, not resist it. ♻️ Flexible consistency beats rigid duplication (once again) Modern UX design celebrates context-aware consistency — not UI duplication at all costs. What works in one app might feel clunky in another. Affinity Publisher has a “Document” menu. Designer does not. Forcing identical menu structures despite that difference reduces clarity, not enhances it. Consistency is useful only when it supports human logic. When it overrides it — it becomes an obstacle. 🧩 Alternative: Rename “Document” to “Pages” Now, here’s a compromise worth considering. If the current “Document” menu mostly contains page-level actions — like Add Page, Go to Page, View Masters — then renaming it to “Pages” would make its purpose crystal-clear. In this case, keeping “Document Setup” under “File” becomes more acceptable — because there’s no longer a competing “Document” label to mislead the user. It even aligns better with Affinity Designer, which doesn’t have a “Document” menu either. This move would: Remove ambiguity from the UI Improve discoverability Maintain cross-app consistency without sacrificing clarity It’s not about chasing purity — it’s about serving the user. Just to clarify — I work closely with UX/UI designers on a regular basis. While my main focus is backend development (PHP is my home turf), I started out on the front end — HTML, CSS, JS, visual design — so I’ve always approached interface logic with a practical, user-centered mindset. This isn’t theoretical for me. I’ve seen firsthand how even small changes in menu logic can either streamline the experience — or slow users down. So when I say that local logic matters, I mean it quite literally: it impacts people’s time, decisions, and overall flow.

🧠 User intuition comes first Users don’t study interface documentation to decide where something should be. They follow names and context. If something relates to a document and there’s a “Document” menu — they’ll **click there**. This isn’t about “terminology convenience” — it’s a cognitive shortcut that: reduces decision time, lowers mental friction, speeds up action. As Steve Krug put it: “Don’t make me think.” The interface should be intuitive enough that users don’t stop to ask: “Do margins count as content or container?” They don’t think in those terms — they just want to change the document. That’s it. 🗂️ Local logic vs. unification From the perspective of modern UX standards, the approach I’m proposing better aligns with human-centered design. Interface design should adapt to the user’s intuition — not the other way around. What improves UX in one app may not make sense in another. Since Publisher has a “Document” menu and Designer does not, placing “Document Setup” under “Document” in Publisher is simply local logic done right. This isn’t a breach of consistency or standard — it’s an intelligent, user-first adaptation. ♻️ Flexible consistency: the golden standard Modern UX embraces flexible consistency — consistency that is context-aware and adaptive: Interfaces shouldn’t be blindly mirrored across apps, Instead, they should be designed to make sense to humans in their specific context. Local logic takes priority when it: enhances intuitiveness, simplifies decision-making, shortens the path to completing a task. That’s what real consistency looks like — not cloned menus, but a consistent principle: “Go where the context leads you.” Because consistency only adds value when it supports intuition. When it suppresses it — it becomes an obstacle.

With all due respect @Pyanepsion to this opinion, it is worth noting that dividing the functionality of the Document menu solely into "content operations" (e.g. pages, objects) while excluding "container settings" (page size, margins, bleeds, etc.) is an artificial limitation that finds no justification in either the logic of the interface or the user's expectations. 🔍 The user does not think in terms of container and content For the user, the document is one coherent whole. The mental model of how the interface works says: "I want to change something in the document", not: "does this function concern the content or the frame (container)". In this logic, both Add Page and Document Setup, Margins or Facing Pages are simply functions on the document. 🧂 Artificial consistency between apps hurts UX It's understandable to strive for consistency between apps in a suite, but: Affinity Designer doesn't have a Document tab → Document Setup goes to File out of necessity. Affinity Publisher has Document — and that's where Document Setup logically and functionally fits in. 👉 Putting it under File just to “make it consistent with Designer” is like keeping milk in the spice drawer because that’s what they did in the neighboring kitchen. Sounds coherent. But no one will thank you when they want to make coffee. 🔧 Bottom line: Consistency can't mean duplicating mismatched solutions. A better form of consistency is consistent logic that works in each app in its own context. Document Setup should be where the user naturally expects it—in the Document menu, if it exists. Simple layout, more intuitive, less frustration.

In the Export dialog (Ctrl + Alt + Shift + S), Affinity allows users to define and save custom export presets (format, resolution, compression, etc.). Unlike most design tools that enforce only unique preset names, Affinity additionally blocks the Create Preset button when your parameter set matches any built-in preset. Why this is bad UX: User control and freedom are violated. Instead of allowing users to name whatever they save, the app forces arbitrary parameter changes to allow naming. This wastes designer time hunting for a tweak just to save a preset. The lack of explanatory messages makes users think it's a bug rather than an deliberate restriction, which ultimately leads to frustration. This breaks good industry conventions that users have become accustomed to over the years (Photoshop, Illustrator, Premiere, Sketch) —none of them block presets based on settings; they only enforce unique names. Proposed solutions: Validate only preset names. Block saving only if the name already exists. Allow unlimited duplicates of any parameter set. Provide Clear Feedback (Messaging). On name collision, show: > “A preset with this name already exists. Please choose a different name.” Current UX couples naming to parameter uniqueness, creating needless friction. By switching validation to names only—and adding clear feedback—Affinity would restore user control, speed up workflows, and align with industry best practices. Please update the Export dialog to remove the “Create Preset” roadblock.

Yup I'm totally agree with that. I think this contour tool bug is an extension of the Expand Stroke issues introduced & known since 2.5 update and that have not been fixed either. This is now hitting over a year since 🤬 Just to let you know @Dan-R head of QA revealed that they plan to release an 2.6.4 patch (beta) early this month to address regressions from previous releases so the so the big question is will they finally fix it. Announced in the post from the link below: https://forum.affinity.serif.com/index.php?/topic/232389-too-quiet-%E2%80%A6/&do=findComment&comment=1382645

I'm glad that instead of pushing out another update with new features, the decision was made to release a patch to address ongoing issues. It's about time the regressions in the Contour and Expand Stroke tools—introduced back in the 2.5 update—finally got the attention they deserve. These bugs have been around for over a year now 😤😞

Environment: Windows 11 Pro 24H2 Affinity Publisher 2.6.3 (MSI/EXE) Hardware acceleration disabled Up-to-date GPU drivers Bug: Somehow the action of switching between documents causes the Pages panel to often fail to clear the gray frame around the previous (old) active page when you change it to a different one. Even though the problem occurs frequently, is easy to reproduce, just play around and switch documents and change active pages, I have not found a pattern or reason why the redraw problem occurs other than it is related to the document switching action. Expected Behavior: Whenever the active page or spread changes - regardless of whether it happened after switching documents - the Pages panel should update and show the correct single active page and a gray border around it, clearing the previous one. Workarounds: Temporarily switching to another document and returning will force a redraw and fix the problem by leaving a gray border indicating the active page around the correct thumbnail. Double-click the thumbnail of the correct active page again and this will force a redraw, clearing the previous one. Attachments: Screen recording of the workflow and glitch. 2025-07-03_11-46-45.mp4

Because resampling still occurs, and that’s where quality loss happens — not due to oversizing, but due to scaling and rasterization during export. Here's what’s going on under the hood: 🔍 Step-by-step breakdown: The original 100×100px.jpg is placed into a 90×90px artboard. To fit, it’s scaled down by 10% in both dimensions. This scaling is non-destructive in the document — the image is still linked or embedded at full resolution, but visually transformed. At export, Affinity rasterizes the entire artboard. Even if the export size matches the artboard (90×90px), Affinity must rasterize the scaled image to flatten it into the final JPEG. This is where resampling happens, and the chosen algorithm (e.g. bilinear, bicubic, Lanczos) determines how pixel data is interpolated. JPEG compression adds another layer of degradation. JPEG is a lossy format — even at high quality settings, it introduces artifacts, especially around edges and gradients. Scaling down ≠ perfect quality. While scaling down is generally better than scaling up (because you’re reducing data, not inventing it), it still involves discarding pixels. Even with an excellent resampling algorithm, fine detail can soften slightly. ✅ How to improve the result: ✅ You're already using Lanczos 3 (non-separable) — a great choice, as it preserves sharpness better than bilinear or bicubic. So no changes needed here. 🟢 Consider exporting to PNG instead of JPEG if you want to avoid compression artifacts entirely. 🟢 Avoid unnecessary transformations in the artboard itself. If possible, match the artboard size to the image or vice versa — this eliminates the need for resampling altogether. 🟢 Alternatively, rasterize manually before export if you want precise control over scaling — though note that Affinity uses a simpler algorithm (usually bilinear) when rasterizing this way. 🖥️ A quick note on DPI: Even though your export is set to 400 DPI, keep in mind that DPI has no effect on how the image appears on screen. It’s just metadata used for print. What truly determines visual quality on digital displays is the pixel resolution — in this case, 90×90 px. So whether you export at 72, 300, or 400 DPI, the image will look the same on a monitor or in a browser. DPI only matters when the image is printed, as it defines how densely those pixels are packed per inch on paper. And trust me — I’ve been working with raster graphics and export pipelines for over a decade. This stuff still surprises people.

I'm using this right. Also i tested and used your steps. To clarify couple things: The logic that is used in that panel is that the »Align to:« drop-down cannot be set until you make the alignment. After you make the alignment the drop-down gets unlocked and you can choose the option you like. It's not intuitive but this is how its designed. As it goes to key object as I said before, First Selected must be set to use the key object as reference. There is no bug here and align to key object is working as designed. The only thing that can be criticized is that it was designed in a non-intuitive way. 2025-03-03_06-04-55.mp4