Subject: [rfc-i] No, constraining to a custom SVG profile is not trivial

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 15 Jan 2020 15:14:37 -0500

I am just attempting to massage my diagrams to get them into the SVG
profile. Contrary to the claim made in RFC7996, creating a completely
non-standard profile is not a trivial matter.

It is not going to be possible to do the conversion properly short of
writing custom translators for each drawing tool or writing an SVG renderer
that uses the profile as backing. It is necessary to keep track of the X
and Y position and the current coordinate system and font size to perform
the processing right.

The specification is inconsistent and does not match the constraints
imposed by the tool.

WARNING:     1 --- element 'svg' does not allow attribute 'stroke-miterlimit'

That's not what the spec says.

attribute stroke-miterlimit { "inherit" | xsd:string }?,

Dealing with <tspan> elements requires the dx,dy coordinates thrown out by
my package (Visio) to be converted to align.

The range of allowed values for stroke varies from one element to another.
Sometimes "none" is allowed, other times not.

I am not going to be able to provide a general purpose conversion tool
because the problem space is simply too large.
_______________________________________________
rfc-interest mailing list
[email-masked]
https://www.rfc-editor.org/mailman/listinfo/rfc-interest

---

From: Doug Royer <[email-masked]>
Date: Wed, 15 Jan 2020 17:56:01 -0700

On 1/15/20 1:14 PM, Phillip Hallam-Baker wrote:
> I am just attempting to massage my diagrams to get them into the SVG profile. Contrary to the claim made in RFC7996, creating a completely non-standard profile is not a trivial matter.

If this helps, I use DIA (a program) to make simple SVG files (export as ...). I have not had the need to translate complex SVG files yet. I have also used this script on some Postscript -> SVG converted files.

It also works with DOT set of tools (ImageMagic command line tools): dot, neato, twopi, circo, fdp, sfdp, patchwork, and osage)

Attached is a simple XSLT script that I created that simply rips out invalid elements. It would not be to difficult to make it alter attribute values. Attributes like 'style' would take some extra work. So far, I have not needed that.

When I create the SVG files, I just don't use color and complex styles. If needed this could be expanded.

-- 
Doug Royer - (http://DougRoyer.US)
[email-masked]
714-989-6135

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 15 Jan 2020 21:23:53 -0500

Thanks, I think I have a system that might be sufficient for most of it.
Main thing missing right now is end of line markers and I have to work out
what the transforms are on those.

Basically, I wrote a CSS parser this morning and a partial SVG engine that
tracks the X, Y and Font-Size attributes this afternoon. Net result is I
can massage the files into something almost OK. Just have to call it out
from my RFC converter and it is done.

Of course at this stage, it might have been easier to work out how to write
a converter for Word diagram format.

On Wed, Jan 15, 2020 at 7:56 PM Doug Royer <[email-masked]> wrote:

> If this helps, I use DIA (a program) to make simple SVG files (export as
> ...). I have not had the need to translate complex SVG files yet. I have
> also used this script on some Postscript -> SVG converted files.
>
> It also works with DOT set of tools (ImageMagic command line tools): dot,
> neato, twopi, circo, fdp, sfdp, patchwork, and osage)
>
> Attached is a simple XSLT script that I created that simply rips out
> invalid elements. It would not be to difficult to make it alter attribute
> values. Attributes like 'style' would take some extra work. So far, I have
> not needed that.
>

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 16 Jan 2020 16:21:10 +1300

> Attached is a simple XSLT script that I created that simply rips out invalid elements.

The problem with colour/greyscale is that this isn't enough. If you have very dark blue text on a very pale pink background, what happens? svgcheck makes this black on black; my heuristic makes it black on white. What would your script do?

But I do agree with Phill, this is a non-trivial issue. Currently I think doing new drawings with a simple tool like DIA is the only practical way.

Allowing unrestricted SVG has plenty of issues too.

Regards
   Brian

On 16-Jan-20 15:23, Phillip Hallam-Baker wrote:
> Thanks, I think I have a system that might be sufficient for most of it. Main thing missing right now is end of line markers and I have to work out what the transforms are on those.
> 
> Basically, I wrote a CSS parser this morning and a partial SVG engine that tracks the X, Y and Font-Size attributes this afternoon. Net result is I can massage the files into something almost OK. Just have to call it out from my RFC converter and it is done.
> 
> Of course at this stage, it might have been easier to work out how to write a converter for Word diagram format.
> 
> 
> On Wed, Jan 15, 2020 at 7:56 PM Doug Royer <[email-masked] <mailto:[email-masked]>> wrote:
> 
>     [email-masked] <mailto:[email-masked]>
>     714-989-6135
>     [email-masked] <mailto:[email-masked]>

---

From: Doug Royer <[email-masked]>
Date: Wed, 15 Jan 2020 21:33:19 -0700

> The problem with colour/greyscale is that this isn't enough. If you have very dark blue text on a very pale pink background, what happens? svgcheck makes this black on black; my heuristic makes it…

I use this tool with SVG files that I planned to use in this way.

I have not needed to solve contrast problems yet. When I do, my plan is to make anything more than 50% black, else white.  It can not handle complex SVG with shades of darkness or complex attribute values (like style). If I get energetic, I could do some contrast computation. Never tried anything that complex with XSLT, might have to do some scripting for that.

The next rev, I am going to tackle the style attribute. I do not know if it is solvable with XSLT. More of an intellectual exercise than a needed goal. If it gets complex, scripting will do.

> But I do agree with Phill, this is a non-trivial issue. Currently I think doing new drawings with a simple tool like DIA is the only practical way.

Yea, DIA and the DOT tools just make stick drawings. You can make nice flow and protocol state drawings with the dot tools (and with PIC for those of you that are troff experts).

---

From: Leonard Rosenthol <[email-masked]>
Date: Thu, 16 Jan 2020 14:36:50 +0000

Have you folks looked at the SVG Native proposal from the W3C - https://w3c.github.io/svgwg/specs/svg-native/index.html?

While it doesn't address all issues (like color), it should cover most/all of the other key issues that are of concern.  And it would give you a standard profile to target.

Leonard

On 1/15/20, 11:33 PM, "rfc-interest on behalf of Doug Royer" <[email-masked] on behalf of [email-masked]> wrote:

    

    

    -- 
    Doug Royer - (https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2FDougRoyer.US&amp;data=02%7C01%7Clrosenth%40adobe.com%7Ce472955bdf344aea564908d79a3d3c1a%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C637147460109168558&amp;sdata=j7fkjiq8qMlb1bCvQ98ghu5eHBCgj5kMwsZkE7%2FvAK0%3D&amp;reserved=0)
    [email-masked]
    714-989-6135
    _______________________________________________
    rfc-interest mailing list
    [email-masked]
    https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fmailman%2Flistinfo%2Frfc-interest&amp;data=02%7C01%7Clrosenth%40adobe.com%7Ce472955bdf344aea564908d79a3d3c1a%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C637147460109168558&amp;sdata=Xtc2yOwAhqL7PTOoy2tq8tZ8%2BFSkRFGaejcf73m2ujM%3D&amp;reserved=0

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 17 Jan 2020 07:49:33 +1300

That's exactly what my Python patch does. If R+G+B > 381 return white else black.

It works pretty well if the contrast in the original is sufficient for legibility.

Regards
   Brian

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 20 Jan 2020 14:32:20 -0500

It is not just the greyscale that is the issue. There are numerous issues
in the diagrams that result from the chosen profile.

Compare the diagrams in:
https://tools.ietf.org/id/draft-hallambaker-mesh-architecture-12.html

With the originals in:
https://mathmesh.com/Documents/draft-hallambaker-mesh-architecture.html

Getting the diagrams to present properly is at least two weeks work for me
on top of the weeks already spent. And I am probably not going to be the
last person making this set of complaints. I am just the first person who
developed specs that depend on having good diagrams in them.

On Wed, Jan 15, 2020 at 10:21 PM Brian E Carpenter <
[email-masked]> wrote:

> invalid elements.
> The problem with colour/greyscale is that this isn't enough. If you have
> very dark blue text on a very pale pink background, what happens? svgcheck
> makes this black on black; my heuristic makes it black on white. What would
> your script do?
>
> But I do agree with Phill, this is a non-trivial issue. Currently I think
> doing new drawings with a simple tool like DIA is the only practical way.
>

It is my opinion that a standards organization should stick to existing
standards rather than inventing its own. Deviation from W3C standards
should only happen with an incredibly good reason. I do not see one.

Telling people to use one particular tool looks like bullying behavior to
me. Forcing people top jump through hoops to produce the old plaintext
format was bullying which was one of the reasons I was so opposed to it.

SVG is ubiquitously supported in current generation browsers. There are
tens, probably hundreds of thousands of person years worth of effort
invested in creating SVG content using today's tools. There is a published
spec that is widely distributed and at least as certain to survive whatever
apocalypses might occur as RFCs.

RFCs are merely tools for making the Internet change. We are not writing
holy scripture here. All RFCs that have the slightest importance are going
to have errors. The question is not how to eliminate the errors but to
minimize them.

Moving to HTML greatly reduces the number of errors in interpretation.

Nobody ever gives a specific issue. That is not how a standards
organization should behave. If there is a need to vary any standard, either
our own or someone else's there should be a clearly articulated reason
given.

Please state specific issues.

---

From: Leonard Rosenthol <[email-masked]>
Date: Mon, 20 Jan 2020 19:41:07 +0000

Phillip – “issues” with SVG are entirely contextual.    When used in the context of a full “Web Platform User Agent” (aka a browser showing a web page), then there aren’t any issues because (as you note) that is the environment it was designed for.  However, use of SVG in other environments (eg. SVG inside of OpenType fonts - https://docs.microsoft.com/en-us/typography/opentype/spec/svg) requires a subsetting.   As I mentioned in a previous message, you can see what the OpenType and SVG committees (and others) are doing so subset SVG for their needs at https://github.com/adobe/svg-native-viewer.

Leonard

From: rfc-interest <[email-masked]> on behalf of Phillip Hallam-Baker <[email-masked]>
Date: Monday, January 20, 2020 at 2:33 PM
To: Brian Carpenter <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [rfc-i] No, constraining to a custom SVG profile is not trivial

It is not just the greyscale that is the issue. There are numerous issues in the diagrams that result from the chosen profile.

Compare the diagrams in:
https://tools.ietf.org/id/draft-hallambaker-mesh-architecture-12.html<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fid%2Fdraft-hallambaker-mesh-architecture-12.html&data=02%7C01%7Clrosenth%40adobe.com%7C2f501838df364303804008d79ddf8e6b%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637151455836674875&sdata=RhykyuDd9T435cIKVPW7yG1PbcLPtdlZkTkCCfxya1Y%3D&reserved=0>

With the originals in:
https://mathmesh.com/Documents/draft-hallambaker-mesh-architecture.html<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmathmesh.com%2FDocuments%2Fdraft-hallambaker-mesh-architecture.html&data=02%7C01%7Clrosenth%40adobe.com%7C2f501838df364303804008d79ddf8e6b%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637151455836684868&sdata=yLpwP9rq1EOyeTrt2c3E8sd7LcC%2FMODhLRv%2FqzSzQpU%3D&reserved=0>

Getting the diagrams to present properly is at least two weeks work for me on top of the weeks already spent. And I am probably not going to be the last person making this set of complaints. I am just the first person who developed specs that depend on having good diagrams in them.

It is my opinion that a standards organization should stick to existing standards rather than inventing its own. Deviation from W3C standards should only happen with an incredibly good reason. I do not see one.

Telling people to use one particular tool looks like bullying behavior to me. Forcing people top jump through hoops to produce the old plaintext format was bullying which was one of the reasons I was so opposed to it.

SVG is ubiquitously supported in current generation browsers. There are tens, probably hundreds of thousands of person years worth of effort invested in creating SVG content using today's tools. There is a published spec that is widely distributed and at least as certain to survive whatever apocalypses might occur as RFCs.

RFCs are merely tools for making the Internet change. We are not writing holy scripture here. All RFCs that have the slightest importance are going to have errors. The question is not how to eliminate the errors but to minimize them.

Nobody ever gives a specific issue. That is not how a standards organization should behave. If there is a need to vary any standard, either our own or someone else's there should be a clearly articulated reason given.

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 21 Jan 2020 10:30:46 +1300

> It is not just the greyscale that is the issue. There are numerous issues in the diagrams that result from the chosen profile.

No colour or greyscale was a choice, not an issue. Because people wanted both printability and accessibility, the choice was made to get rid of colour-impaired sight problems and cheap printer problems.

The only other big problem I'm currently aware of is scalability. There are some interactions between browsers and elements like viewBox, width="724.0" and height="485.135549872".

I also discovered that any any <?xml ...> or <!DOCTYPE ...> declarations must be removed from the SVG file.

Hopefully the Temporary RFC Series Project Manager can coordinate some systematic approach to identifying SVG issues, both in tooling for the existing subset and possible updates to the subset. As Leonard Rosenthol hinted, unrestricted SVG is not really an option.

   Brian

> On Wed, Jan 15, 2020 at 10:21 PM Brian E Carpenter <[email-masked] <mailto:[email-masked]>> wrote:
>

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 20 Jan 2020 22:05:23 -0500

Since we will be embedding the SVG in a HTML page, I fail to see the
relevance of your point.

The font example is a reach. Since the fonts in question are intended for
use inside documents to define character glyphs it is pretty clear that
some very minimal set of terms will be required and so we are not so much
defining in SVG as designing a new version of metafont that uses the same
basic constructs.

I fail to see the reason I need to write code to flatten out markers and
perform the peculiar restrictions on tail text spans following tspan
elements.

On Mon, Jan 20, 2020 at 2:41 PM Leonard Rosenthol <[email-masked]>
wrote:

> Phillip – “issues” with SVG are entirely contextual.    When used in the
> context of a full “Web Platform User Agent” (aka a browser showing a web
> page), then there aren’t any issues because (as you note) that is the
> environment it was designed for.  However, use of SVG in other environments
> (eg. SVG inside of OpenType fonts -
> https://docs.microsoft.com/en-us/typography/opentype/spec/svg) requires a
> subsetting.   As I mentioned in a previous message, you can see what the
> OpenType and SVG committees (and others) are doing so subset SVG for their
> needs at https://github.com/adobe/svg-native-viewer.
>
>
>
> Leonard
>
>
>
> *From: *rfc-interest <[email-masked]> on behalf of
> Phillip Hallam-Baker <[email-masked]>
> *Date: *Monday, January 20, 2020 at 2:33 PM
> *To: *Brian Carpenter <[email-masked]>
> *Cc: *"[email-masked]" <[email-masked]>
> *Subject: *Re: [rfc-i] No, constraining to a custom SVG profile is not
> trivial
>
>
>
> <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fid%2Fdraft-hallambaker-mesh-architecture-12.html&data=02%7C01%7Clrosenth%40adobe.com%7C2f501838df364303804008d79ddf8e6b%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637151455836674875&sdata=RhykyuDd9T435cIKVPW7yG1PbcLPtdlZkTkCCfxya1Y%3D&reserved=0>
>
>
>
>
> With the originals in:
>
> <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmathmesh.com%2FDocuments%2Fdraft-hallambaker-mesh-architecture.html&data=02%7C01%7Clrosenth%40adobe.com%7C2f501838df364303804008d79ddf8e6b%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637151455836684868&sdata=yLpwP9rq1EOyeTrt2c3E8sd7LcC%2FMODhLRv%2FqzSzQpU%3D&reserved=0>
>
>
>

---

From: Doug Royer <[email-masked]>
Date: Mon, 20 Jan 2020 22:02:35 -0700

> Getting the diagrams to present properly is at least two weeks work for me on top of the weeks already spent. And I am probably not going to be the last person making this set of complaints. I am j…

I think I understand your point, however the example you provided is not really an SVG vs RFC-7996-SVG comparison. I also agree some of the RFC-7996-SVG limitations seem extreme.

The problem is the VISIO to RFC-7996-SVG conversion tool your using is selecting a wider font than the original. The conversion tool would need to get the em width, and match it up to a font with the same em width, or adjust the font size.

  (1) It looks like VISIO places some object to absolute positions.
  (2) VISIO seems to set some text objects relative to each other based on em ('M') width.
  (3) VISIO seems to set font size by the size of the 'M' (em) character, rather than absolute point sizes. And different fonts have a different em sizes.
  
The same is going to happen if the browser viewing mathmesh.com does not support the 'Calibri' font (unlikely, but the diagram will look messed up).

Have you tried using monospace or sans-serif in VISIO? They are also supported in RFC-7996. I am guessing you will have to tweak your VISIO file after the change.

Example, in the mathmesh.com SVG file (Calibri font):

   .st2 {fill:#000000;font-family:Calibri;font-size:1.00001em}
  ...
   <text x="11.64" y="430.18" class="st2" v:langID="1033"><v:paragraph v:horizAlign="1"/><v:tabList/>ProfileMaster<v:newlineChar/><tspan x="33.25" dy="1.2em" class="st3">Alice</tspan></text>
  
Yet in the IETF.org version is in a different font (sans-serif font):

<text x="11.64" y="430.18" fill="#000000" font-family="sans-serif" font-size="1.00001em">ProfileMaster<tspan x="33.25" y="444.580144" font-size="1em">Alice</tspan></text>

NOTE: When I update the SVG file from mathmesh.com and change the embedded CSS font from 'Calibri' (mathmesh.com) to 'sans-serif' (IETF.org), it looks as broken as the IETF.org version.

And - kind of related:

The mathmesh.com SVG file far from a standard SVG file. It contains non-SVG Microsoft extensions from the VISIO program.
(xmlns:v="http://schemas.microsoft.com/visio/2003/SVGExtensions/)

I do not think that a VISIO SVG-like file is reasonable as an example of what fails.

The VISIO team that added export to SVG to VISIO seems to have done so without regard to actually exporting standard SVG. It exports to SVG-like files.

(I am using your mathmesh.com SVG files to tweak my XSLT script to see what I can generate - I love being retired and have the time to just try things)

---

From: Martin J. Dürst <[email-masked]>
Date: Tue, 21 Jan 2020 05:48:59 +0000

On 21/01/2020 14:02, Doug Royer wrote:
>> It is not just the greyscale that is the issue. There are numerous 
>> issues in the diagrams that result from the chosen profile.
>>
>> Compare the diagrams in:
>> Getting the diagrams to present properly is at least two weeks work 
>> for me on top of the weeks already spent. And I am probably not going 
>> to be the last person making this set of complaints. I am just the 
>> first person who developed specs that depend on having good diagrams 
>> in them.
> 
> I think I understand your point, however the example you provided is not 
> really an SVG vs RFC-7996-SVG comparison. I also agree some of the 
> RFC-7996-SVG limitations seem extreme.
> 
> The problem is the VISIO to RFC-7996-SVG conversion tool your using is 
> selecting a wider font than the original. The conversion tool would need 
> to get the em width, and match it up to a font with the same em width, 
> or adjust the font size.

In SVG, there is actually a specific attribute for dealing with the 
variation in overall width of a text depending on the font. It is called
textLength. Please see 
https://www.w3.org/TR/SVG11/text.html#TextElementTextLengthAttribute. I 
do not know whether this attribute is allowed in the RFC subset of SVG, 
but it should be.

Regards,   Martin.

>   (3) VISIO seems to set font size by the size of the 'M' (em) 
> character, rather than absolute point sizes. And different fonts have a 
> different em sizes.
> 
> The same is going to happen if the browser viewing mathmesh.com does not 
> support the 'Calibri' font (unlikely, but the diagram will look messed up).
> 
> Have you tried using monospace or sans-serif in VISIO? They are also 
> supported in RFC-7996. I am guessing you will have to tweak your VISIO 
> file after the change.
> 
>    <text x="11.64" y="430.18" class="st2" v:langID="1033"><v:paragraph 
> v:horizAlign="1"/><v:tabList/>ProfileMaster<v:newlineChar/><tspan 
> x="33.25" dy="1.2em" class="st3">Alice</tspan></text>
> 
> <text x="11.64" y="430.18" fill="#000000" font-family="sans-serif" 
> font-size="1.00001em">ProfileMaster<tspan x="33.25" y="444.580144" 
> font-size="1em">Alice</tspan></text>
> 
> NOTE: When I update the SVG file from mathmesh.com and change the 
> embedded CSS font from 'Calibri' (mathmesh.com) to 'sans-serif' 
> (IETF.org), it looks as broken as the IETF.org version.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 21 Jan 2020 01:01:56 -0500

I have read all posts on the RFC-I list that include the string 'SVG'. I
find that almost no mention whatsoever was made of SVG-Tiny until it
appeared in the drafts. There is barely any mention of an SVG profile
before it is asserted that the decision to use a profile of SVG is
immutable in 2014. I therefore reject the suggestion that this was
sufficiently discussed at the time.

If people want to claim that something was discussed and decided, I am
going to be asking for a link to the post where that happened.

But the other point I will make is that 2014 is six years ago and the
statement made then was that these issues could be reopened at a later
date. I am simply holding the group to the promise made then that these
issues can be revisited.

The state of SVG may well have been very different in 2014. Today it is
ubiquitously supported and there doesn't seem to be much interest in the
SVG-Tiny subset. Stripping out colour is simple. Converting from SVG to
SVG-Tiny is not.

On Tue, Jan 21, 2020 at 12:02 AM Doug Royer <[email-masked]> wrote:

> > Getting the diagrams to present properly is at least two weeks work for
> me on top of the weeks already spent. And I am probably not going to be the
> selecting a wider font than the original. The conversion tool would need to
> get the em width, and match it up to a font with the same em width, or
> adjust the font size.
>

I can fix the font issue in the source files. But the much bigger problem
is the positioning of the text and the loss of the line markers.

>   (3) VISIO seems to set font size by the size of the 'M' (em) character,
> rather than absolute point sizes. And different fonts have a different em
> sizes.
>

My tool converts everything into pixel units so that it can cope with the
dx/dy positioning attributes that are supported in SVG but not SVG-Tiny.

The set of transformations performed is:

1) Parse embedded CSS and substitute into class attributes.
2) Expand all style elements to corresponding attributes
3) Convert all relative coordinates (dx, dy) to absolute
4) Wrap text trailing a <tspan> element within the same <text> element with
a <tspan>
5) Strip out all elements and attributes that are not permitted.

The current known omissions in the conversion include:

1) Marker elements are not converted.
2) I have no idea what the set of allowed UNICODE characters is. This is
not apparent from the documentation.
3) Possible further positional issues.

If I could be confident this is all there is, I might be willing to
complete the converter but I strongly suspect that there will be an
infinite number of issues and the only way to get an acceptable conversion
is to implement a full SVG render engine in the conversion tool.

I also note that multiple Web sites report every current Web Browser
(except IE if you consider it that) has full support for the full SVG spec.
I have been unable to find any evidence for use of SVG-Tiny in any product
at any time. The only tool supporting it native seems to be Adobe
Illustrator.

So rather than embarking on an error prone exercise, the simplest approach
is to simply substitute the SVG full profile for SVG-Tiny.

> support the 'Calibri' font (unlikely, but the diagram will look messed up).

I have over a hundred diagrams to edit. So I am only going to make one set
of changes after I have determined what the minimal set is.

And - kind of related:
>
> The mathmesh.com SVG file far from a standard SVG file. It contains
> non-SVG Microsoft extensions from the VISIO program.

The first version of the tool striped them out without any loss. They
appear to be there to allow the SVG files to be read back into Visio.

The display only changes when the font restrictions and attribute/element
stripping is implemented.

> The VISIO team that added export to SVG to VISIO seems to have done so
> without regard to actually exporting standard SVG. It exports to SVG-like
> files.
>
> (I am using your mathmesh.com SVG files to tweak my XSLT script to see
> what I can generate - I love being retired and have the time to just try
> things)
>

I rather doubt you will be able to do this type of transformation with XSLT:

(original)
  .st9 {font-family:Cambria Math;font-size:1em}
...
   <text x="17.17" y="282.11" class="st7" v:langID="1033"><v:paragraph
v:horizAlign="1"/><v:tabList/>Signature Key<v:newlineChar/><tspan
x="20.28" dy="1.225em" class="st6">Public</tspan>: X<tspan
class="st9">⊕</tspan>Y</text>

(cleaned)
      <text x="17.17" y="282.11" fill="#000000" font-family="sans-serif"
font-size="0.833336em">Signature Key<tspan x="20.28" y="294.3600392"
font-size="1em">Public</tspan>: X<tspan font-family="sans-serif"
font-size="1em">?</tspan> <tspan>Y </tspan> </text>

If you are going to enforce the restrictions properly, you have to expand
the class elements to the corresponding styles and then filter those.

You also need to catch the trailing </tspan>Y</text>, an error that is
reported by the submission tool but does not correspond to a requirement I
could see. Converting  dy="1.225em" to y="294.3600392" required an insane
amount of code. SVG has eight different units of length.
_______________________________________________
rfc-interest mailing list
[email-masked]
https://www.rfc-editor.org/mailman/listinfo/rfc-interest

---

From: Julian Reschke <[email-masked]>
Date: Tue, 21 Jan 2020 07:04:18 +0100

> The only other big problem I'm currently aware of is scalability. There are some interactions between browsers and elements like viewBox, width="724.0" and height="485.135549872".

I implemented experimental down-conversion of SVG in
<https://github.com/reschke/xml2rfc/blob/master/prep-xml2rfc.xslt> and
found that the lack of markers prevents the use of even trivial GraphViz
output.

> I also discovered that any any <?xml ...> or <!DOCTYPE ...> declarations must be removed from the SVG file.

That I would call a bug. It's not backed by anything in the specs.

> Hopefully the Temporary RFC Series Project Manager can coordinate some systematic approach to identifying SVG issues, both in tooling for the existing subset and possible updates to the subset. As…

While I agree with that, there are *much* more pressing issues to
address (such as the fact that we publish "canonical" XML which does not
conform to any agreed-upon vocabulary definition).

Best regards, Julian

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 21 Jan 2020 01:14:41 -0500

On Tue, Jan 21, 2020 at 1:04 AM Julian Reschke <[email-masked]>
wrote:

> > No colour or greyscale was a choice, not an issue. Because people wanted
> both printability and accessibility, the choice was made to get rid of
> colour-impaired sight problems and cheap printer problems.
> >
> > The only other big problem I'm currently aware of is scalability. There
> are some interactions between browsers and elements like viewBox,
> width="724.0" and height="485.135549872".
>

It was the lack of markers set me off. It is clear that pretty much every
drawing program is going to use them because they are implementing
primitives that are there in every vector drawing API for the past 30
years.

I can work round the font issues provided that I get a list of the allowed
character sets (I have looked in the documentation and not found such) nor
did the other links provide the necessary info.

While we are not doing MathML at this point, I am pretty sure that math
characters are going to be more useful than the chess pieces in the current
set. But right now, I can't use any non ascii characters because I don't
know what the filter set should be.
_______________________________________________
rfc-interest mailing list
[email-masked]
https://www.rfc-editor.org/mailman/listinfo/rfc-interest

---

From: Michael Richardson <[email-masked]>
Date: Tue, 21 Jan 2020 12:03:52 -0500

Phillip Hallam-Baker <[email-masked]> wrote:
    > date. I am simply holding the group to the promise made then that
    > these issues can be revisited.

I would support revisiting the question of a SVG profile... in 2021.
Certainly by IETF110, with planning for that discussion at IETF109.
So... after we have a new permanent RFC-editor.

I think that the change to v3-XML under changing leadership is difficult
enough as it is.

In the meantime, in the I-D series, I think that we should tolerate a variety
of SVG inputs, and we should encourage monochrome inputs, but not require
them.

I tried SVG for some diagrams in a document a year or so ago, and the lack of
any way to shade or colour boxes immediately became a major PITA, with the
result that I went back to ASCII art (with the excellent asciio), as the SVG
didn't do enough for me that I was willing to abandon the ability to
communicate easily in text.
(I'm a regular DIA, and Inkscape user. Although, I still prefer xfig...)

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-