[rfc-i] Guidelines for illustrations

"Martin J. Dürst" duerst at it.aoyama.ac.jp
Mon Apr 23 20:38:49 PDT 2012

On 2012/04/24 7:39, Larry Masinter wrote:
> I think some simple guidelines for illustrations would go a long way. Maybe not "rules", but "guidelines". But engineers often get carried away since most people who author Internet Drafts are not professional designers and don't think about simple things like accessibility and whether the diagram will print out.
> For text, the RFC editor can actually fix grammar errors and missing references and periods in the wrong place.
> For graphics, the RFC editor can only fix things for which the RFC editor has tools which can edit the graphics that are delivered to the RFC editor.
> That won't be true for graphics delivered as images -- not editable. And while Adobe illustrator can be used to edit SVG, the kinds of edits needed are probably not really supported.
> Some guidelines:
> Keep the diagram or illustration to something that could reasonably be done in ASCII art. That's not because we like ASCII art, but just as a matter of insuring maximum interoperability. For example, diagrams and illustrations could be kept to simple lines, arcs, text which doesn't depend on the font -- even if the font is embedded.
> Diagrams should avoid unnecessary use of color -- to  make sure the illustration or diagram can be printed on a black and white printer, that it doesn't require calibration of color of devices.

All very good points, except a detail in this one. There is nothing bad 
in using color in diagrams. What's important is not that the 
illustration can be printed exactly as is on a black-and-white printer, 
but that it can be printed without loss of message. See 
http://www.w3.org/TR/WCAG/#visual-audio-contrast for background.

As an examle, it's perfectly okay to have all the foos in a diagram red, 
and all the bars in a diagram green, if at the same time all the foos 
are rectangles and all the bars are circles, or some such.

Regards,   Martin.

> I don't know how much of this the RFC editor wants to get into, though.
> If it is a requirement that someone can take an old RFC and start editing it to produce a new one, then having the archival form of the illustrations be in an editable vector graphic format seems a minimum, but that's problematic, if only because the field is still developing.
> http://www.yworks.com/en/products_yed_about.html
> http://www.gliffy.com/
> http://code.google.com/p/diagram-editor-for-google-plus/
> _______________________________________________
> rfc-interest mailing list
> rfc-interest at rfc-editor.org
> https://www.rfc-editor.org/mailman/listinfo/rfc-interest

More information about the rfc-interest mailing list