Pyanepsion

This kind of improvement would indeed make perfect sense as part of the 2.7 update, rather than waiting for a full 3.0 upgrade.

Hello everyone, The arrival of QR codes in Affinity, with the integration into Canva, was a welcome improvement. It was expected, and it is certainly useful. However, time is passing, and the tool still remains too limited for truly professional use. Here are the main areas for improvement: – Narrow window: the field for entering the address is tiny, which makes it hard to read and verify. This is especially problematic for long URLs, which cannot be fully viewed or scrolled horizontally! – Visual appearance: the generated codes are very basic, with no option to enhance the design. This is surprising in software aimed at print and internet publishing. – Automatic linking: no hyperlink is associated with the QR code. It has to be added manually, which is time-consuming and prone to omission, especially in PDF files. – Hover effect: all links appear by default with an “Invert” highlight effect, often considered unattractive, with no option to choose a different style. – Error correction: it is not possible to adjust the redundancy level, which is essential in some contexts (damaged prints, complex textures, etc.). – Shapes and appearance: there is no option to customise the modules (rounded corners, circles, decorative styles), unlike what most other tools offer. – Logotype: it is not possible to insert a logo in the centre of the code — a very frequently used feature. Admittedly, it often raises legibility issues in competing tools. – Background: it is not possible to add a background behind the code (for example, a white square), which limits its readability on certain backgrounds. – Narrow window: the field for entering the address is tiny, which makes it hard to read and verify. – Styles and consistency: it is not possible to save a style or template for QR codes, which complicates consistency across multiple pages. – Master page limitation: unlike image frames, QR code frames placed on a master page cannot have their hyperlink edited individually on document pages. This prevents using them as dynamic placeholders, which would be especially useful for automating multi-page documents. – No automation: no function allows for generating several QR codes from a data source. Yet this is useful in personalised documents. A complementary tool, applying the same treatment options where appropriate, should also be considered alongside the QR code generator: – Barcodes: support for creating EAN or ISBN barcodes, which are essential in both print and web publishing. It is indeed time to bring this essential tool up to standard, as it has become important for many of us.

Hi, @Belleson, You made an excellent choice in adopting Affinity Publisher. It offers a much more professional working environment than general-purpose solutions. Equation editor Like you, I regret the absence of a proper equation editor. It would be an extremely valuable addition, particularly for technical and scientific documents. While Serif does not appear to prioritise this feature at present, it could significantly expand the software’s potential use cases. Perhaps you might consider supporting your request with examples of real-world needs, target demographics, and potential user benefit? Out of interest, how are you currently handling equations within Publisher? Automatic figure numbering and cross-referencing As for automatic figure numbering and cross-referencing, there are indeed indirect methods available, as @MikeTO has clearly explained. While not native, they are entirely feasible with a disciplined workflow. However Allow me, however, to nuance some of your comparisons. For professionals in editorial work, LibreOffice remains highly limited. Microsoft Office is markedly superior in terms of typographic precision, automation, and stability. In fact, many practitioners prefer not to accept ODT files, as the time required to correct them far exceeds their usefulness. Lastly, Affinity Publisher is not a successor to PageMaker, which was discontinued in 2004. It is better understood as a modern evolution of InDesign, itself the successor to QuarkXPress. Desktop publishing bears little relation to word processing: word processors serve us, as layout artists and typesetters, merely as a starting point—never as a final formatting tool. Have a great day,

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 ³ Please create QR code with swquare hol for logos inside

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.