There is an advantage to doing something incremental off of the existing
format - it speeds the acceptance. In fact, a proposal (and implementation)
have already been made for an LZHUF version of GIF, but it doesn't always
compress quite as well. But (as someone else pointed out) TIFF might be
the way to go for an alternate. The only concern I have there is to make
sure that the overhead for small images isn't too high.
>While we are at it, there are actually two sub-options here:
>
>2a) Use an existing format that uses non-LZW compression
>2b) Use an existing format, and use the MIME content-encoding header to
>specify a suitable compression scheme. I notice that Arena already supports
>inline XPM (which is in dire need of compression, I admit).
2b doesn't really solve the problem for other uses of the format though. I
think any solution has to take into account the millions of other files in
GIF format.
>> 3) Add a "mask" attribute to <img>
>
>Is adding to HTML 2.0 wise? Supposed to be about frozen - adding to HTML 3.=
0
>seems a better idea. So, add attributes to FIG and IMG
=46ine.
>3a) Have an external mask file for all image types
>3b) Have the mask information inside the image file
I'd prefer 3b, since it's easier to manage, but practically, I think we
have to do 3a, since modifying JPEG to add a mask doesn't seem terribly
practical. (Although, masking a lossy compression file may not be very
practical either).
>Well OK but then we need registration hints. What if the mask and the
>image are different sizes?
Ugh. I suppose an xoffset and yoffset setting would work, but I'd rather
just disallow it.
(BTW, I've seen no activity on this mailing list in weeks, has it lulled,
or did I get dropped somehow?)
Kee Hinckley Utopia Inc. - Cyberspace Architects=81 617/721-4671
nazgul@utopia.com http://www.utopia.com/
I'm not sure which upsets me more: that people are so unwilling to accept
responsibility for their own actions, or that they are so eager to regulate
everyone else's.