Doug Schepers Posted June 5, 2024 Posted June 5, 2024 Currently, SVG export, which is otherwise very good, adds a lot of legacy XML cruft that slightly increases files sizes, but more importantly, makes it harder to use SVG in HTML. This is merely tedious for SVG experts, but it could be very confusing for less experienced developers. Specifically the XML prolog and the DOCTYPE declaration are completely unnecessary, and can be removed with no effect at all. In fact, it must be removed in order to put the SVG inline in HTML or CSS, which is common for icons and such in React and other HTML-in-JS frameworks. Similarly, the XLink namespace declaration in the SVG is no longer needed (as of 2013 or so), and the `xml:space` and version attributes no longer have any effect. For example, here's the first 3 lines of your SVG export file: <?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 96 120" 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;"> Instead, it should look like this: <svg width="100%" height="100%" viewBox="0 0 96 120" xmlns="http://www.w3.org/2000/svg" xmlns:serif="http://www.serif.com/" style="fill-rule:evenodd;clip-rule:evenodd;"> For context, I was the W3C project manager for the SVG Working Group for a decade, overseeing the adoption of SVG in all major browsers, and I can definitely say that the XML cruft is a throwback to the 1990s, and seems very out of place in modern SVG. Thanks! Megnusin, Gripsholm Lion, bbrother and 3 others 6 Quote
walt.farrell Posted June 6, 2024 Posted June 6, 2024 Welcome to the Affinity forums, @Doug Schepers. Just curious, as I haven't managed to find it yet: Is there someplace in the standards that says a standalone SVG file doesn't need the XML information? Quote -- Walt Designer, Photo, and Publisher V1 and V2 at latest retail and beta releases PC: Desktop: Windows 11 Pro 23H2, 64GB memory, AMD Ryzen 9 5900 12-Core @ 3.00 GHz, NVIDIA GeForce RTX 3090 Laptop: Windows 11 Pro 23H2, 32GB memory, Intel Core i7-10750H @ 2.60GHz, Intel UHD Graphics Comet Lake GT2 and NVIDIA GeForce RTX 3070 Laptop GPU. Laptop 2: Windows 11 Pro 24H2, 16GB memory, Snapdragon(R) X Elite - X1E80100 - Qualcomm(R) Oryon(TM) 12 Core CPU 4.01 GHz, Qualcomm(R) Adreno(TM) X1-85 GPU iPad: iPad Pro M1, 12.9": iPadOS 18.3, Apple Pencil 2, Magic Keyboard Mac: 2023 M2 MacBook Air 15", 16GB memory, macOS Sequoia 15.0.1
Doug Schepers Posted June 16, 2024 Author Posted June 16, 2024 Hi, Walt, The language is needlessly obscure, but the SVG 2 spec does describe a "conforming SVG DOM subtree", which: is rooted by an ‘svg’ element in the SVG namespace, conforms to the content model and attributes rules for the elements defined in this document (Scalable Vector Graphics (SVG) Specification), and conforms to the content model and attributes rules defined by other specifications for any elements in the SVG namespace defined by those specifications […]. In plain language, while the XML declaration is allowed, per XML processing rules, it is not required; only the `svg` root is required, along with the SVG namespace (when not embedded in HTML5). (Misleadingly, the SVG spec itself, perhaps in a fit of formality, usually does include the XML declaration in most of the examples; it shouldn't.) The Extensible Markup Language (XML) spec itself makes it clear that the XML declaration is not required: [Definition: XML documents SHOULD begin with an XML declaration which specifies the version of XML being used.] For example, the following is a complete XML document, well-formed but not valid: <?xml version="1.0"?> <greeting>Hello, world!</greeting> and so is this: <greeting>Hello, world!</greeting> Note the technical usage of the RFC 2119 keyword "SHOULD", which means, roughly, "encouraged but not required", as contrasted with the keywords "MUST" or "SHALL". Since the only point of the XML declaration is to specify which version of XML is being used, and there was only ever one version of XML (XML 1.0), the declaration is useless. And I don't want to dig into the HTML5 spec, but I'm almost certain that the HTML5 parser doesn't allow inline XML declarations, especially since the XML spec requires that any XML declaration is at the top of the document. So, an SVG document embedded in an HTML5 document cannot include an XML declaration. A less grizzled and hardened dev than you or I would likely simply copy the entire SVG file and paste it into an HTML file, and not know why it doesn't validate. You didn't ask about the DOCTYPE, but just for completeness, the SVG 2 spec removes all references to the Document Type Definition: "SVG 2 is not defined in terms of a DTD". Ultimately, the greatest utility is in looking at which software contexts the output SVG is going to be used in. Any modern XML processor doesn't need the XML declaration. Browsers often choke on it. Other SVG tools don't need it. At least some VSCode linting tools (perhaps incorrectly) flag it as an error. At best,the XML prolog is tolerated; on average, it's a nuisance; at worst, it breaks things. In terms of implementation, this should be very easy; the Affinity developers don't need to add anything, they just need to take something out. Regards, Doug Meliora spero, Westerwälder, bbrother and 1 other 3 1 Quote
walt.farrell Posted June 16, 2024 Posted June 16, 2024 Thanks, Doug. In part, I think, the issue may be that Affinity is not creating something to be directly embedded by the user in an HTML5 document. It is creating a file, to be used in another program or to be displayed from an HTML document. But both could be handled, if it's necessary, by having an Export option to say whether to make it a standalone file or something embeddable, I suppose (The Developers will be able to figure it out, I'm sure.) Megnusin 1 Quote -- Walt Designer, Photo, and Publisher V1 and V2 at latest retail and beta releases PC: Desktop: Windows 11 Pro 23H2, 64GB memory, AMD Ryzen 9 5900 12-Core @ 3.00 GHz, NVIDIA GeForce RTX 3090 Laptop: Windows 11 Pro 23H2, 32GB memory, Intel Core i7-10750H @ 2.60GHz, Intel UHD Graphics Comet Lake GT2 and NVIDIA GeForce RTX 3070 Laptop GPU. Laptop 2: Windows 11 Pro 24H2, 16GB memory, Snapdragon(R) X Elite - X1E80100 - Qualcomm(R) Oryon(TM) 12 Core CPU 4.01 GHz, Qualcomm(R) Adreno(TM) X1-85 GPU iPad: iPad Pro M1, 12.9": iPadOS 18.3, Apple Pencil 2, Magic Keyboard Mac: 2023 M2 MacBook Air 15", 16GB memory, macOS Sequoia 15.0.1
Doug Schepers Posted June 17, 2024 Author Posted June 17, 2024 Hi, Walt, Respectfully, you're overthinking this. There is no benefit to including the XML and DOCTYPE declarations. There are disadvantages to doing so. There's no need to complicate the implementation by having 2 export options, one with useless XML cruft, and one without. They can just remove the prolog, as simple as that. I worry that by presenting a false dichotomy, you may be reducing the odds that the Affinity developers understand how easy this fix would be for them to make. I'm a user of Affinity, and one of my use cases is embedding SVGs inline in HTML5; another is embedding them as BASE64Encoded entries in CSS; another is optimizing file sizes; another is opening SVG files in VSCode without getting errors. I understand that you may use Affinity and SVGs differently than I do, but please don't invalidate my use cases by prescriptively declaring what an SVG "should" be used for. Thanks, Doug bbrother, Ezbaze, Westerwälder and 1 other 1 2 1 Quote
walt.farrell Posted June 17, 2024 Posted June 17, 2024 9 hours ago, Doug Schepers said: I understand that you may use Affinity and SVGs differently than I do, but please don't invalidate my use cases by prescriptively declaring what an SVG "should" be used for. I'm not trying to do that, and my apologies if it seems like I am. I am merely pointing out that what Affinity is producing is complete stand-alone files, and you want it to produce embeddable pieces of SVG code for a different usage than the Affinity designers intended. Can you guarantee that no one else in the world is expecting complete files, and that no other application would be affected by the outer XML shell disappearing? If it's really true that no one would be affected or need to change how they're processing the current output, then I would agree no option is needed. Quote -- Walt Designer, Photo, and Publisher V1 and V2 at latest retail and beta releases PC: Desktop: Windows 11 Pro 23H2, 64GB memory, AMD Ryzen 9 5900 12-Core @ 3.00 GHz, NVIDIA GeForce RTX 3090 Laptop: Windows 11 Pro 23H2, 32GB memory, Intel Core i7-10750H @ 2.60GHz, Intel UHD Graphics Comet Lake GT2 and NVIDIA GeForce RTX 3070 Laptop GPU. Laptop 2: Windows 11 Pro 24H2, 16GB memory, Snapdragon(R) X Elite - X1E80100 - Qualcomm(R) Oryon(TM) 12 Core CPU 4.01 GHz, Qualcomm(R) Adreno(TM) X1-85 GPU iPad: iPad Pro M1, 12.9": iPadOS 18.3, Apple Pencil 2, Magic Keyboard Mac: 2023 M2 MacBook Air 15", 16GB memory, macOS Sequoia 15.0.1
Gripsholm Lion Posted June 18, 2024 Posted June 18, 2024 You must be second-guessing what the Serif developers intended. If Serif had consulted some web devs, it would know that this can be a shortcoming. Along with the other shortcomings in its SVG output. I still use this software professionally daily, but these stupid issues can be frustrating. Doug Schepers 1 Quote
Paul Schreiber Posted July 2, 2024 Posted July 2, 2024 I am in strong agreement with Doug. This really should be fixed, and quickly. Doug Schepers 1 Quote
Doug Schepers Posted July 2, 2024 Author Posted July 2, 2024 4 hours ago, Paul Schreiber said: I am in strong agreement with Doug. This really should be fixed, and quickly. And it is a really quick fix. It doesn't need multiple save options, as Walt suggests. The code just needs to omit the XML and DOCTYPE declarations. Meliora spero 1 Quote
David Cake Posted July 8, 2024 Posted July 8, 2024 I agree that this is a good change, and that Doug is correct. Unless anyone can come up with a common use case for retaining the cruft, which I think is unlikely, simply remove it. Anyone who really needs it (should they exist) should understand the issue and be capable of creating a tool to trivially replace it. But the vast majority do not need it, and are likely to find baffling problems as a result. Doug Schepers 1 Quote
Old Bruce Posted July 8, 2024 Posted July 8, 2024 11 hours ago, David Cake said: Anyone who really needs it (should they exist) should understand the issue and be capable of creating a tool to trivially replace it. But the vast majority do not need it, and are likely to find baffling problems as a result. An alternate view: Anyone who really does not need it should understand the issue and be capable of creating a tool to trivially remove it. Perhaps the vast majority do need it, and are likely to find baffling problems as a result. Gripsholm Lion 1 Quote Mac Pro (Late 2013) Mac OS 12.7.6 Affinity Designer 2.5.7 | Affinity Photo 2.5.7 | Affinity Publisher 2.5.7 | Beta versions as they appear. I have never mastered color management, period, so I cannot help with that.
Paul Schreiber Posted July 8, 2024 Posted July 8, 2024 @Old Bruce Nobody needs this. Meliora spero 1 Quote
Westerwälder Posted July 8, 2024 Posted July 8, 2024 https://de.wikipedia.org/wiki/Scalable_Vector_Graphics SVG, das auf XML basiert Meliora spero 1 Quote
walt.farrell Posted July 8, 2024 Posted July 8, 2024 14 minutes ago, Westerwälder said: https://de.wikipedia.org/wiki/Scalable_Vector_Graphics SVG, das auf XML basiert And that page says (courtesy of Firefox's translator): Quote As an XML document, an SVG is built in a tree structure of different elements and attributes assigned to these elements. An SVG file can begin with the XML declaration, as is usual with XML-based languages. This can be followed by processing instructions, such as those for referencing external style sheets. The indication of the document type declaration is not recommended on the one hand,[17] on the other hand it is considered necessary for a correct document.[18] It is possible and customary for SVG since its infits to note abbreviations in the form of entities in the internal document type declaration in order to be able to reduce the file size. Quote -- Walt Designer, Photo, and Publisher V1 and V2 at latest retail and beta releases PC: Desktop: Windows 11 Pro 23H2, 64GB memory, AMD Ryzen 9 5900 12-Core @ 3.00 GHz, NVIDIA GeForce RTX 3090 Laptop: Windows 11 Pro 23H2, 32GB memory, Intel Core i7-10750H @ 2.60GHz, Intel UHD Graphics Comet Lake GT2 and NVIDIA GeForce RTX 3070 Laptop GPU. Laptop 2: Windows 11 Pro 24H2, 16GB memory, Snapdragon(R) X Elite - X1E80100 - Qualcomm(R) Oryon(TM) 12 Core CPU 4.01 GHz, Qualcomm(R) Adreno(TM) X1-85 GPU iPad: iPad Pro M1, 12.9": iPadOS 18.3, Apple Pencil 2, Magic Keyboard Mac: 2023 M2 MacBook Air 15", 16GB memory, macOS Sequoia 15.0.1
Doug Schepers Posted July 8, 2024 Author Posted July 8, 2024 1 hour ago, walt.farrell said: on the other hand it is considered necessary for a correct document.[18] That statement in the German Wikipedia article is wrong; note that this doesn't appear in the English version of that page. That link (reference #18) points to the outdated SVG 1.1 spec, which even there, as I've noted before, doesn't require an XML declaration, only that the document be well-formed XML, which (as clarified before) doesn't require the XML declaration. The folks suggesting we retain the XML prolog have not pointed to a single piece software that would be negatively affected (indeed, affected at all) by removing the XML prolog. I suggest that if they want to continue to block this issue, they name a software product that would be harmed by this. This seems to be a case of cargo-culting, where the people advocating for retaining the XML prolog don't seem to understand what it does or why it was put there in the first place, but are afraid to remove it because it might disrupt the "ritual". Meanwhile, those of us skilled in authoring and using SVG know that it's only a hindrance. Walt, you seem to be active on the forums, and I've seen very helpful responses by you. I don't understand why you're trying to make things harder for those of us who want to use SVG in all the ways it's meant to be used; I advocated for SVG for a decade to get it adopted across all browsers, so I'm invested in everyone being able to use it. Are you just trying to "win" a perceived argument? I'm afraid I don't have more time to respond to your disinformation on this topic. I've presented the technical and practical argument for removing the XML declaration and DOCTYPE; I've clarified that this doesn't harm any SVG users; I hope my arguments and the overwhelming support for this by other technical users will convince the developers. I won't be commenting further on this issue. (This has been a thoroughly unpleasant experience, and I hope it's not representative of the Affinity forums in general.) lepr, Gripsholm Lion, Westerwälder and 1 other 2 1 1 Quote
walt.farrell Posted July 8, 2024 Posted July 8, 2024 6 minutes ago, Doug Schepers said: Walt, you seem to be active on the forums, and I've seen very helpful responses by you. I don't understand why you're trying to make things harder for those of us who want to use SVG in all the ways it's meant to be used; I advocated for SVG for a decade to get it adopted across all browsers, so I'm invested in everyone being able to use it. Are you just trying to "win" a perceived argument? I'm afraid I don't have more time to respond to your disinformation on this topic. I've presented the technical and practical argument for removing the XML declaration and DOCTYPE; I've clarified that this doesn't harm any SVG users; I hope my arguments and the overwhelming support for this by other technical users will convince the developers. I won't be commenting further on this issue. (This has been a thoroughly unpleasant experience, and I hope it's not representative of the Affinity forums in general.) I'm not trying to win. And if you're 100% sure that it won't affect any users who are expecting valid files rather than some code they can embed, then I'll be happy with whatever the Affinity team tries to produce. It would be nice, though, to have a clear statement in some standard that says the XML headers are not required in documents, and that parsers should not depend on them. I haven't found that, yet. Westerwälder, Old Bruce and Meliora spero 2 1 Quote -- Walt Designer, Photo, and Publisher V1 and V2 at latest retail and beta releases PC: Desktop: Windows 11 Pro 23H2, 64GB memory, AMD Ryzen 9 5900 12-Core @ 3.00 GHz, NVIDIA GeForce RTX 3090 Laptop: Windows 11 Pro 23H2, 32GB memory, Intel Core i7-10750H @ 2.60GHz, Intel UHD Graphics Comet Lake GT2 and NVIDIA GeForce RTX 3070 Laptop GPU. Laptop 2: Windows 11 Pro 24H2, 16GB memory, Snapdragon(R) X Elite - X1E80100 - Qualcomm(R) Oryon(TM) 12 Core CPU 4.01 GHz, Qualcomm(R) Adreno(TM) X1-85 GPU iPad: iPad Pro M1, 12.9": iPadOS 18.3, Apple Pencil 2, Magic Keyboard Mac: 2023 M2 MacBook Air 15", 16GB memory, macOS Sequoia 15.0.1
Gripsholm Lion Posted July 8, 2024 Posted July 8, 2024 Arguing with Doug Schepers about SVG specs… 🤦♂️ Meliora spero 1 Quote
Megnusin Posted August 26, 2024 Posted August 26, 2024 On 6/17/2024 at 5:23 AM, walt.farrell said: having an Export option to say whether to make it a standalone file or something embeddable An export option would be an excellent solution. Quote
fde101 Posted August 26, 2024 Posted August 26, 2024 On one hand, the XML spec itself recommends the inclusion of the DOCTYPE, so I think the fact that the Affinity apps include it is technically correct, whether you like it or not. The file stands alone, as @walt.farrell suggested, so embedding the image into HTML code later on is largely irrelevant to the task of exporting it from the software. Coming at it from the other direction, as the XML spec does make the DOCTYPE optional, if its removal would cause an application to reject or misinterpret the SVG file, that application would not be conformant with the XML spec, and this would be a bug (or design flaw) in the application opening the file (for requiring the DOCTYPE), not in the Affinity apps (for not including it). On 6/16/2024 at 5:49 PM, Doug Schepers said: In terms of implementation, this should be very easy; the Affinity developers don't need to add anything, they just need to take something out. You are assuming that Serif is writing the XML code directly, but this is highly unlikely; they are probably using a library to write the XML code, and the library may be adding the DOCTYPE automatically. If that is the case and if the library does not provide an option to omit it, Serif would need to switch to a different XML library, or write their own, which would not be the "very easy" change you are suggesting. Some libraries do provide an option for that, and Serif may be able to add an instruction to tell the library to omit it. Other libraries may not provide that as an option. On 6/5/2024 at 7:18 PM, Doug Schepers said: Similarly, the XLink namespace declaration in the SVG is no longer needed (as of 2013 or so), and the `xml:space` and version attributes no longer have any effect. Saying "no longer" suggests they were required at one time, and leaving them out may impact older software which reads the files, so if this change were made it would need to be an option in order to maintain compatibility. As leaving them in place has "no effect", Serif may be simplifying its interface and reducing potential confusion over users wondering what version they need to use by simply including them in the file regardless. Quote
Doug Schepers Posted August 26, 2024 Author Posted August 26, 2024 The SVG code Affinity exports is correct. The SVG code I'm suggesting is also correct. It's not an either-or situation. In both cases, the file works equally well as a standalone file. (This is very easy to test for yourself.) My suggestion makes additional use cases (including embedding in HTML) easier and less error-prone. That's it. That's the only difference. (Well, besides the fact that it yields very slightly smaller file sizes.) There is no difference in how these files will render in any software. I'm not asking you to trust me; you can prove everything I'm saying for yourself. 2 hours ago, fde101 said: Saying "no longer" suggests they were required at one time, and leaving them out may impact older software which reads the files. No, the `xml:space` and `version` attributes were not required, they were always optional; now, they are not only optional, but also have no effect. Try them for yourself. The XLink namespace declaration was indeed required, but not for well over a decade now. Any hypothetical "older software" that might be at risk would have to be very old indeed… the oldest SVG software I'm aware of, Batik, has releases as recent as last year, and works just fine with my suggestions; as does Inkscape, the most common open-source SVG software, with even more recent releases. Illustrator works fine with the changes I've suggested, as does every other SVG editor I've used. The Adobe SVG Viewer (a browser plugin which predates native browser SVG support and which might indeed have choked on a missing XLink namespace, but not the others) was End-of-Lifed on 1 January 2009. All of the web browsers, including Internet Explorer, work as expected with my suggestions. Which specific software are you concerned with for compatibility? Adding options to the export dialog would be a bad UX decision, because it adds needless complexity with no benefit, and might confuse users with a false choice, but whatever makes it easiest for Serif (and everyone else) is fine by me. (Though considering that it's been nearly 3 months and not a peep from Serif, I suspect they aren't listening anyway.) lepr and bbrother 1 1 Quote
GarryP Posted August 26, 2024 Posted August 26, 2024 1 hour ago, Doug Schepers said: (Though considering that it's been nearly 3 months and not a peep from Serif, I suspect they aren't listening anyway.) Serif generally don’t acknowledge feature requests. They read them all, and then they might do something about some of them at some point, or they won’t. I think they stopped acknowledging them because some people, when receiving a “Thanks for your suggestion” reply, imagined that “...and we’ll get started on that straight away so expect it happening soon.” was appended to it. And then those people started to complain that whatever it was wasn’t happening quick enough or to their own self-perceived timescale. For feature requests, we just have to wait and see. Quote
Megnusin Posted August 27, 2024 Posted August 27, 2024 17 hours ago, Doug Schepers said: it's been nearly 3 months and not a peep from Serif, I suspect they aren't listening anyway This is the Affinity user forum. It might be more appropriate to get in touch with Serif through more official channels. Quote
bbrother Posted August 27, 2024 Posted August 27, 2024 22 hours ago, fde101 said: If that is the case and if the library does not provide an option to omit it, Serif would need to switch to a different XML library, or write their own, which would not be the "very easy" change you are suggesting. There is also the option of modifying the library they currently use by writing an additional function if needed. This is something I have often done with open source libraries as a dev. I also don't think that what Doug proposes is so demanding that it would require significant modification to the library. And if you are worried about licensing issues, most open source libraries allow modifications. So I don't think your arguments are very strong compared to @Doug Schepers. 19 hours ago, GarryP said: I think they stopped acknowledging them because some people, when receiving a “Thanks for your suggestion” reply, imagined that “...and we’ll get started on that straight away so expect it happening soon.” was appended to it. Good communication would have solved this problem or at least minimized complaints. But oh well, Serif has always preferred to take the easy way out. 20 hours ago, Doug Schepers said: Though considering that it's been nearly 3 months and not a peep from Serif, I suspect they aren't listening anyway. Just look at the forum for user requests and dates and see what features have been implemented and the answer to the question of whether they are listening to their users will be obvious. --------- P.S Serif's heavy use of open source libraries and thus lowering licensing costs to maximize margins is a topic for a separate discussion. There's nothing wrong with using someone else's work to earn money, if the license allows it. But Serif has mastered this field to perfection. Quote
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.