[5395] in www-talk@info.cern.ch
Re: Mailcap extensions (was Re: Client Compliance)
daemon@ATHENA.MIT.EDU (wmperry@spry.com)
Sun Aug 28 17:22:18 1994
Date: Sun, 28 Aug 1994 23:15:39 +0200
Errors-To: listmaster@www0.cern.ch
Errors-To: listmaster@www0.cern.ch
Reply-To: wmperry@spry.com
From: wmperry@spry.com
To: Multiple recipients of list <www-talk@www0.cern.ch>
Marc VanHeyningen writes:
> Bill Perry sed:
> > Browsers should only send the '*/*' header when in 'load-to-disk' mode
> >(or their equivalent). Another win would be if the clients would send
> >a different set of headers for inlined images... not much use sending
> >text/plain when you can only inline image/gif, image/jpeg, or
> >image/x-bitmap.
>
> It's never been very clear to me what a server should do if it cannot
> present an item in a format the client will accept. Return an error?
> Which one?
The Windows-NT server from EMWAC tries to do this, but has a few problems
when it sees multiple Accept: headers instead of having one huge one. I
believe it just returns one of the more generic error codes (401 or
something like that).
> > I'm getting ready to add the 'quality' (q=xxx) flag to my emacs-w3
> >browser. Is there a standard way to show this in a mailcap entry (I didn't
> >see one off the bat, but perhaps we could all standardize on an x-yyy
> >flag). Perhaps an x-quality so that a mailcap would look like this:
> >
> >image/gif; xv -perfect %s; needs-x11; x-quality=0.8
> >image/jpeg; xv -perfect %s; needs-x11; x-quality=1.0
> >image/x-bitmap; bitmap %s; needs-x11; x-quality=0.2
>
> This seems reasonable; I was exploring adding this to the mailcap spec
> a while back. Nathan was interested, but I sort of let it die because
> I wanted to do something more general with file typing and I didn't
> detect much interest (I mean, how many clients even bother to parse
> mailcap files as currently defined, let alone new features?)
I think the mailcap parser you wrote in tcl and the one I write in elisp
for my browser are about the only ones. Did your mailcap parser ever make
it into tkWWW?
> Not to flame you, Bill, but your use of the quality settings above
> looks exactly backward to me. The purpose of quality is to specify
> how losslessly the client's viewer can present that content-type.
> Presuambly you can display a bitmap losslessly, so you might specify a
> quality setting of 1.0. A GIF might be slightly lossy, say about
> 0.95. A JPEG might be lossier still, since there are more colors to
> quant down to a 256 colormap, so it might have a setting of 0.9 or
> 0.8. Now, naturally there is also lossiness on the server end (there
> would be a lot of loss convering a JPEG to a bitmap) which the server
> is supposed to calculate and multiply by the client lossiness.
Ahah - just misunderstood what the quality related to. I'll just send
whatever is shown in the mailcap - it'll be a while before I get to the
point of automatically modifying the mailcap file through a form, etc. :)
> What I would use low quality settings for are things like the
> following:
>
> image/gif; giftoppm | pnmscale -width 80 | ppmtopgm | pgmtopbm | pbmtoascii;\
> copiousoutput
>
> Now, *that's* lossy. But it does provide a very crude idea of what an
> image looks like even on a VT100.
Hey! I actually used that once when I did inlined 'images' in text mode
for the emacs-w3 browser. God was it ugly though. :)
-Bill P.
