Pyanepsion

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.

I believe it has now been at least ten years since the ICO format—essential though it is—was first noted as unsupported in the Affinity suite. Let there be no misunderstanding: although this limitation concerns a narrowly defined use case, it presents a very real challenge in certain professional environments. This gap has been addressed, without exception, by competing software. Overview of standard icon sizes and formats by platform : Affinity Designer, Photo and Publisher are widely recognized for their robustness, accessibility and professional quality in handling both raster and vector graphics. Their growing adoption across creative industries attests to their functional maturity. However, certain essential but narrowly defined needs—particularly those involving digital environments such as web browsers, operating systems and application shortcuts—are still not fully supported. A format still in active use Despite its age, the ICO format remains essential for: —traditional favicons (notably for Internet Explorer, Firefox, legacy CMSs and web themes); —Windows application icons; —shortcuts and desktop integrations on various platforms. It is the only standardized format recognized by both web browsers and operating systems that allows multiple raster icon resolutions (such as 16 × 16, 32 × 32, 48 × 48, 64 × 64, 256 × 256) to be embedded within a single file. This ensures broad compatibility and automatic adaptation depending on the display context (e.g. tab icon, desktop shortcut, high-resolution screen, etc.). Market Reality A wide range of software applications—both free and commercial—now support ICO export natively or through official extensions. This includes GIMP, IrfanView, XnConvert, IcoFX, Greenfish Icon Editor and many others. Notably, even Adobe Photoshop—Affinity’s primary competitor—has long offered ICO exports via its official plugin. Their continued support for the format clearly demonstrates that demand remains steady and that ICO is far from obsolete. While technically correct, this entirely misses the real issue Some might argue that there are plenty of tools available to convert PNG files to ICO. While this is technically true, it misses the point entirely. Affinity is positioned as a professional, self-contained creative suite — not a toolkit requiring external utilities for basic industry-standard outputs. Relying on third-party converters introduces workflow fragmentation, quality risks (such as transparency loss or incorrect sizing), and in some cases, legal uncertainties when using online tools. The need for ICO export is not a fringe request, but clearly a core expectation for any graphic tool used in interface, application or web design. Summary The lack of ICO format support in the Affinity suite: —limits adoption among certain web and software professionals; —requires unnecessary manual steps or dependence on external tools; —contradicts the aim of providing a complete, self-contained creative environment. Conclusion It would be highly valuable for Serif to consider implementing ICO as a native export format, particularly within Affinity Designer. While it may be a specialised format, ICO addresses a persistent need in digital and web design. Its inclusion would strengthen Affinity’s promise of delivering a robust, coherent and professional solution—without workflow interruptions. I remain at your disposal should you wish for additional feedback or examples, and thank you sincerely for your attention and for the quality of the tools you continue to develop.

Yes. Serif does not seem to realise the importance of this market, even though Affinity Designer was the first software to mark Serif’s strong comeback with the Affinity suite. Uses and requirements of optimised vector graphics Vector graphic creation tools are used by a wide range of professionals from technical, creative and industrial sectors. Among the main users are: Graphic designers and illustrators : visual identities, publishing, posters, Print professionals : prepress, packaging, Web designers and developers : icons, SVG-based interfaces, Architects and planners : stylised plans, diagrams, Textile and embroidery professionals : designs for printing or cutting, Teachers and researchers : diagrams, maps, educational visuals, Communication and marketing departments : coherent promotional material, Small businesses and microenterprises : often via simplified tools, And most importantly, digital cutting professionals : plotters, CNC machines, laser engravers. In the latter case, the precision and cleanliness of the SVG file are critical, as these machines require a perfectly clean path that can be interpreted without ambiguity. Why must an SVG File truly be clean, error-free, and free of unnecessary tags? A messy, error-ridden, overly verbose or repetitive code is simply rejected by most of the professional users listed above. The following criteria are generally expected: 1. Technical reliability Cutting or printing machines do not tolerate duplicates, invisible paths or stray elements. These may lead to errors, wasted time or wasted materials. 2. Cross-software compatibility An optimised code ensures correct interpretation across all environments: Affinity Designer, Inkscape, Illustrator, LightBurn, and others. 3. Lightness and performance Removing redundant styles (using CSS classes), empty groups or useless objects significantly reduces file size and improves workflow fluidity. 4. Readability and maintenance A well-structured file is easier for others to edit, easier to fix quickly, and more readily reused in other projects. Maintenance becomes far too costly with the SVG source code exported by Affinity Designer. 5. Scalability A clean SVG code integrates more easily into automated pipelines, graphic libraries, or websites. It becomes a reliable and reusable component. One example among many The future logotype of my firm originally used four colours from a palette created by the designer. Two colours were later changed. With clean SVG code, the modification took just a few seconds — simply updating the values of the two relevant CSS colour classes. The same change took 45 minutes in Affinity Designer. Worse still, editing the SVG it exported was an utter headache, due to its convoluted structure. This Requirement is now recognised by Artificial Intelligence SVG code quality has become such a concern that advanced AI models — such as Claude developed by Anthropic — have integrated dedicated modules for generating or optimising SVG files. This reflects not only the increasing complexity of expectations around the format, but also the essential need for code that is readable, lightweight, and reusable — in a word, clean. It is no longer merely a matter of human usage, but of interoperability with automated and intelligent systems. It is time to act.

Contour, that's a tool I didn't understand. Thank you very much, @Bryan Rieger. The stroke tool is an adjustable but non-destructive wrapping around a line. The contour tool modifies or creates a new vector shape, enlarged or reduced as required.

Hello, I have a vector shape in Affinity Designer, and I’d like to enlarge it uniformly by 10 px all around, a bit like adding a 10 px border. However, adding a stroke does not meet my needs, as the ends then become pointed, rounded or broken, which changes the appearance of the shape. What I’m looking for is a real extension of the shape itself, with a clean, regular and controllable edge, without resorting to a line or a temporary effect. Is there a specific method in Affinity Designer for achieving this? I would like to keep a vector shape at the end, not an image or a styling effect. Thank you in advance for your help. stroke.afdesign

Version 2.6.2.3213. Hello everyone, The following code has been generated by the Affinity Suite. Although it is usable in its current form, it contains errors that must be corrected, along with a number of essential optimisations. These adjustments significantly reduce development time, simplify maintenance, improve compatibility with both web and industrial tools, and accelerate rendering and printing. Context: File intended for print and internet use, created with Serif (Affinity). Compatibility with cutting or engraving systems is also considered. 0. original and optimization Original created by the Affinity suite. <?xml version="1.0" encoding="UTF-8" standalone="no"?> <!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd"> <svg width="100%" height="100%" viewBox="0 0 915 915" version="1.1" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" xml:space="preserve" xmlns:serif="http://www.serif.com/" style="fill-rule:evenodd;clip-rule:evenodd;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:1.5;"> <rect id="Background" x="-0" y="-0" width="914.667" height="914.667" style="fill:#407336;"/> <rect id="Lower-recurring-elements" serif:id="Lower recurring elements" x="121.333" y="644" width="653.333" height="93.333" style="fill:#fffffc;"/> <rect id="Recurring-elements-left" serif:id="Recurring elements left" x="121.333" y="289.333" width="93.333" height="336" style="fill:#fffffc;"/> <rect id="Recurring-elements-top" serif:id="Recurring elements top" x="121.333" y="177.333" width="672" height="93.333" style="fill:#fffffc;"/> <path id="Small-gear" serif:id="Small gear" d="M321.54,366.086l4.46,17.37c8.632,1.057 17.091,2.871 25.227,5.408l14.719,-13.259c8.236,2.996 16.09,6.623 23.452,10.832l-6.994,16.827c6.815,4.368 13.008,9.322 18.467,14.774l21.034,-5.595c5.261,5.889 9.795,12.172 13.54,18.761l-16.574,11.776c3.172,6.508 5.439,13.276 6.76,20.181l21.713,3.568c0.875,7.204 0.875,14.46 -0,21.664l-21.713,3.568c-1.321,6.905 -3.588,13.673 -6.76,20.182l16.574,11.775c-3.745,6.589 -8.279,12.872 -13.54,18.761l-21.034,-5.595c-5.459,5.452 -11.652,10.406 -18.467,14.774l6.994,16.827c-7.362,4.209 -15.216,7.836 -23.452,10.832l-14.719,-13.259c-8.136,2.538 -16.595,4.351 -25.227,5.408l-4.46,17.37c-9.005,0.7 -18.075,0.7 -27.08,0l-4.46,-17.37c-8.632,-1.057 -17.091,-2.87 -25.227,-5.408l-14.719,13.259c-8.236,-2.996 -16.09,-6.623 -23.452,-10.832l6.994,-16.827c-6.815,-4.368 -13.008,-9.322 -18.467,-14.774l-21.034,5.595c-5.261,-5.889 -9.795,-12.172 -13.54,-18.761l16.574,-11.775c-3.172,-6.509 -5.439,-13.277 -6.76,-20.182l-21.713,-3.568c-0.875,-7.204 -0.875,-14.46 0,-21.664l21.713,-3.568c1.321,-6.905 3.588,-13.673 6.76,-20.181l-16.574,-11.776c3.745,-6.589 8.279,-12.872 13.54,-18.761l21.034,5.595c5.459,-5.452 11.652,-10.406 18.467,-14.774l-6.994,-16.827c7.362,-4.209 15.216,-7.836 23.452,-10.832l14.719,13.259c8.136,-2.537 16.595,-4.351 25.227,-5.408l4.46,-17.37c9.005,-0.7 18.075,-0.7 27.08,0Zm-13.54,89.075c15.454,0 28,10.037 28,22.4c0,12.363 -12.546,22.4 -28,22.4c-15.454,0 -28,-10.037 -28,-22.4c-0,-12.363 12.546,-22.4 28,-22.4Z" style="fill:#fffffc;stroke:#407336;stroke-width:7.78px;"/> <path id="Large-gear" serif:id="Large gear" d="M609.665,318.208l7.434,28.951c14.385,1.761 28.485,4.783 42.044,9.013l24.532,-22.099c13.727,4.993 26.818,11.039 39.087,18.053l-11.657,28.046c11.358,7.279 21.68,15.537 30.779,24.623l35.057,-9.325c8.767,9.815 16.325,20.287 22.566,31.269l-27.623,19.625c5.287,10.847 9.065,22.127 11.266,33.636l36.188,5.947c1.459,12.007 1.459,24.099 0,36.106l-36.188,5.947c-2.201,11.509 -5.979,22.789 -11.266,33.636l27.623,19.625c-6.241,10.982 -13.799,21.454 -22.566,31.269l-35.057,-9.325c-9.099,9.086 -19.421,17.344 -30.779,24.623l11.657,28.046c-12.269,7.014 -25.36,13.06 -39.087,18.053l-24.532,-22.099c-13.559,4.23 -27.659,7.252 -42.044,9.013l-7.434,28.951c-15.009,1.166 -30.124,1.166 -45.133,-0l-7.433,-28.951c-14.386,-1.761 -28.486,-4.783 -42.045,-9.013l-24.532,22.099c-13.727,-4.993 -26.817,-11.039 -39.086,-18.053l11.656,-28.046c-11.358,-7.279 -21.679,-15.537 -30.779,-24.623l-35.056,9.325c-8.768,-9.815 -16.326,-20.287 -22.567,-31.269l27.623,-19.625c-5.286,-10.847 -9.064,-22.127 -11.266,-33.636l-36.188,-5.947c-1.458,-12.007 -1.458,-24.099 0,-36.106l36.188,-5.947c2.202,-11.509 5.98,-22.789 11.266,-33.636l-27.623,-19.625c6.241,-10.982 13.799,-21.454 22.567,-31.269l35.056,9.325c9.1,-9.086 19.421,-17.344 30.779,-24.623l-11.656,-28.046c12.269,-7.014 25.359,-13.06 39.086,-18.053l24.532,22.099c13.559,-4.23 27.659,-7.252 42.045,-9.013l7.433,-28.951c15.009,-1.166 30.124,-1.166 45.133,0Zm-22.566,148.459c25.756,-0 46.666,16.728 46.666,37.333c0,20.605 -20.91,37.333 -46.666,37.333c-25.756,0 -46.667,-16.728 -46.667,-37.333c-0,-20.605 20.911,-37.333 46.667,-37.333Z" style="fill:#fffffc;stroke:#407336;stroke-width:7.78px;"/> <rect id="Masking" x="737.333" y="177.333" width="93.333" height="560" style="fill:#407336;"/> </svg> Optimized version written in VS Code <?xml version="1.0" encoding="UTF-8"?> <svg width="100%" height="100%" viewBox="0 0 915 915" version="1.1" xmlns="http://www.w3.org/2000/svg"> <style> .colour-green {fill: #407336;} .colour-white {fill: #fffffc;} .gear-stroke-on-white {stroke: #407336; stroke-width: 7.78px; fill: #fffffc;} </style> <!-- Background --> <rect class="colour-green" x="-0" y="-0" width="915" height="915"/> <!-- Recurring elements --> <rect class="colour-white" x="121.333" y="289.333" width="93.333" height="336"/> <rect class="colour-white" x="121.333" y="644" width="653.333" height="93.333"/> <rect class="colour-white" x="121.333" y="177.333" width="672" height="93.333"/> <!-- Small gear --> <path class="gear-stroke-on-white" d="M321.54,366.086l4.46,17.37c8.632,1.057 17.091,2.871 25.227,5.408l14.719,-13.259c8.236,2.996 16.09,6.623 23.452,10.832l-6.994,16.827c6.815,4.368 13.008,9.322 18.467,14.774l21.034,-5.595c5.261,5.889 9.795,12.172 13.54,18.761l-16.574,11.776c3.172,6.508 5.439,13.276 6.76,20.181l21.713,3.568c0.875,7.204 0.875,14.46 -0,21.664l-21.713,3.568c-1.321,6.905 -3.588,13.673 -6.76,20.182l16.574,11.775c-3.745,6.589 -8.279,12.872 -13.54,18.761l-21.034,-5.595c-5.459,5.452 -11.652,10.406 -18.467,14.774l6.994,16.827c-7.362,4.209 -15.216,7.836 -23.452,10.832l-14.719,-13.259c-8.136,2.538 -16.595,4.351 -25.227,5.408l-4.46,17.37c-9.005,0.7 -18.075,0.7 -27.08,0l-4.46,-17.37c-8.632,-1.057 -17.091,-2.87 -25.227,-5.408l-14.719,13.259c-8.236,-2.996 -16.09,-6.623 -23.452,-10.832l6.994,-16.827c-6.815,-4.368 -13.008,-9.322 -18.467,-14.774l-21.034,5.595c-5.261,-5.889 -9.795,-12.172 -13.54,-18.761l16.574,-11.775c-3.172,-6.509 -5.439,-13.277 -6.76,-20.182l-21.713,-3.568c-0.875,-7.204 -0.875,-14.46 0,-21.664l21.713,-3.568c1.321,-6.905 3.588,-13.673 6.76,-20.181l-16.574,-11.776c3.745,-6.589 8.279,-12.872 13.54,-18.761l21.034,5.595c5.459,-5.452 11.652,-10.406 18.467,-14.774l-6.994,-16.827c7.362,-4.209 15.216,-7.836 23.452,-10.832l14.719,13.259c8.136,-2.537 16.595,-4.351 25.227,-5.408l4.46,-17.37c9.005,-0.7 18.075,-0.7 27.08,0Zm-13.54,89.075c15.454,0 28,10.037 28,22.4c0,12.363 -12.546,22.4 -28,22.4c-15.454,0 -28,-10.037 -28,-22.4c-0,-12.363 12.546,-22.4 28,-22.4Z"/> <!-- Large gear --> <path class="gear-stroke-on-white" d="M620.977,302.767l7.434,28.951c14.386,1.761 28.485,4.783 42.045,9.012l24.531,-22.098c13.728,4.993 26.818,11.039 39.087,18.053l-11.657,28.045c11.358,7.28 21.68,15.537 30.779,24.624l35.057,-9.326c8.767,9.816 16.325,20.288 22.566,31.27l-27.623,19.625c5.287,10.847 9.065,22.127 11.266,33.636l36.188,5.946c1.459,12.008 1.459,24.1 0,36.107l-36.188,5.947c-2.201,11.508 -5.979,22.788 -11.266,33.636l27.623,19.625c-6.241,10.982 -13.799,21.454 -22.566,31.269l-35.057,-9.325c-9.099,9.086 -19.421,17.344 -30.779,24.623l11.657,28.045c-12.269,7.014 -25.359,13.06 -39.087,18.054l-24.531,-22.099c-13.56,4.229 -27.659,7.252 -42.045,9.013l-7.434,28.95c-15.009,1.167 -30.124,1.167 -45.133,0l-7.433,-28.95c-14.386,-1.761 -28.486,-4.784 -42.045,-9.013l-24.532,22.099c-13.727,-4.994 -26.817,-11.04 -39.086,-18.054l11.656,-28.045c-11.358,-7.279 -21.679,-15.537 -30.779,-24.623l-35.056,9.325c-8.768,-9.815 -16.325,-20.287 -22.567,-31.269l27.623,-19.625c-5.286,-10.848 -9.064,-22.128 -11.266,-33.636l-36.188,-5.947c-1.458,-12.007 -1.458,-24.099 0,-36.107l36.188,-5.946c2.202,-11.509 5.98,-22.789 11.266,-33.636l-27.623,-19.625c6.242,-10.982 13.799,-21.454 22.567,-31.27l35.056,9.326c9.1,-9.087 19.421,-17.344 30.779,-24.624l-11.656,-28.045c12.269,-7.014 25.359,-13.06 39.086,-18.053l24.532,22.098c13.559,-4.229 27.659,-7.251 42.045,-9.012l7.433,-28.951c15.009,-1.167 30.124,-1.167 45.133,0Zm-22.566,148.458c25.756,0 46.666,16.729 46.666,37.334c0,20.605 -20.91,37.333 -46.666,37.333c-25.756,0 -46.667,-16.728 -46.667,-37.333c0,-20.605 20.911,-37.334 46.667,-37.334Z"/> <!-- Masking--> <rect class="colour-green" x="737.333" y="177.333" width="93.333" height="560"/> </svg> - remove + add 1. Removal of the DOCTYPE and cleaning of the XML header Modification: - <!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" …> - <?xml version="1.0" encoding="UTF-8" standalone="no"?> - <svg width="100%" height="100%" viewBox="0 0 915 915" version="1.1" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" xml:space="preserve" xmlns:serif="http://www.serif.com/" style="fill-rule:evenodd;clip-rule:evenodd;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:1.5;"> + <?xml version="1.0" encoding="UTF-8"?> + <svg width="100%" height="100%" viewBox="0 0 915 915" version="1.1" xmlns="http://www.w3.org/2000/svg"> Why? The SVG 1.1 DOCTYPE is inherited from strict XHTML formats or tools such as Adobe Illustrator. It is unnecessary for all modern browsers, rendering engines and production tools using inline SVG (embedded in HTML or parsed directly). The attribute standalone="no" has no useful effect on a standalone SVG file, and may even trigger unexpected behaviour in industrial tools using lightweight XML parsers. Consequences if not done: Risk of blocking certain industrial parsers or embedded tools File may be interpreted using outdated compatibility behaviour 2. Removal of proprietary attributes (serif:id) Modification: - <rect id="Lower-recurring-elements" serif:id="Lower recurring elements" style="…"/> + <rect class="…" …> Why? The serif:id attributes are specific to Affinity Designer and have no functional value in production. They are used only when reopening the file within the same software. These attributes are neither readable nor usable by third-party tools (CNC machines, laser cutters, layout viewers, browsers). Consequences if not done: Unnecessary metadata pollutes the file Possible confusion if another tool misinterprets them Longer file size without benefit 3. Replacement of incorrect or unnecessary values (such as x="-0") Modification: - x="-0" y="-0" + x="0" y="0" Why? Mathematically, -0 is equivalent to 0, but it is the result of an export anomaly, usually linked to floating point rounding. It is a form of digital noise and should be removed. This ensures: Consistency in coordinate values Better human readability More reliable interpretation by software (some fabrication tools interpret -0 as a tiny negative offset) Consequences if not done: Slight offset errors during machining may occur Uncertainty about precision during quality contro 4. Creation of a block using CSS classes Added: <style> .colour-green {fill: #407336;} .colour-white {fill: #fffffc;} .gear-stroke-on-white {stroke: #407336; stroke-width: 7.78px; fill: #fffffc;} </style> Why? Centralize all styles in one place Avoids repeating fill="#fffffc" or stroke="#407336" on every element If colour or style needs to be changed (for example changing green to aluminium etching), only one line must be edited. Consequences if not done: File becomes longer and harder to maintain Every colour change requires manual editing of each occurrence Increased risk of error (for example mismatched shade or incomplete replacement) 5. Use of the class attribute on each element Example: <rect class="colour-green" … /> Why? A class defines a reusable style. It gives meaning to elements (such as "white items" or "green masking") without hardcoding their visual properties. It is cleaner, lighter, more modular It allows styling to be changed via CSS (in an HTML page or interactive SVG interface) without altering the SVG code itself Consequences if not done: Style repetition leads to heavier, harder-to-maintain files No flexibility for future updates or variations 6. Placement of the class attribute at the beginning of the tag Why first? <rect class="colour-white" x="…" y="…" … /> It is the most general attribute (appearance) Placing it first makes it immediately clear what the element represents: Improves readability for technicians and operators Respects a logical hierarchy: What it is (style) Where it is (coordinates) What size it is (dimensions) Consequences if not done: Slower reading Harder to distinguish between elements Less structured code for human readers 7. Addition of structural comments in the code Example: <!-- Background --> … <!-- Recurring elements --> … <!-- Small gear --> … <!-- Masking --> … Why? These comments replace the former id attributes (now removed) in a non-intrusive way They serve as visual markers for those reviewing or editing the file In a production context, they help locate visual sections quickly (such as gears, background, repeating elements) Consequences if not done: Files become harder to maintain over time No easy way to identify parts without opening the file graphically 8. Removal of id attributes no longer in use Why? Id attributes are only useful if: They are called by a script or link They are targeted by external CSS In this file, ids were included solely for graphic editing (Affinity, Illustrator). Removing them lightens the DOM and avoids conflicts if the SVG is embedded into a web page. Consequences if not done: DOM can be polluted with unused identifiers Risk of naming conflicts in interactive interfaces 9. Geometrical verification and preservation of original paths No geometrical changes were made: All path data remains identical The shapes and proportions of the gears have been left untouched Only the code structure was optimized, not the visual content. 10. Correction of rounding in the background rectangle Modification: - <rect width="914.667" height="914.667" … /> + <rect width="915" height="915" … /> Why? The value 914.667 results from automatic rounding during SVG export from Serif or during unit conversion. This creates slight visual imprecision: On screen, it may cause a blurred edge or one-pixel overflow depending on resolution In print, it risks a faint white line or inaccurate trim In graphic production or cutting, such an offset may lead to a misalignment or deviation from the template Consequences if not done: Imprecise cut or frame in printed output Defects in alignment on presses or imposition profiles Non-compliant rendering with physical specifications Strictly speaking, the exported file should match the exact dimensions specified within the Affinity Suite. Any discrepancy, even minimal, can lead to misalignment during printing, cropping issues or visual artefacts on screen. 11. Why classes were used instead of inline styles Why? In the optimized version, no styles are written directly into the tags, such as <path style="fill:#fffffc;stroke:#407336;stroke-width:7.78px;" /> Instead, classes are used: <path class="gear-stroke-on-white"… /> Classes offer the following advantages: Style definitions are reusable for multiple elements They separate appearance from geometry Colours can be updated quickly (for instance, switching to greyscale for offset printing, or adapting to dark mode on the web) They allow for animation or interaction in dynamic SVG if required for web use Inline styles are fixed, hard to maintain and make each element heavier Consequences if not done: File becomes larger Manual errors become more frequent Files are less flexible for multi-platform use (paper, screen, manufacturing) 12. Why classes were placed at the beginning of each tag Example: <rect class="colour-white" x="…" y="…" width="…" height="…" /> Why? The class attribute defines visual intent. Placing it at the top of the tag allows: Immediate understanding of the element’s visual function (background, mask, gear, etc.) Easy grouping of similar elements (e.g. all white elements, all green masks) A logical structure: First: style Then: position (x, y) Finally: shape or path (width, height, d, etc.) This choice supports efficient human reading, especially in a fabrication context or for last-minute manual adjustments Consequences if not done: Less clear code Harder to navigate and read More difficult to maintain after export This writing order follows a clear and consistent structure, similar to what is found in well-designed development environments. The class attribute, which defines the overall appearance of the element, is placed at the beginning of the tag, before coordinates (x, y) and dimensions. This hierarchy improves readability, identification and modification, especially when the file is used in a web or graphical production workflow. 13. Compatibility extended to cutting or engraving systems Why relevant, even if not the primary purpose? Although the file is primarily designed for printing and web via Serif, the optimized SVG structure also provides: Vector accuracy suitable for cutting tables (laser, router, plotter) No inline styles that could be misinterpreted by automation software Clean geometry without proprietary tags, making it easier to process with cutting preparation software (LightBurn, Zünd Cut Center, etc.) Clearly identifiable layers if separate operations were required (cutting path, engraving path, solid fill) Positive consequences: The same file can be adapted for extended use without needing to be redrawn or manually cleaned General conclusion The SVG file has been carefully structured to ensure: Perfect accuracy for printing, without export artefacts or misaligned edges Native compatibility with browsers and online display, without obsolete code Potential interoperability with cutting or engraving tools thanks to code clarity Graphical modularity, allowing for future variants without needing a full redesign All optimizations are reversible and documented, ensuring safe, reliable and scalable use. optimisation-svg.afdesign svg-actual.svg svg-after.svg

v 2.6.1.3134 Hello everyone, I need to generate several dimensions of an image for a website. Reducing a WEBP image to 480 px often gives a mediocre result. Integrating the AFFPUB version used to create this WEBP image into another AFPUB file generally doesn't improve the rendering, and may even make it worse. Is there a way to get a better result? Please find attached the original file and its integration into a target file. cible.afpub origine.afpub

Hello everyone, I’m looking to apply a true perspective to the rectangular surface of a photograph using the Affinity suite, with two or three vanishing points. What would be the best way to achieve this? Thank you in advance for your advice and help. See the attached AFPUB file, for example with this attached photo (Ph. Jomigraphy, March 3, 2021). perspective.afpub

14. Character style The font style Small capital should produce a reduced-size capital text, but instead there's a path whose place is reserved by a <tspan>. Underline often produces a rectangle, and sometimes a path. The apostrophe sometimes produces a <tspan>, but I don't know why. <!-- Vulputate, and others --> <path d="M234.686,19.098l-2.411,5.922l-1.032,0l-2.349,-5.922l1.047,0l1.61,4.303c0.027,0.072 0.052,0.138 0.072,0.197c0.021,0.059 0.04,0.118 0.058,0.175c0.017,0.057 0.033,0.114 0.047,0.172c0.014,0.057 0.029,0.12 0.047,0.19l0.01,-0c0.028,-0.122 0.059,-0.241 0.094,-0.359c0.034,-0.119 0.078,-0.244 0.13,-0.375l1.687,-4.303l0.99,0Z" style="fill:#11161e;fill-rule:nonzero;"/> <path d="M240.467,22.526c0,0.184 -0.008,0.375 -0.023,0.575c-0.016,0.2 -0.052,0.396 -0.11,0.589c-0.057,0.192 -0.139,0.375 -0.247,0.546c-0.108,0.172 -0.253,0.323 -0.437,0.454c-0.184,0.13 -0.412,0.233 -0.683,0.309c-0.271,0.077 -0.599,0.115 -0.984,0.115c-0.427,0 -0.785,-0.043 -1.073,-0.13c-0.288,-0.087 -0.525,-0.202 -0.711,-0.344c-0.186,-0.142 -0.327,-0.305 -0.424,-0.487c-0.098,-0.182 -0.168,-0.37 -0.211,-0.562c-0.044,-0.193 -0.068,-0.381 -0.073,-0.565c-0.006,-0.185 -0.008,-0.351 -0.008,-0.5l-0,-3.428l0.963,0l0,3.417c0,0.149 0.005,0.297 0.013,0.443c0.009,0.146 0.03,0.284 0.063,0.414c0.033,0.13 0.082,0.252 0.146,0.364c0.064,0.113 0.151,0.211 0.26,0.292c0.11,0.082 0.244,0.145 0.404,0.19c0.16,0.045 0.354,0.068 0.583,0.068c0.358,-0 0.642,-0.043 0.852,-0.128c0.21,-0.085 0.369,-0.205 0.476,-0.362c0.108,-0.156 0.176,-0.343 0.206,-0.56c0.03,-0.217 0.044,-0.457 0.044,-0.721l0,-3.417l0.974,0l0,3.428Z" style="fill:#11161e;fill-rule:nonzero;"/> <path d="M245.926,25.02l-3.922,0l-0,-5.922l0.968,0l0,5.089l2.954,-0l-0,0.833Z" style="fill:#11161e;fill-rule:nonzero;"/> <path d="M246.983,19.098l2.354,0c0.413,0 0.769,0.04 1.068,0.118c0.298,0.078 0.543,0.193 0.734,0.346c0.191,0.153 0.332,0.341 0.422,0.565c0.09,0.224 0.135,0.482 0.135,0.774c0,0.26 -0.043,0.505 -0.13,0.734c-0.087,0.229 -0.223,0.43 -0.409,0.604c-0.185,0.174 -0.422,0.311 -0.711,0.412c-0.288,0.1 -0.633,0.151 -1.036,0.151l-1.458,-0l-0,2.218l-0.969,0l-0,-5.922Zm0.969,2.87l1.312,0c0.479,0 0.839,-0.08 1.078,-0.242c0.24,-0.161 0.36,-0.428 0.36,-0.799c-0,-0.198 -0.034,-0.362 -0.102,-0.49c-0.068,-0.128 -0.164,-0.23 -0.289,-0.305c-0.125,-0.074 -0.278,-0.126 -0.458,-0.156c-0.181,-0.029 -0.384,-0.044 -0.61,-0.044l-1.291,-0l-0,2.036Z" style="fill:#11161e;fill-rule:nonzero;"/> <path d="M257.832,22.526c-0,0.184 -0.008,0.375 -0.024,0.575c-0.015,0.2 -0.052,0.396 -0.109,0.589c-0.057,0.192 -0.14,0.375 -0.247,0.546c-0.108,0.172 -0.254,0.323 -0.438,0.454c-0.184,0.13 -0.411,0.233 -0.682,0.309c-0.271,0.077 -0.599,0.115 -0.985,0.115c-0.427,0 -0.784,-0.043 -1.072,-0.13c-0.289,-0.087 -0.526,-0.202 -0.711,-0.344c-0.186,-0.142 -0.328,-0.305 -0.425,-0.487c-0.097,-0.182 -0.167,-0.37 -0.211,-0.562c-0.043,-0.193 -0.068,-0.381 -0.073,-0.565c-0.005,-0.185 -0.008,-0.351 -0.008,-0.5l0,-3.428l0.964,0l-0,3.417c-0,0.149 0.004,0.297 0.013,0.443c0.009,0.146 0.03,0.284 0.063,0.414c0.032,0.13 0.081,0.252 0.145,0.364c0.065,0.113 0.151,0.211 0.261,0.292c0.109,0.082 0.244,0.145 0.403,0.19c0.16,0.045 0.355,0.068 0.584,0.068c0.357,-0 0.641,-0.043 0.851,-0.128c0.21,-0.085 0.369,-0.205 0.477,-0.362c0.108,-0.156 0.176,-0.343 0.206,-0.56c0.029,-0.217 0.044,-0.457 0.044,-0.721l-0,-3.417l0.974,0l-0,3.428Z" style="fill:#11161e;fill-rule:nonzero;"/> <path d="M263.78,19.932l-2.026,-0l-0,5.088l-0.959,0l0,-5.088l-2.005,-0l0,-0.834l4.99,0l-0,0.834Z" style="fill:#11161e;fill-rule:nonzero;"/> test-svg-style.afpub test-svg-style.svg

@walt.farrell, Thanks for your insight. I think I understand what you’re referring to! You’re probably talking about the  symbol. This character corresponds to the Unicode U+FFFC, called Object Replacement Character. It’s used to represent objects embedded or anchored in a text stream when they can’t be displayed directly. It’s a standard character often, and certainly always found in all well-designed fonts. It precedes �, the Unicode character U+FFFD, called Replacement Character. The latter is used to indicate that a character is absent from the font used, or that it cannot be displayed due to inappropriate encoding. If it doesn’t exist in a font, it means that the font is really badly designed. In practice, it’s best to avoid using such a font, as it may cause similar problems elsewhere. To answer your question more precisely, this U+FFFC character appeared in the AFPUB file during a simple manual insertion of the character, carried out for didactic purposes, to check whether it passed the export test. PS: I haven’t yet tested the use of anchored objects with SVG files. Do you think such use would be relevant in this specific format?

13. Tables Tables also produce numerous unnecessary transformation artifacts, often one per row. These serve no functional purpose and significantly increase the file size. <g transform="matrix(10.6667,0,0,10.6667,125.09,31.8289)"> </g> At the top level, we also observe transformations that effectively cancel each other out. <g transform="matrix(1.00318,6.93889e-18,-2.77556e-17,1.11865,-1.017,-20.8912)"> <g transform="matrix(0.996832,0,0,0.893932,0.306381,1.98085)"> <text x="112.043px" y="31.829px" style="font-family:'ArialMT', 'Arial';font-size:10.667px;fill:#e43a30;">A1</text> </g> </g> The result of these redundant artifacts is an SVG file that is, on average, three to five times larger. This also increases display latency, introduces significant inaccuracies due to compounded rounding, and complicates maintenance for any post-generation edits. test-svg-table.svg test-svg-table.afpub

I'm not sure I understand your request. I've provided the original AFPUB file, the SVG image produced, the SVG source code generated with my comments, and a proposal for an optimized version of the source code. I'd like to take advantage of your request to add a twelfth point.

Hello everyone, While exporting a very simplified text from Affinity in regular Arial, 8 pt, black), I came across several oddities in the generated SVG file. To illustrate the case, I added “absent” characters represented by a red placeholder, as well as a red rectangle. And there you have : - A ghost font named ArialMT (from Adobe), which doesn't exist in my source file or even on my system. - A totally useless empty group. - Nested transformations for no good reason. None of the transformations are useful. - Many useless attributes. Here's the source file (Unnecessary things in color). <?xml version="1.0" encoding="UTF-8" standalone="no"?> <!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd"> <svg width="100%" height="100%" viewBox="0 0 1334 350" version="1.1" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" xml:space="preserve" xmlns:serif="http://www.serif.com/" style="fill-rule:evenodd;clip-rule:evenodd;stroke-linejoin:round;stroke-miterlimit:2;"> <g transform="matrix(4.16667,0,0,4.16667,0,0)"> <g transform="matrix(4.60446,0,0,0.45635,0,0)"> <rect x="0" y="0" width="18.243" height="184.069" style="fill:#e43a30;"/> </g> <g id="Fonte" transform="matrix(1,0,0,1,84,2.84217e-14)"> <text x="14px" y="31.954px" style="font-family:'ArialMT', 'Arial';font-size:10.667px;fill:#11161e;">In purus est, mattis eget, imp</text> <text x="150.948px" y="31.954px" style="font-family:'ArialMT', 'Arial';font-size:10.667px;fill:#e43a30;"></text> <text x="161.615px" y="31.954px" style="font-family:'ArialMT', 'Arial';font-size:10.667px;fill:#11161e;">rdiet nec,</text> <text x="14px" y="45.82px" style="font-family:'ArialMT', 'Arial';font-size:10.667px;fill:#11161e;">f</text> <text x="16.964px" y="45.82px" style="font-family:'ArialMT', 'Arial';font-size:10.667px;fill:#e43a30;"></text> <text x="27.63px" y="45.82px" style="font-family:'ArialMT', 'Arial';font-size:10.667px;fill:#11161e;">rm</text> <text x="40.068px" y="45.82px" style="font-family:'ArialMT', 'Arial';font-size:10.667px;fill:#e43a30;"></text> <text x="50.734px" y="45.82px" style="font-family:'ArialMT', 'Arial';font-size:10.667px;fill:#11161e;">ntum cong</text> <text x="100.542px" y="45.82px" style="font-family:'ArialMT', 'Arial';font-size:10.667px;fill:#e43a30;"></text> <text x="111.208px" y="45.82px" style="font-family:'ArialMT', 'Arial';font-size:10.667px;fill:#11161e;">e, tortor. Aenean ut</text> <g transform="matrix(10.6667,0,0,10.6667,187.094,59.687)"> </g> <text x="14px" y="59.687px" style="font-family:'ArialMT', 'Arial';font-size:10.667px;fill:#11161e;">nibh. Nullam hendrerit viverra mi […]</text> </g> </g> </svg> Here's why. <?xml version=“1.0” encoding=“UTF-8” standalone=“no”?> <!-- Can be removed: redundant with file header. --> <!DOCTYPE svg PUBLIC “-//W3C//DTD SVG 1.1//EN” “http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd”> <!-- Obsolete: useless in modern SVG files. --> <svg width=“100%” height=“100%” <!-- Potentially useless: dimensions will often depend on integration via CSS. --> viewBox="0 0 1334 350” version=“1.1” <!-- Superfluous: version is implicit in modern specifications. --> xmlns="http://www.w3.org/2000/svg” xmlns:xlink=“http://www.w3.org/1999/xlink” <!-- Potentially useless: `xlink` is no longer needed in SVG 2.0. --> xml:space=“preserve” <!-- Unnecessary in most cases: `xml:space=“preserve”` has little effect except with intentional spaces. --> xmlns:serif=“http://www.serif.com/” <!-- Totally useless: no use of this namespace in the file. --> style=“fill-rule:evenodd;clip-rule:evenodd;stroke-linejoin:round;stroke-miterlimit:2;”> <!-- Potentially useless if these styles don't concern content. --> To be more precise: Here's a list of aspects to consider: 1. DTD usage Criticism: Use of the DTD <!DOCTYPE svg PUBLIC “-//W3C//DTD SVG 1.1//EN” “http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd”> is obsolete and of little use in a modern context. Most browsers ignore this declaration. Improvement: Remove the DTD or simply use the XML version without DTD. 2. Inline style Criticism: The style attribute in svg and internal elements (rect, text) mixes style definitions in SVG content, making maintenance difficult. Improvement: Externalize styles in a CSS sheet or group them in a <style> tag in the SVG file to centralize styles. 3. Non-standard fonts Criticism: The style font-family:'ArialMT', 'Arial'; includes a non-standard font (ArialMT), which may not be recognized on all systems. This may cause incorrect rendering. Improvement: Use standard fonts or define reliable fallbacks (font-family: 'Arial', sans-serif;). If the software could also optimize the source, it would produce much smaller images that would load more quickly. 4. Inconsistent attribute values Criticism: x-positions for <text> elements use px values when other units might be more suitable (e.g. % or relative coordinates). Dimensions and transformations (matrix(...)) are complicated and difficult to interpret, making manual editing a pain. Improvement: Simplify transformations and use consistent units or positions to facilitate readability and maintenance. 5. Lack of descriptive tags (accessibility) Criticism: The file does not contain accessible descriptions such as <title> or <desc> tags. These tags are useful for assistive technologies (screen readers). Improvement: Add <title> and <desc> tags to describe visually represented content. 6. Unnecessary or redundant data Criticism: The namespace xmlns:serif=“http://www.serif.com/” is declared but never used. The <g transform=“matrix(10.6667,0,0,10.6667,214.422,59.687)”> element is empty, which seems unnecessary. Improvement: Remove unused elements or declarations to lighten the file. 7. Complex transformations Criticism: Matrix(...) transformations are complex and make subsequent modification difficult. They can also cause compatibility problems with certain viewers or tools. Improvement: Replace matrices with explicit transformations (e.g. translate, scale, rotate) where possible. 8. Fixed dimensions and lack of dynamic viewBox Criticism: The dimensions width=“100%” and height=“100%” do not guarantee correct rendering in all contexts, as they depend on the parent container. The viewBox is correctly defined, but its association with dynamic dimensions could be optimized. Improvement: Add explicit dimensions or use a more flexible viewBox to ensure consistent rendering. 9. Confusing hierarchical structure Criticism: The numerous <g> and <text> sub-elements make the structure unwieldy. Each word or fragment is encapsulated in a separate element, making the file difficult to manipulate or modify. Improvement: Group text in a single <text> element if possible, with <tspan> elements to handle differences in style or position. 10. Style redundancy Criticism: Each <text> element repeats the same styles (font-family, font-size, fill), making the file unwieldy. Improvement: Use classes or global styles to reduce redundancy. 11. Unnecessary inclusion of XML attributes Criticism: The xml:space=“preserve” attribute is rarely needed and could be superfluous here. Improvement: Remove it if its presence does not modify the file's behavior. 12. Longer text spans Criticism: The text of an option should not resemble a treasure hunt, but clearly describe its function. The current title, 'Longer text spans', is inappropriate, even a misnomer that can only add to the confusion. In French, the translation also adds a contradiction to the contradiction. This option actually determines whether or not <text> tags include <tspan> child tags. Improvement: A more suitable formulation would be: <Text> tag without <tspan> child tags. Or: <Text> tag without <tspan> In French : Balise <Text> sans balises enfants <tspan>. Or: Balise <Text> sans <tspan> To take things a step further, here's some optimized code. <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 1334 350"> <!-- Styles CSS intégrés --> <style> .svg-red { fill: #e43a30; } .svg-black { fill: #11161e; } .svg-text { font-family: Arial, sans-serif; font-size: 10.667px; } </style> <!-- Rectangle rouge --> <rect x="0" y="0" width="76" height="184.069" class="svg-red" /> <!-- Textes noirs --> <text class="svg-text svg-black"> <tspan x="14" y="31.954">In purus est, mattis eget, imp</tspan> <tspan x="161.615" y="31.954">rdiet nec,</tspan> <tspan x="14" y="45.82">f</tspan> <tspan x="27.63" y="45.82">rm</tspan> <tspan x="50.734" y="45.82">ntum cong</tspan> <tspan x="111.208" y="45.82">e, tortor. Aenean ut</tspan> <tspan x="14" y="59.687">nibh. Nullam hendrerit viverra mi […]</tspan> </text> <!-- Textes rouges --> <text class="svg-text svg-red"> <tspan x="150.948" y="31.954"></tspan> <tspan x="16.964" y="45.82"></tspan> <tspan x="40.068" y="45.82"></tspan> <tspan x="100.542" y="45.82"></tspan> </text> </svg> 13. Table with unnecessary transformation sequences Criticism: Instead of transforming the table directly into text, and adding a grid, the software produces an unbelievable number of transformations that in reality serve no purpose except to add inaccuracies. Improvement: Avoid transformations. See discussion below 14. Character style transformed into path Criticism: The Small capital character style turns text into a path and adds a <tspan> tag, the underscore becomes a rectangle, the highlight becomes a path, the apostrophe sometimes leads to the insertion of a <tspan> tag. Improvement: Avoid transformations. See discussion below. Summary of areas for improvement By streamlining the structure, optimizing the styles and simplifying the transformations, we could make this SVG file : More readable, lighter, More compatible with modern tools. By adopting these optimizations, Affinity could generate SVG files that are not only more powerful and lightweight, but also conform to modern standards, making them easier to integrate and manipulate in demanding professional workflows. Wouldn't it be a good thing to be ahead of the game? test-svg.afpub bad-font.svg