[rfc-i] graphics support
Paul E. Jones
paulej at packetizer.com
Fri Apr 20 19:01:54 PDT 2012
> > 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
First, do not wait until a file format is so ancient that support is a
challenge. Second, do not use formats that are proprietary and present
I have documents on my machine I produced in WordPerfect in the 80s. I can
still open them, because I converted them before as I transitioned away from
WordPerfect. I have even older ones, but the format used was not so widely
known and I lost the formatting.
Still, I had fairly good success with even that proprietary format. Use an
open format and keep texts in a current open format and you should be fine.
> > 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?
Because the conversion should be accurate. The older format can be retained
for reference. If there is discrepancy, fix the conversion issue and convert
again. This would be possible with open document formats. As a last
resort, type/draw it again ;-)
There is always an opportunity for conversion issues, but I see no reason
for this to be a reason to stay fixed in time.
> >> 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...
Seriously? If Safari is the only browser with broken SVG support, this WILL
get fixed. If not, then use something other than Apple. I'm pretty sure it
would get fixed.
I'm not sweating over here that Windows' Notepad does not deal with LF in
files and wants CRLF. I use a different tool.
> > 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.
You doubt that? Watch and see. It would be in their best interest. To help
ensure that, put a complex equation and detailed diagram into the next HTTP
> 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.
Well, this is a whole other can of worms. Browsers were designed for viewing
documents and they should excel at that. It is the most fundamental
and the idea that we can turn the web browser into an application platform.
This is where the breakages happen all the time.
If there is an issue rendering *basic* HTML+CSS, then that needs attention.
> 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".
Heck no, I will not require people to write that manually. I don't want to
get a headache, either. Either we will use an editor (Word or dedicated
HTML editor) that will produce the required output, or we merge images and
text in as part of a post-processing step. (I already have a
post-processing step since I use Word to write I-Ds. So, nothing worse than
In any case, where does all of this stand? I saw the requirements list. I
think HTML came close to meeting almost everything, if not everything. HTML
is pretty much the only way I read RFCs or I-Ds today, anyway. I'd say we
go in that direction. We would not have to support images and equations on
day 1; we always have the old ASCII approach, even with HTML.
More information about the rfc-interest