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

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 <douglasroyer@gmail.com> wrote:

> On 1/20/20 12:32 PM, Phillip Hallam-Baker 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:
> > 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.
>
> 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.
>

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.

  (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.
>

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.

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).
>

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.
> (xmlns:v="http://schemas.microsoft.com/visio/2003/SVGExtensions/)
>

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.

> 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)
>

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.