Re: [Tools-discuss] [rfc-i] What do do about SVG

Hi Nevil,

I'll write off list with the things I discovered. Some of it was quite
a long time ago, so I'll have to look back at my emails to Jim.

One thing for now though. I'm illiterate in RelaxNG, but it seems
to me that <style> is definitely allowed in two or three places
in RFC7996, and it isn't even defined in svgcheck/word_properties.py
so it's no wonder that svgcheck rejects it.

Regards
   Brian

On 14-May-21 16:23, Nevil Brownlee wrote:
> Hi Brian and Tony:
> 
> I'm the guy who wrote the original version of svgcheck.py.
> Jim Schaad did the production engineering on it, and I worked with him
> to make sure it was compliant with the RNC schema that appears in RFC
> 7996.
> 
> I recently downloaded svgcheck (from the RFC Editor site, I think),
> that's version 0.6.0;  I could work through that to fix the problems
> Brian reported.  However, it will need someone on the Tools team to
> get the fixed version back into their repository.
> 
> Please let me know if you'd like me to make the changes to svgcheck
> (it will take a week or two though).
> 
> Cheers, Nevil
> 
> 
> On Fri, May 14, 2021 at 12:29 AM HANSEN, TONY L <tony@att.com> wrote:
>>
>> On 5/13/2021, 12:24 AM, "rfc-interest on behalf of Brian E Carpenter" <rfc-interest-bounces@rfc-editor.org on behalf of brian.e.carpenter@gmail.com> wrote:
>>
>> After some investigation, I've understood that this particular problem
>> is because svgcheck doesn't allow <style> as a child of <svg>. Nor, after
>> some experiments, as a child of <path>, even though the RelaxNG in
>> RFC7996 appears to allow it. (Also, when <style> defines a color, and
>> I patch svgcheck/word_properties.py to allow <style>, svgcheck doesn't
>> seem to detect the color elements inside <style>.)
>>
>> In the course of this I found another instance of a particular
>> bug in svgcheck (failure to increment errorCount).
>>
>> So we have the facts that
>> (a) svgcheck is buggy;
>> (b) it doesn't implement the RelaxNG in RFC7996;
>> (c) sadly, we lost the maintainer of the code;
>> (d) our subset of TinySVG is very hard to generate with most drawing tools;
>> (e) experience shows that special SVG mangling programs are needed to prepare files for inclusion in RFCs;
>> (f) we've been told that TinySVG is no longer alive at W3C;
>> (g) browsers appear to be fully competent at interpreting full SVG.
>>
>> How can we make progress on resolving this?
>>
>> As an FYI, I see three maintainers listed for svgcheck at https://pypi.org/project/svgcheck/. Can we poke them to address some of these issues, in particular a&b? Or provide them pull requests for the code?
>>
>> d,e,f are somewhat intractable unless we throw it out entirely and move to full SVG. g is one argument for that.
>>
>> However, there were several reasons behind going with a subset, laid out in section 2 of RFC 7996 and section 3.2 of RFC 6949. Any movement to support a larger version of SVG needs to address these requirements first.
>>
>> Tony
>>
>> _______________________________________________
>> rfc-interest mailing list
>> rfc-interest@rfc-editor.org
>> https://www.rfc-editor.org/mailman/listinfo/rfc-interest
> 
> 
> 