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

Brian E Carpenter brian.e.carpenter at gmail.com
Fri Jan 24 13:49:44 PST 2020


<snip>

>>     gnuplot, for example, supports setting monochrome linetypes when plotting multiple variables on a single graph. LibreOffice Draw supports cross-hatching. Unfortunately the SVG that it generates includes a construct (<path style="fill:url(#pattern1)"  .../>) that we apparently don't allow, even though it's an internal reference:
> 
> 
> I don't currently support that transformation, what my tool would produce instead is:
> 
> <path fill="url(#pattern1)"  .../>
That is also rejected by unpatched svgcheck. Not that this matters when a common drawing tool like LibreOffice generates the other form. That's really the problem here: using a widely available tool and sticking to the IETF intention (such as cross-hatching instead of colour) doesn't guarantee conformance. That is unsaleable even to the specialised market of RFC authors.

Regards
   Brian

On 23-Jan-20 17:24, Phillip Hallam-Baker wrote:
> (For some reason the last posts only just showed up or would have answered them all in one.)
> 
> On Wed, Jan 22, 2020 at 9:29 PM Brian E Carpenter <brian.e.carpenter at gmail.com <mailto:brian.e.carpenter at gmail.com>> wrote:
> 
>     On 23-Jan-20 11:29, Donald Eastlake wrote:
>     > There does exist a system form mapping some colors into cross
>     > hatchings. See hatchings at
>     > https://en.wikipedia.org/wiki/Tincture_(heraldry).
> 
>     However, I think that realistically we can't expect IETF tooling to perform that complex a remapping (colour to cross-hatching). It really would need to be done with the initial drawing tool.
> 
> 
> Not necessarily.
> 
> It would certainly be horrible if you are trying to use perl scripting or SLT. But I have what amounts to the SVG DOM. So it is actually not that difficult to implement that type of processing or the processing or some of the features suggested earlier. 
> 
> The main part of the tool is only 700 lines of code:
> 
> https://github.com/hallambaker/PHB-Build-Tools/blob/master/DocTools/Goedel.Document.RFCSVG/Program.cs
> 
> The method Attribute at line 268 is currently substituting x/y attributes for dx/dy which requires the font size etc to be tracked.
> 
> The same approach could easily be used to vet color values for contrast. My original diagrams use color but in a very limited fashion. Most have two colours plus black and white.
> 
>  
> 
>     gnuplot, for example, supports setting monochrome linetypes when plotting multiple variables on a single graph. LibreOffice Draw supports cross-hatching. Unfortunately the SVG that it generates includes a construct (<path style="fill:url(#pattern1)"  .../>) that we apparently don't allow, even though it's an internal reference:
> 
> 
> I don't currently support that transformation, what my tool would produce instead is:
> 
> <path fill="url(#pattern1)"  .../>
> 
> I can easily write an FSM to resolve this, the reason I didn't is that the features that use url() aren't in SVG-Tiny.
> 
> Anyone wanting to use SVG diagrams in an RFC is going to need a tool that can do the deep parse if they are going to use more than one diagram because they will both have an id="pattern1" element.



More information about the rfc-interest mailing list