[rfc-i] graphics support
Iljitsch van Beijnum
iljitsch at muada.com
Fri Apr 20 09:17:54 PDT 2012
[This is a reply to a bunch of messages]
On 18 Apr 2012, at 1:53 , Ole Jacobsen wrote:
> I think it would be nice if we could produce more "professional" and
> "modern" looking RFCs that look more like our competition, that is,
> ITU and ISO documents.
I agree with this. Keyword being "nice", though. We have other more important considerations that take precedence. The current tools already create nicer versions than the "real" version, and I don't see how this could be improved, especially if we get to change some things that get in the way of creating nice alternative versions.
> I don't understand why we need to be stuck in a 1960's lineprinter world,
We don't have to be stuck in a 1960's lineprinter world, but I think we do have to relatively old and simple document formats because those have a much better chance to give us the longevity we need coupled with the needs to process and edit RFCs with a variety of tools, most of them homegrown and therefore relatively simple, and we also want to impose little or no requirements on the display devices. The fact that it's possible to read RFCs over an ssh connection is something that I think is valuable, as is the fact that RFCs are so small that you can cary the entire series on a USB drive.
> nor do I accept the notion that it is
> always better to explain things with words and not with pictures.
Words are notoriously imprecise, and in some cases pictures are much more precise. For instance, a header diagram allows for less confusion than a text description. But pictures also have the ability to be completely unfathomable in ways that we know we can avoid in text. So I'm really hesitant to allow pictures in general as a normative part of RFCs. However, we could easily recognize a number of classes of diagrams (headers, states) as being useful and allowed as normative.
Still, having a normative part of an RFC unavailable to those who can't view images (for temporary technology availability reasons or otherwise) would be an important downside.
> this doesn't sound like an unreasonable "requirement" or at
> least "desirable feature" to me.
It's already possible to have PDF/PS versions of an RFC with additional non-normative images. I understand this isn't done all that much, though.
> I would also like to have some way of producing a reference paper
> (virtual or real) version where you could say "see diagram 15 on the
> top of page 47".
I don't think the convenience of being able to point to a page number that is stable across all representations of an RFC is worth the hassle of displaying them on a screen or paper with different dimensions. IMO, pagination has to go, although there is of course nothing wrong with printing an RFC and then including a TOC that points to page numbers. Just don't expect these page numbers to be relevant to other views of the same RFC. This is where section, table and image numbers are for.
> Once (or if) we agree on what elements we would like to have in future
> RFCs we can then have the discussion of how to encode it, edit it and
> so on. We seem to be having those discussions already without having
> agreed on any requirements, wishlists etc.
On 18 Apr 2012, at 4:03 , Peter Saint-Andre wrote:
> To expand upon that statement, I must admit to being concerned about
> people wanting to include the kinds of fancy graphics one often finds in
> whitepapers and presentations. Perhaps the answer to that concern is
> "exercise some self-control"...
Not always a foolproof solution.
On 18 Apr 2012, at 8:58 , Stewart Bryant wrote:
> We tend to allow those that think in words unlimited scope and
> complexity to express their thoughts, but constrain those that
> think in pictures or maths only the most primitive forms of
Authors shouldn't whine about this kind of stuff, it's their job to make things easy for the reader, not to make things easier for themselves.
> The text equivalent of ascii art would be to limit the dictionary
> to that of 10 year old and the sentence size to something like
> 120 chars.
Sounds like a service I know that is pretty popular. :-)
RFCs are not a means of free artistic expression. They are protocol specifications. If specifying a protocol requires detailed pictures, then we should look for ways to make that possible. But from where I'm sitting, the current system where it's possible to use "real" pictures but only as non-normative parts of an RFC, seems to work pretty well.
On 18 Apr 2012, at 9:00 , Stewart Bryant wrote:
> We have a review process that roots out unnecessary complexity in
> text, why would it not root out unnecessary complexity in the figs?
Pictures are different from text. The skill sets are quite different.
On 20 Apr 2012, at 2:07 , Paul E. Jones wrote:
> Why the desire to move from old ASCII text files to something better, but
> still cling to drawing diagrams using ASCII art?
> The IETF should make an effort to produce better-looking documents and I say
> graphics are a key element of that.
A first step could be to come up with a good font for ASCII art. Back in the day you could do pretty nice things with ASCII and special graphics characters on character based displays. But our current fonts really don't support this anymore.
> For inclusion of graphics, we could require something that we can convert,
> like SVG.
SVGs don't display in a good way on Safari on the Mac. The format isn't widely supported as far as I can tell, I don't think it's a useful way forward.
On 20 Apr 2012, at 2:15 , Phillip Hallam-Baker wrote:
> I think you get the resistance back to front, the folk who don't want
> to give up ASCII art probably have no desire to move from ASCII text
> It is a form of hazing to keep out people who might challenge the old
> guard. It is sick, pathetic and stupid but that is what it is about.
I strongly disagree.
More information about the rfc-interest