> I'd propose the following.
>
> 1) (Moves are already being made in this direction.) Get code out there for
> all existing browsers to gain JPEG support ASAP.
Fine. Needs doing anyway.
> 2) Draft a spec, similar in concept to GIF, but using an alternative
> non-lossy compression mechanism
Ah, the invent-another-format position. Why? What is wrong with all the
hundreds of existing formats?
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).
> 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
> which specifies an 8-bit grayscale mask
Hooray! Yes! Proper antialiased text in transparent graphics without having
to guess a likely background colour!
Again there are two sub-options:
3a) Have an external mask file for all image types
3b) Have the mask information inside the image file
> for handling anti-aliasing (aka "transparency")
Well, transparency and antialiasing are separate though related issues.
You can have an antialiased figure that has no transparency; you can have
a figure with transparency that is not antialiased. At present though,
producing a figuire that is both antialiased and transparent involves
making the assumption that the background is not too far from a mid grey.
> Its argument is any
> format supported by "src".
Well OK but then we need registration hints. What if the mask and the
image are different sizes?
> That will more than make up for the loss of the
> transparency option in GIFs.
> The only disadvantage I can think of for not
> providing this in the image format is that you can't provide a mask with an
> non-in-line image, but I think the benefits of doing this without creating
> a new image format outweigh that minor issue.
Again, a new format need not be defined. There are loads of valid arguments
that could be put forward on the merits of 3A or 3B, but the labour of
creating a new format is a spurious one. Just use an existing format that has
an alpha channel. TIFF 6 springs to mind as the obvious candidate: AVS X image
files, Photoshop files etc are other, less suitable examples. TIFF does of
course have a freely available library which can be linked to, so inline
TIFF should be fairly easy to add.
> None of this is rocket science. If those three things can be pushed forward
> with a minimum of fuss, and no time wasted fighting with Compuserve and/or
> Unisys
I agree that this would be unproductive.
-- Chris Lilley +-------------------------------------------------------------------------+ | Technical Author, Manchester and North HPC Training & Education Centre | +-------------------------------------------------------------------------+ | Computer Graphics Unit, | Email: Chris.Lilley@mcc.ac.uk | | Manchester Computing Centre, | Voice: +44 61 275 6045 | | Oxford Road, | Fax: +44 61 275 6040 | | Manchester, UK. M13 9PL | X400: /I=c /S=lilley | | /O=manchester-computing-centre /PRMD=UK.AC /ADMD= /C=GB/| |<A HREF="http://info.mcc.ac.uk/CGU/staff/lilley/lilley.html">my page</A> | +-------------------------------------------------------------------------+ |This is supposed to be data transfer, not artificial intelligence. M VanH| +-------------------------------------------------------------------------+