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

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.

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

-- 
Doug Royer - (http://DougRoyer.US)
Douglas.Royer@gmail.com
714-989-6135
_______________________________________________
rfc-interest mailing list
rfc-interest@rfc-editor.org
https://www.rfc-editor.org/mailman/listinfo/rfc-interest