benkasminbullock
commented
3 months ago On Fri, 2 Aug 2024 at 16:37, fthire @.***> wrote:
Context
As highlighted in #451 https://github.com/KanjiVG/kanjivg/issues/451 and #456 https://github.com/KanjiVG/kanjivg/pull/456 , some parsers may reject SVG files in this repository, likely because the files in this repository use a non-standard prefix name 'kvg' for attributes.
According to the W3C validator https://validator.w3.org/check this is compliant with the standard SVG 1.0. However, it is not compliant with the standard SVG 1.1.
Moreover, it seems that many XML validators are unable to parse those files also. For example this XML validator https://jsonformatter.org/xml-validator reports an error like:
Invalid XML: This page contains the following errors: error on line 33 at column 2: StartTag: invalid element name
I was unable to reproduce this. I copied the text of a kanji I randomly selected using the "Random" button on the viewer at
https://kanjivg.tagaini.net/viewer.html?kanji=%E5%91%91
by going to the "Image source" link and then clicking on "Raw" to get to
https://raw.githubusercontent.com/KanjiVG/kanjivg/master/kanji/05451.svg
and then "view source" using Control-U. Inserting that into the XML validator you suggest and then clicking on "Validate", it said "Valid XML". I also notice that the text "StartTag" does not appear on line 33, or indeed anywhere in any of the KanjiVG files.
https://github.com/user-attachments/assets/9e5b0bb4-9272-4273-a0be-632499120bcb
I have checked with multiple validators, and none indicate that it is valid.
I have some questions about this.
Suggestions
There is already an pull request opened regarding this issue (#456 https://github.com/KanjiVG/kanjivg/pull/456), but there seems to be some hesitation in merging it.
Hesitation, deviation, and repetition will all draw the ire of Nicholas Parsons I'm sure.
I’d like to raise a few questions for consideration:
- XML compliance:
The files are not XML compliant (according to this XML validator https://jsonformatter.org/xml-validator). However, it seems to be enough to add in the svg tag the following attribute: xmlns:kvg=" http://kanjivg.tagaini.net" to make the files compliant. This simple change maintains SVG 1.0 compliance and makes the files XML compliant (based on my tests). Would it be possible to consider this change? I've also suggested this on the PR here https://github.com/KanjiVG/kanjivg/pull/456#issuecomment-2264735171)?
I am very concerned about your tests and I would prefer you re-check what you've done at this stage.
- SVG 1.1 compliance:
Although the files comply with SVG 1.0, this standard is over 20 years old and has been superseded by SVG 1.1. For compatibility with multiple tools, would it be beneficial to consider updating to SVG 1.1 compliance in the future?
This is the only suggestion which makes sense to me. When I tried to get pverdy to discuss whether that was a solution to the problem that he was bringing up, he went off on another tangent about how we did not need to change to SVG 1.1 but could keep SVG 1.0, although we would have to remove various things. He hadn't justified the changes at all in my opinion. I brought it up on the mailing list for KanjiVG but there was not a very concrete response.
- Documentation:
The current website doesn't mention that the SVG format is compliant with SVG 1.0 but not 1.1. Adding a note about this could be helpful. Similarly, a note regarding XML compliance might also be valuable.
The current website does prominently mention that the KanjiVG is SVG 1.0 compliant on the top page at the bottom. Please refer to https://kanjivg.tagaini.net/index.html. You can actually check that by clicking the link where you will go straight to the validator:
Since it would not validate as SVG if it was not XML, it is also clearly valid XML.
I hope these suggestions are helpful and can be considered for improving compatibility and compliance. Please let me know if there's anything else I can do to assist with these updates or if there are specific reasons for maintaining the current standards that I might have missed.
Thank you for your offer of help. The first step to take is to go back and check your results above.
Message ID: @.***>
saroupille
Context
As highlighted in #451 and #456 , some parsers may reject SVG files in this repository, likely because the files in this repository use a non-standard prefix name 'kvg' for attributes.
According to the W3C validator this is compliant with the standard SVG 1.0. However, it is not compliant with the standard SVG 1.1.
Moreover, it seems that many XML validators are unable to parse those files also. For example this XML validator reports an error like:
I have checked with multiple validators, and none indicate that it is valid.
Suggestions
There is already an pull request opened regarding this issue (#456), but there seems to be some hesitation in merging it. I’d like to raise a few questions for consideration:
The files are not XML compliant (according to this XML validator). However, it seems to be enough to add in the
svgtag the following attribute:xmlns:kvg="http://kanjivg.tagaini.net"to make the files compliant. This simple change maintains SVG 1.0 compliance and makes the files XML compliant (based on my tests). Would it be possible to consider this change? I've also suggested this on the PR here)?Although the files comply with SVG 1.0, this standard is over 20 years old and has been superseded by SVG 1.1. For compatibility with multiple tools, would it be beneficial to consider updating to SVG 1.1 compliance in the future?
The current website doesn't mention that the SVG format is compliant with SVG 1.0 but not 1.1. Adding a note about this could be helpful. Similarly, a note regarding XML compliance might also be valuable.
I hope these suggestions are helpful and can be considered for improving compatibility and compliance. Please let me know if there's anything else I can do to assist with these updates or if there are specific reasons for maintaining the current standards that I might have missed.