[rfc-i] graphics support

Iljitsch van Beijnum iljitsch at muada.com
Fri Apr 20 17:10:44 PDT 2012


On 20 Apr 2012, at 19:27 , 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.

> The fundamental drive to apply Ocam's razor still applies

I have no idea what you are getting at in this message. Maybe a picture will make things clearer...


On 21 Apr 2012, at 0:18 , Paul E. Jones wrote:

> I can appreciate not wanting to use a bleeding edge, complex, proprietary
> format.  However, anything that is built on an open standard will not
> present issues w.r.t. longevity.

There is a difference between being able to decode something by carefully executing several dozen steps so ancient no longer supported software will do its thing in a modern environment, and everyday usability. We need the latter.

> We can convert txt to HTML.  We can
> convert HTML to whatever we want.  We can convert ePub to that next great
> thing.

But how do you know for sure nothing meaningful is lost in the conversion?

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

> Is this an issue with SVG or Safari?  If SVG, I'd be concerned.  If Safari,
> I'm sure this will get addressed.

Jump off the cliff and grow your wings on the way down...

> In fact, I'm pretty darn sure if the IETF
> selected MathML and SVG, all browsers would suddenly have great support for
> those.

Yeah right.

And browsers are terrible pieces of hugely complex software that change every day. We really don't want to make ourselves depend on those if we can avoid it.

Also, now we're going to require people who want to write an RFC to learn how to write mathml and svg? Remember, "first. do no harm".


More information about the rfc-interest mailing list