invalid SVG images from this project: unbound XML prefix "kvg:"

[verdy-p]

Many SVG images from this project are not validating and not rendering now with stricter SVG parsers. The reason is that these images from KanjiVG are using the prefix "kvg:" for various of its attributes, which is not declared as an XML namespace.

So these SVG are not rendering for example in Google Chrome (which displays the validation error), or in Wikimedia Commons by its SVG-to-PNG thumbnail renderer. They may have rendered in the past due to more lenient parsing (where these non-SVG attributes were simply ignored) but this is not longer the case.

Please declare the "kvg:" namespace with an XML namespace declaration and bind it to a unique URI (which should be pointing to a project description page). XML validation is absolutely required before any other validation of the SVG schema.

As well, the "kvg:" prefix is used in the value of id="" attributes, which is less critical but does not respect the syntax for SVG identifiers (where the colon ":" should not be used but replaced by a "-"). This is not an XML error (so the document may still be parsed by XML) but an violation of the SVG schema and of SVG recommandations (and similar recommandation of HTML5 when SVG images are embedded in HTML documents). It complicates the element referencing notably with CSS for selectors.

[benkasminbullock]

You've claimed that there is no declaration of the namespace, but each image in the collection already has an extensive collection of XML-related verbiage, including what appear to be two XML namespace declarations:

https://github.com/KanjiVG/kanjivg/blob/master/kanji/00021.svg?short_path=31dc8b1

<?xml version="1.0" encoding="UTF-8"?>
<!--
...
-->
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.0//EN" "http://www.w3.org/TR/2001/REC-SVG-20010904/DTD/svg10.dtd" [
<!ATTLIST g
xmlns:kvg CDATA #FIXED "http://kanjivg.tagaini.net"
kvg:element CDATA #IMPLIED
kvg:variant CDATA #IMPLIED
kvg:partial CDATA #IMPLIED
kvg:original CDATA #IMPLIED
kvg:part CDATA #IMPLIED
kvg:number CDATA #IMPLIED
kvg:tradForm CDATA #IMPLIED
kvg:radicalForm CDATA #IMPLIED
kvg:position CDATA #IMPLIED
kvg:radical CDATA #IMPLIED
kvg:phon CDATA #IMPLIED >
<!ATTLIST path
xmlns:kvg CDATA #FIXED "http://kanjivg.tagaini.net"
kvg:type CDATA #IMPLIED >
]>

I can vouch that every single image in the entire collection contains exactly the above text, with the copyright notice.

If the XML verbiage in the KanjiVG files is in error somehow then please point out more specifically where, and how it should be altered, and give an example of a validator we can use to check against, otherwise it's quite hard for us to know what to do. I checked it with the W3C validator, which claims the above is perfectly correct.

https://validator.w3.org/check?uri=https%3A%2F%2Fraw.githubusercontent.com%2FKanjiVG%2Fkanjivg%2Fmaster%2Fkanji%2F00021.svg&charset=%28detect+automatically%29&doctype=Inline&group=0

[verdy-p]

What is included is actually a DTD, that most SVG processors do not processus and that are not standard for SVG, only processed by a full XML processor(with Security risks) and forbiden in HTML5 embedded version of SVG. Instead of including a SMGL-like DTD, which still does not declare the XML namespace, you should include the xmlns:kvg="" pseudo-attribute required by XML, giving it a unique URI value to your projet. There's no requirement that this URI ponts to an existing Web page or document but it must be unique for the schéma you use. At that place you may display any htmm page with links to a DTD or better an XML schema. When this is done you no longer need any included DTD in SVG files to use the "kvg:" prefix that has been been bound to your URI.

All this is required for SVG conformance

Le mar. 11 juin 2024, 05:14, Ben Bullock @.***> a écrit :

You've claimed that there is no declaration of the namespace, but each image in the collection already has an extensive collection of XML-related verbiage, including what appear to be two XML namespace declarations:

https://github.com/KanjiVG/kanjivg/blob/master/kanji/00021.svg?short_path=31dc8b1

<?xml version="1.0" encoding="UTF-8"?>

<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.0//EN" "http://www.w3.org/TR/2001/REC-SVG-20010904/DTD/svg10.dtd" [ <!ATTLIST g xmlns:kvg CDATA #FIXED "http://kanjivg.tagaini.net" kvg:element CDATA #IMPLIED kvg:variant CDATA #IMPLIED kvg:partial CDATA #IMPLIED kvg:original CDATA #IMPLIED kvg:part CDATA #IMPLIED kvg:number CDATA #IMPLIED kvg:tradForm CDATA #IMPLIED kvg:radicalForm CDATA #IMPLIED kvg:position CDATA #IMPLIED kvg:radical CDATA #IMPLIED kvg:phon CDATA #IMPLIED > <!ATTLIST path xmlns:kvg CDATA #FIXED "http://kanjivg.tagaini.net" kvg:type CDATA #IMPLIED > ]>

I can vouch that every single image in the entire collection contains exactly the above text, with the copyright notice.

If the XML verbiage in the KanjiVG files is in error somehow then please point out more specifically where, and how it should be altered, and give an example of a validator we can use to check against, otherwise it's quite hard for us to know what to do. I checked it with the W3C validator, which claims the above is perfectly correct.

https://validator.w3.org/check?uri=https%3A%2F%2Fraw.githubusercontent.com%2FKanjiVG%2Fkanjivg%2Fmaster%2Fkanji%2F00021.svg&charset=%28detect+automatically%29&doctype=Inline&group=0

image.png (view on web) https://github.com/KanjiVG/kanjivg/assets/102005/a8f35624-c18c-4d2b-b8f7-137847c97f16

— Reply to this email directly, view it on GitHub https://github.com/KanjiVG/kanjivg/issues/451#issuecomment-2159700813, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAKSUGY2MYSCDBG2NBDCFGDZGZTRVAVCNFSM6AAAAABJDKXYZOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCNJZG4YDAOBRGM . You are receiving this because you authored the thread.Message ID: @.***>

[benkasminbullock]

Thank you for getting back with a response. Can you please do the following:

(a) Give a specific example of what you think the file should look like. Take one of the existing files and edit it so that it is correct according to your ideas.

(b) Give us information about a validator which will check that the file meets the specifications you claim to be necessary.

Could you also explain why it is necessary for the files to be compatible with an HTML5 embedded version of SVG, to the extent that all the files need to be altered? The W3C validator says that the SVG is perfectly valid, despite what you say, and end users are of course free to alter the files themselves, so I can't see any clear need for the changes you suggest, which seems to involve drastic editing of virtually every file in this large repository, which is sure to cause disruption to existing users.

[verdy-p]

Is it really complicate to just add the pseudo-attribute xmlns:kvg="http://..." to the main "svg" element, and drop the embedded DTD completely? Embedded DTD requires a complex DTD parser (based on the old SGML parser, even if it has been limited in XML by a some limitations, expanding the DTD is very tricky, costly and has severe security issues). For XML parsing of SVG we don't need that parser cost at all. Many SVG parsers are unable to parse embedded DTDs, or just refuse to parse them (this is the case for example for SVG files in Wikimedia Commons. If we drop the embedded DTD, the XML is no longer valid at all: we need the xmlns declaration instead (SVG requires that all non-SVG attributes must use their own XML namespace that MUST be declared. Declaring "xmlns:kvg" as a DTD "attribute" is a hack (XML namespaces declarations in any element are NOT XML attributes). As well the existing embedded DTD has to do that declaration for each attribute in each element, and it does that only for the "g" element.

You can see examples for example in: https://commons.wikimedia.org/w/index.php?title=Category:KanjiVG_stroke_order_images&filefrom=%E3%83%B2+-+U%2B030F2-+KanjiVG+stroke+order.svg#mw-category-media Broken files (not rendered) were previously rendered by a "lenient" parsing of the SVG (without strict validation). It was too slow when using SVG parsers based on SGML-based parsers capable of expanding the DTD declaration. Now the XML parser used must be able to load the XML completely and validate it, but any embedded DTD is NOT supported. If the embedded DTD was removed, initially it was working but now that XML validation are enforced (for security reasons), the entire SVG is NOT loaded at all by the XML parser, and fails due to the absence of declaration of the "kvg:" prefix.

All these broken files have to be edited, not by restoring the embedded DTD (it does not work), but simply by using the XML pseudo-attribute xmlns:kvg="http://..." directly in the main "svg" element (you don't need to add it multiple times on each "g" elements).

An example of edit is in the history shown at

https://commons.wikimedia.org/wiki/File:%E6%95%B0_-_U%2B06570_-_KanjiVG_stroke_order.svg

(1) The initial version (2 Avril 2021 19:32) had the embedded DTD dropped, but not declaring the XML namespace: this no longer works today. I fixed it (today) by just adding that XMLNS declaration.

(2) I also further edited it to use ID values without any colon, there was a "kvg:" prefix there too (it does not need any DTD to do that, and the DTD in fact does not validate such values the way XML wants it), but strict XML validation does not work (the identifier is invalid with a colon, even if for now most SVG parsers don't care about it, as long as these ID's are NOT referenced inside the file); I have kept these superfluous IDs, just modified them to use hyphens "-" instead of ":", but in fact I could have removed them, they are not even part of the KanjiVG schema and not needed, except for "internal description" purpose.)

And now with these edits, the KanjiVG images work perfectly. I have signaled this bug to the initial file uploader (which was not aware, given that it was working in the past in the SVG-to-PNG thumnail generator of Wikimedia Commons, but now it no longer works; and it has never worked in any browser).

There's a discussion there:

https://commons.wikimedia.org/wiki/Category_talk:KanjiVG_stroke_order_images

The solution I used is very simple to do, but it requries uploading new versions of the affected files that are no longer rendering (Wikimedia Commons signals a "cannot load XML" error; but when trying to view the file this error is displayed too. When linking to the mediafile itself in a separate browser window, we also get a browser error. We can only view its "source" (using the "view source" utility of modern browsers, or in the browser console, from which we can copy-paste the content into an external text editor, where we can add the missing xmlns declaration and then upload this new edited version to replace the existing version). This takes time again and most other users of KanjiVG glyphs need to edit all of them to use them.

My suggestion is then the same as I told: drop any embedded DTD, just insert a single "xmlns:kvg" pseudo attribute to the main "svg" element. The result is smaller. (This editing can be even automated.) For end users of your site and project and for submitters, the life will be simpler.

The other benefit is that now you can use the URI of your project to bind this namespace, and point it to a page where it explains the schema, or that contains a XML schema (fow now I've used the URI of your project, exactly the URI shown in the top boiler comments for attribution, and that you use also in your existing old DTDs). You can also bind the namespace to the XML schema (note that there are several competing XML schema syntaxes, choose the one you prefer, but the old DTD is not really a schema, as it has no semantics, and cannot validate everything you'll want (the same is true for the old DTD used to partially validate HTML, it has been deprecated, and HTML5 now forbids using any embedded DTD, even in its XHTML5 variant based on XML validation but with stricter constraints for security reasons that HTML5 documents).

Note that on Wikimedia Commons (in the example above), not declaring the XMLNS was supported, because Wikimedia used lenient parsing based on SMLG parsing rules, however it was very slow, consumed lot of resources, and caused security issues. The new SVG parser uses strict XML validation, forbids the use of embedded DTD, so images won't be rendered at all now and no PNG image will be returned; the existing thumbnails may persist in its local cache but displaying any SVG image at a PNG image size missing in cache returns now such errors. All these images need to be fixed now (like what I did).

The SVG specifications also explictly allows user agents to not accept and process any embedded DTD (even if they are still valid according to XML 1.0 and SVG 1.0). The W3C validator still accepts these DTD, when using the "full" profile. But it is invalid in "Tiny SVG" profiles.

Many sites and user agents will simply reject SVG files with embedded DTD (given the huge cost for completely validating them prior to serve them: the embedded DTD can cause severe havoc, notably in its replacement texts, that can "bypass" the normal syntax: modern web browsers (including Mozilla Firefox, MSEdge, Chrome, Chromium and Safari) encountering SVG files with a DTD use a very slow path trying to validate them to enforce the security and avoid breaches and various attacks, such as malicious scripting). XML namespace declarations solve the problem very cleanly without the security risks associated to DTD's, and allows user agents to use much faster processing with much less resources.

[verdy-p]

About id attributes in SVG, see https://svgwg.org/svg2-draft/struct.html#Core.attrib (the doc still says that user agents must still accept the SVG even if the id does not validate XML 1.0 rules about their value; this is not recommanded however)

5.11.2. Attributes common to all elements: ‘id’

Must reflect the element's ID [DOM]. The ‘id’ attribute must be unique within the node tree, must not be an empty string, and must not contain any whitespace characters.

Additional requirements apply in order for the ‘id’ attribute to be valid in XML documents, as defined in the specification for the relevant version of XML. A stand-alone SVG document uses XML 1.0 syntax [xml], which specifies that valid ‘id’ values are XML name tokens. Valid XML 1.0 names only include designated characters (letters, digits, and a few punctuation marks), and do not start with a digit, a full stop (.) character, or a hyphen-minus (-) character.

User agents should process ‘id’ values in SVG files irrespective of XML validity.

Authors should avoid the use of ‘id’ values that would be parsed as an SVG view specification or a basic media fragment when used as a URL target fragment.

This requires that id must be "XML name tokens" that do not contain any "#" for basic media fragments or for SVG view specifications. "XML name tokens" are defined by:

[4] NameStartChar ::= ":" | [A-Z] | "_" | [a-z] | [#xC0-#xD6] | [#xD8-#xF6] | [#xF8-#x2FF] | [#x370-#x37D] | [#x37F-#x1FFF] | [#x200C-#x200D] | [#x2070-#x218F] | [#x2C00-#x2FEF] | [#x3001-#xD7FF] | [#xF900-#xFDCF] | [#xFDF0-#xFFFD] | [#x10000-#xEFFFF] [4a] NameChar ::= NameStartChar | "-" | "." | [0-9] | #xB7 | [#x0300-#x036F] | [#x203F-#x2040] [5] Name ::= NameStartChar (NameChar) [6] Names ::= Name (#x20 Name) [7] Nmtoken ::= (NameChar)+ [8] Nmtokens ::= Nmtoken (#x20 Nmtoken)*

Technically the ":" is acceptable here (it is part of NameStartChar) but not recommanded (notably for their use in CSS selectors, that would require using escaping to reference such IDs). See also the definition of ids in CSS:

https://www.w3.org/Style/css3-selectors-updates/WD-css3-selectors-20010126.fr.html#id-selectors

And the lexical production of "IDENT" for CSS:

https://www.w3.org/Style/css3-selectors-updates/WD-css3-selectors-20010126.fr.html#lex

where there is this restriction:

nmstart ::= [a-z]|{nonascii}|{escape} nmchar ::= [a-z0-9-]|{nonascii}|{escape}

meaning the escaping is required if there are ASCII characters that are not basic Latin letters (the CSS lexer is case-insensitive and works with 8-bit input codes, so the encoding of CSS must be ASCII-compatible, or converted to UTF-8), digits or hyphens, or any non-ASCII character:

nonascii ::= [\200-\377] unicode ::= \{h}{1,6}[ \t\r\n\f]? escape ::= {unicode}|\[ -~\200-\377]

For the use of any SVG directly embedded in HTML5 documents, you have no choice: you MUST drop the embedded DTD (the "!DOCTYPE" declaration and the "!ATTLIST"), and explicitly use the XMLNS declaration (ideally in the "svg" HTML5 element rather than each "g" subelements), and as well validate HTML5 rules for IDs (or you need to rename your existing "id" attributes into "kvg:id" attributes to avoid HTML5 rules on IDs, so that you can insert UTF-8 encoded ideographs in these identifiers, without having to use any escape for each byte of the UTF-8 encoding of these characters, and to avoid the uniqueness rule for IDs used throughout the HTML5 document!)

[verdy-p]

Now if you want an existing validator, you can use the W3C validator, but select the "SVG 1.1 Strict" or "SVG 1.1 Basic" profile in options rather than the more lenient "XML 1.0" profile or autodetection (which is also much slower and frequently fails due to resources exhaustion in the W3C site if parsing with the "full" SVG 1.0/XML 1.0 detected profile). The W3C will probably soon terminate its support for the full XML 1.0 profile which causes them maintenance nightmares on their site. It no longer recommends using XML 1.0 and since long it recommends not using any DTD in XML and SVG, but using XMLNS declarations instead.

This is already the case for HTML5 (and it has permitted huge progresses in performance and security in web browsers, some of them having even dropped their support of embedded DTD with HTML4, along with many of its old "compatibility" tricks which caused severe security issues to users). Modern web browsers also have policies that can be enforced (e.g. by corporate policies) to forbid HTML4 or DTD-parsing in HTML, XML and SVG (or that require using specific software to secure their use). DTD's are old SGML things inherited from the past. The safer replacement for DTD's in XML and SVG is to use XML schemas (but these schemas are not required to process SVG safely).

[benkasminbullock]

Thanks for your partial response. It would make life much easier for me if you would actually do the thing I asked you to do. Since you're suggesting changing the format of all the files, I'll ask other people on the mailing list what they think.

https://groups.google.com/g/kanjivg/c/LO8qiufW7rc

[verdy-p]

"Partial response ?" What is missing, I gave all the details, with live examples, and justifications, plus additional documentation from W3C with relevant links and extracts. I don't know what I can add. The change suggested is very simple, and easily automatable.

[benkasminbullock]

Apologies, I read your messages as email from github on the phone originally and replied accordingly. Looking at the github page here now, I think you've edited your messages quite extensively since I read them. You seem to have made quite a good case for making the change, but since this would require a change to all of the image files, I've posted as above to the KanjiVG mailing list to get a response.

[benkasminbullock]

Since the images are already valid SVG 1.0, the title of this issue was misleading. What you seem to actually be asking for us to do is to upgrade the version of SVG we're using for the KanjiVG images, so I've changed the title of the issue to reflect that better.

I haven't received any responses on the mailing list about this yet, so initially what I plan to do is to create a branch of the repository called "newsvg" where we can experiment with changing the format over, and see where it goes.

https://github.com/KanjiVG/kanjivg/tree/newsvg

Obviously if you want to contribute to making the changeover, it will happen faster. A good starting point would be this software, which is my main assistant in editing the files at the moment:

https://github.com/benkasminbullock/kvg

I may put that under the KanjiVG group at some point.

[benkasminbullock]

About id attributes in SVG, see https://svgwg.org/svg2-draft/struct.html#Core.attrib

This is the SVG2 draft standard. Are you proposing to use that standard for the KanjiVG files? It's not very clear from the top of that document whether it's an accepted standard yet. There is no validator for SVG2 at the W3C validator site.

[verdy-p]

No i was just referencing the current old and well known release of svg and XML specs. i gave the links. These are not bêta versions. Xml1. 1 is possible, but but not necessary for this change. Svg 1.0 or 1.1 can both be used. All that is requested is dropping the old embedded DTD that is supported in svg only because of XML (that includes it, but does not recommand its use) and that many svg processors don't like or that cause severe performance degradation, or security issues if they are allowed and not checked with the fast processing, or that cause processors to reject the file and not process it if they have not implemented the slow mitigation of security risks associated with the full DTD parsing.

Le ven. 14 juin 2024, 09:57, Ben Bullock @.***> a écrit :

About id attributes in SVG, see https://svgwg.org/svg2-draft/struct.html#Core.attrib

This is the SVG2 draft standard. Are you proposing to use that standard for the KanjiVG files? It's not very clear from the top of that document whether it's accepted standard yet. There is no validator for SVG2 at the W3C validator site.

— Reply to this email directly, view it on GitHub https://github.com/KanjiVG/kanjivg/issues/451#issuecomment-2167462685, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAKSUG3ZJ45XASDI5IFKFD3ZHKO7VAVCNFSM6AAAAABJDKXYZOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCNRXGQ3DENRYGU . You are receiving this because you authored the thread.Message ID: @.***>

[benkasminbullock]

No i was just referencing the current old and well known release of svg and XML specs. i gave the links.

You gave a link to the SVG2 standard there. If we're proposing to upgrade to another standard then please be specific.

These are not bêta versions. Xml1. 1 is possible, but but not necessary for this change. Svg 1.0 or 1.1 can both be used. All that is requested is dropping the old embedded DTD that is supported in svg only because of XML (that includes it, but does not recommand its use) and that many svg processors don't like or that cause severe performance degradation, or security issues if they are allowed and not checked with the fast processing, or that cause processors to reject the file and not process it if they have not implemented the slow mitigation of security risks associated with the full DTD parsing.

Currently the files are parsed correctly as SVG 1.0, so it's not a matter of "just doing XYZ". If we change to another standard for SVG then we need to be clear what standard is to be used. Also, these files are currently in use by hundreds if not thousands of projects, so any change in the file format needs to be done carefully.

[benkasminbullock]

If you aren't prepared to specify the version of SVG that you want to upgrade to, I'll close this issue.

[verdy-p]

Even svg 1.0 is enough. I don not proposé any upgrade. The links were to current svg standard, but in parts that have not changed at all.

Le sam. 15 juin 2024, 03:27, Ben Bullock @.***> a écrit :

If you aren't prepared to specify the version of SVG that you want to upgrade to, I'll close this issue.

— Reply to this email directly, view it on GitHub https://github.com/KanjiVG/kanjivg/issues/451#issuecomment-2169024863, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAKSUGYY4S6FEZHE23VBSHDZHOJ7ZAVCNFSM6AAAAABJDKXYZOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCNRZGAZDIOBWGM . You are receiving this because you authored the thread.Message ID: @.***>

[verdy-p]

You close immediately befote asking clarifications. I was clear even since the begining that svg 1.0 was enough. And note that the w3c validator has known issues to recognize the effective version used, but this does not charge the fact that KanjiVG uses a non-svg extension for custom attributes (only needed for tracking purpose in the projet itself, and never used by Svg renderers. These extensions need proper declaration, even in SVG 1.0 and Even svg 1.0 does not recommand using any embedded DTD, which is clearly not needed.

Yoi closed it too early.

Le sam. 15 juin 2024, 03:27, Ben Bullock @.***> a écrit :

If you aren't prepared to specify the version of SVG that you want to upgrade to, I'll close this issue.

— Reply to this email directly, view it on GitHub https://github.com/KanjiVG/kanjivg/issues/451#issuecomment-2169024863, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAKSUGYY4S6FEZHE23VBSHDZHOJ7ZAVCNFSM6AAAAABJDKXYZOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCNRZGAZDIOBWGM . You are receiving this because you authored the thread.Message ID: @.***>

[benkasminbullock]

If you want these changes you'll need to contribute them yourself. I'm not willing to spend any more time discussing with you.

[benkasminbullock]

I've restored your original title since you don't think the version of SVG needs to be upgraded.

[benkasminbullock]

As far as I'm concerned this issue can be left open if you wish to do so. However, I won't be taking any further action.

[verdy-p]

Note that if you don't want to update here, I have fixed this issue in many files imported in Wikimedia Commons to fix the issue, by doing exactly whatI described above. Now these SVG files are correctly rendered with the explicit declaration of the xmlns:kvg in the svg root element. I have done that alaready for about one thousand files there and each time the rendering was fixed.

I have not changed anything else, not changed the SVG version, and I have kept all licencing, attributions and comments (your custom "kvg:*" attributes are kept as is and work directly with the explicit xmlns:kvg declaration, in ALL SVG renderers I tested, in browsers or in standalone tools.

No embedded DTD is used, it is clearly never needed in valid SVG (and even deprecated in ALL versions, including for security reasons: there are multi CVE issues related to embedded DTD in SVG, all advisories recommend NOT using that old XML feature, including for SVG; embedded DTD are also NOT supported in most SVG profiles, including SVG Tiny). You don't need this even for your local project.

It is impossible to validate your extended schema with these "kvg:*" attributes in the W3C validator without seeing "errors", which are just in fact warnings because the W3C validator will accept but will NEVER be able to validate these custom extensions that ONLY your project defines privately).

The SVG specifications (as an XML application, or as part of HTML5) clearly says that custom private attributes must just be ignored if they are not supported, and this is fine "as is"; the embedded DTDs cause much more blocking troubles causing many tools to reject your files containing them.

[benkasminbullock]

To repeat myself, I won't be taking any further action on this issue.

[benkasminbullock]

The current KanjiVG format is SVG 1.0. The error reported in this results from trying to parse it using the SVG 1.1 standard. We probably should upgrade to the SVG 1.1 standard, or at the least offer SVG 1.1 formatted files in a release, and make the KanjiVG files valid for that standard. The rest of this bug report and the related discussions seems to be noise.