Pyanepsion

Importing and exporting SVG files in Affinity Designer reveals several structural shortcomings that significantly limit the format’s usability in modern production workflows. I. Issues with SVG handling in Affinity – References not preserved: The xlink:href or href attributes, used to replicate elements without duplicating code, are neither recognised on import nor reinstated on export. Each instance is converted into a complete copy, nullifying the benefits of structural reuse and reduced file size. – Exported file size: SVG files generated by Affinity are often unnecessarily large and verbose, even for relatively simple documents. As another user also pointed out in a separate post¹, a well-structured SVG using approximately 200 references via href may result in a file of just 14 kB — while the same content exported from Affinity Designer can reach up to 16 MB, due to repeated full duplication of elements. This directly illustrates the structural inefficiency caused by the lack of reference reuse in Affinity’s SVG export. – Unexpected rounding and loss of precision: Bézier curves and coordinates are frequently approximated, leading to rounded shapes or slight distortions in the exported SVG. This compromises the visual fidelity and makes the output unreliable for use cases requiring vector accuracy. – Loss of <pattern> fills²: SVG files that include <pattern> tags cannot be properly imported into Affinity Designer, as the contents of the tag are not rendered. This means that SVG files created in other programmes cannot be correctly imported or edited in Affinity Designer. I consistently need to rework exported SVG files: I reduce their size by half, correct geometric inaccuracies, and document the structure, whether the files are intended for the web or for print publishing. It results in a considerable loss of time, and by extension, of money. II. Technical hypothesis These limitations suggest that Affinity’s SVG engine is based on an outdated and incomplete implementation — possibly derived from the original SVG 1.0 specification (W3C Recommendation, 2001), which was issued at a time when the format was still in its infancy. Many features introduced in later specifications (1.1, 1.2, and even the draft of SVG 2) do not appear to be supported. III. Industry impact and relevance Today, SVG is a strategic format across a range of industries: – Scalable vector graphics for user interfaces and games, – Laser cutting, CNC machining, and vector-based printing, – Web and mobile applications (particularly with libraries like D3.js and React), – Vector illustration workflows in AI image generation, prior to raster or 3D conversion. As it stands, Affinity’s support for SVG falls short of the needs of these professional contexts, especially when compared to open-source tools like Inkscape or proprietary software offering cleaner, more efficient exports. Conclusion The current SVG implementation is a major weakness in the Affinity suite. A thorough overhaul of the import/export engine — with full support for references, groups, symbols, and precise coordinates — would not only align the software with modern standards, but also unlock new professional uses. ¹ SVG xlink:href / SVG 2 href for reused elements inside a document to reduce export file size ² Please implement vector pattern fill in Affinity Designer

Hello @matt.baker, Would you be able to share the original SVG file, along with the steps you followed to produce the .afdesign document? That would help clarify the software’s behaviour and illustrate the issue more concretely.

📚 This discussion might serve as a gentle reminder that reasoning detached from reality tends to unravel when put to the test. At the very least, it has helped highlight that. And that, in itself, is worth something.

@bbrother, When professionals describe their actual workflow, and you respond with theories that are clearly AI-generated (we could even name which one)… the masquerade becomes obvious. End of discussion.

@bbrother — thank you for your detailed replies. Let’s now take a moment to clarify a few essential points, for the benefit of everyone following this discussion. 1. Steve Krug, an American based in Chestnut Hill, does not advocate following labels at the expense of logic. Quite the opposite. His well-known principle — “Don’t make me think” — means: “Design so clearly that the user never has to wonder.” It does not mean: “Place functions wherever the wording feels familiar.” What Krug (as well as Norman, Tidwell, Cooper…) consistently defend is this: A good interface does not maintain ambiguity — it resolves it. 2. The “Setup” menu acts on the container, not on the editorial structure. Changing a document’s size, margins, resolution or units affects the file itself, not its content. → That is precisely why its logical place is under File, alongside other global settings. Adding the label “of the document” is entirely appropriate, as it clarifies the scope of the command. → But it certainly does not justify a change of menu. 3. The “Document” menu is aptly named — but not everything containing the word “document” belongs in it. This menu is dedicated to editorial actions: adding pages, managing styles, navigating through sections… It is therefore perfectly legitimate and functionally sound. But that does not mean every command mentioning the word document must be placed there. → “Document Setup” modifies the container, not the editorial structure — which is why it rightly belongs under File. It is not the menu label that causes confusion, but an overly literal interpretation of it. In summary: Coherence, clarity and predictability remain the foundations of sound interface design — not lexical proximity. 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. You are now defending the opposite of your own arguments, simply to avoid acknowledging the obvious. 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. This is no longer a discussion — it’s a loop. Perhaps it’s time to consult the sources — the real ones — rather than argue from impressions.

@BBrother, we cannot follow you down that path. The distinction is clear, necessary and universal — even on digital game distribution platforms. Manufacturers who ignore it sooner or later adopt it… or vanish. Is that what you want, @BBrother? Here, have a banana split. And don’t worry — I haven’t confused the wrapper (the peel) with the content. 😊

One must always instruct with the right tools. 75% soft caramel, 25% cocoa. 😊

Thank you, @bbrother, for your response, which usefully clarifies the debate. We probably all agree on one essential point: user experience must take precedence. But that must be grounded in coherent logic, not in a superficial convenience of terminology. That a menu is labelled Document does not mean that everything related to the document must be placed there. Let me offer a concrete analogy: if you give someone a packet of sweets, no one would think to eat the wrapper simply because it, too, bears the word “sweets”. The distinction between what is consumed and what contains it is obvious — and it is just as obvious here. There is nothing artificial, then, in distinguishing: what relates to editorial content (pages, sections, styles), → which rightly belongs under Document; and what concerns the physical or digital properties of the file (page size, margins, resolution), → which naturally belongs under File. This structuring is anything but arbitrary: it has long been adopted by most software, especially in word processing and publishing (Adobe, Scribus, Microsoft, Jutoh, Soft-Logic…), because it promotes a clear, intelligible and sustainable interface. Affinity’s suite has nothing to gain by departing from these proven standards. And much to lose by clouding the interface in the name of a personal sense of consistency.

That sounds promising. Would you mind explaining how you did it?

The Document menu is traditionally intended, where it exists, for editorial or contextual actions. It includes: —options related to content, such as sections, pages, styles and navigation; —commands that affect the logical or narrative structure of the document; —and, in some cases, tools specific to page layout. → This menu operates on what the document contains, not on its ‘container’ (page size, resolution, etc.). The File menu, by contrast, is traditionally used for: —operations that apply to the document as a whole, such as opening, saving, exporting or printing; —global settings for the file, such as page format, margins, units of measurement, colour profiles or resolution. → These elements concern the physical structure of the file, which is why they are grouped under File, as it relates to the digital container of the document. As Ali rightly pointed out, there is also the Document Setup button, which is quite handy, as well as the Preferences button in both Affinity Publisher and Affinity Designer. This does not apply to Affinity Photo, since we are not dealing with a document, but with a working canvas.

@Oufti Thank you for the video. It helped me understand how to insert the required space relatively easily. @carl123 I would add that automatic replacement should also cover superscripts when they exist in the font: typing superscript 2 should replace it with ² (U+00B2); typing 1er should replace it with 1ᵉʳ (U+1D49 and U+02B3). This would greatly simplify the transcription of text across different platforms. @MikeTO The use of spacing before punctuation marks depends on the typographic conventions of each language or publishing style. It should not be integrated into the typeface. This is not the role of the type designer, but of the typographer. This idea that these conventions should be managed by the font itself is, I believe, an American conception, far removed from typographic practice anywhere else. 🤫Yes, until this limitation is addressed, we’ll still have to rely on regex-based find-and-replace. Alas. Microsoft Word already implements something similar using its AutoCorrect and so-called "Automath" dictionaries. These apply formatting or character substitution depending on the context. Affinity Publisher could adopt a comparable approach.

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.