Re: images

Leonard Rosenthol wrote:
> 
> At 9:15 PM +0200 8/4/00, Chris Lilley wrote:
> >The MIME type is missing, as has been noted, from your example. Adding the
> >PNG mimetype does not affect display of the image; then again, adding any
> >string in there doesn;t seem to affect the displayof the image.
> 
>         OK, so the Adobe viewer is smart enough to do auto-detection
> of the image type based on the "magic bytes".

Well, whether that is smart or not sort of depends.

Looking at the specification for the data url scheme, ut clearly says that
the MIME type is optional, as is the encoding. 

But omitting the encoding means ascii, with non-ascii characters
represented by %xx URL escapes of the *byte values*, and they don't say
what character encoding is being used (same old problem, people are setting
on utf-8 for URIs to solve that) so who knows what the byte values are? So,
I woulds be happy, personally, so see the base64 declaration be required
for all SVG use of data url on images.

Omitting the MIME type also has a defined meaning - the resource has the
MIME type text/plain;charset="us=ascii".

So the issue is exactly the same as the following one

<image width="20" height="30" xlink:htef="http://example.net/foo.xyz">

when the server returnes a MIME type of text/plain, what do you do? Some
HTML broewsers use a range of undocumented hueristics to fix things up,
which propogates the brokenness Some html browsers follow the spec and
offer to save to disk (application/octed -stream) or open a text editor
(text/plain).

>  Is it expected that
> all SVG conforming viewers do the same, or should they instead punt
> on invalid mime-types?  What are you thoughts on what to put into the
> spec on this subject?

Whatever there is needs to be consistent. Generally, with URLs there is
resistance to putting the MIME type there - the server might do content
negotiation, the resource might change over time, there might be a
transcoding proxy in between you and the server, and so forth. These
reasons do not apply to the data scheme - the encoding application always
knows what the format is and can always write the MIME type and the data
will never change.

So, my preference would be to follow the spec, require the MIME type in all
cases (since text/plain is not an image type and thus never appropriate,
for SVG) and require implementatiosn to issue an error if the MIME type is
text/plain (by implication of omiossion, or through being physically
present), immage/silly, foo.bar, or anything else that is not supported.

--
Chris

Received on Friday, 4 August 2000 16:14:41 UTC