[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: lynx-dev Overriding mime types

From: Al Gilman
Subject: Re: lynx-dev Overriding mime types
Date: Sat, 23 Mar 2002 12:56:43 -0500

Can one automate the "lose the type indication by passing through the file 
system" hack by binding this image type to a viewer which is [a script which 
calls] Lynx which then keys off the file-extension casting?

I don't think that casting SVG to HTML is a good idea, however.  Until Lynx has 
an XML/plain presentation mode such as the tree view in IE, you probably want 
to cast image/svg+xml to a viewer which applies a text transform to get HTML 
and then pipe it to Lynx.  In other words, an XSLT partner of the SVG 
techniques, or a functional equivalent thereof written in Perl or whatever you 
think is broadly available on the same platforms with Lynx.

Danny, yes the precedent and a pattern that many think should be preserved is 
that the type indication, like the BASE, is subject to a rule that the most 
local indication takes precedence.  And the type indication in the HTTP 
Content-Type: header is more 'local' than the type indication in the referring 
document.  See Martin Duerst's comment (20) to the SRGS grammar specification.

[But then they don't want the typespace to change inside "a document."]

On the other hand, forcing the processing to a valid supertype of the indicated 
type, as in forcing text/html to text/plain, and forcing any xml dialect to 
some generic xml processing, should be legal and a 'try harder' approach that 
assistive applications may employ.  This is where we need to understand the 
valid limits on transformation vs. the artifacts of the author's personal 
predilections about expendable property bindings.


At 03:29 PM 2002-03-22 , you wrote:
>On Fri, Mar 22, 2002 at 08:22:22PM +0100, Danny Ayers wrote:
>> Will this actually be presented as image/svg+xml coming from file? I can't
>> see any mention in the trace (though I'm not familiar with these traces).
>> I don't suppose you could try
>> ?
>hmm - this is a different problem - the server sets the Content-Type, which
>makes it an image:
>HTMIME: PICKED UP Content-Type: 'image/svg+xml; qs=0.85'
>HTMIME: Extended MIME Content-Type is image/svg+xml;qs=0.85
>LYmktime: Parsing 'Sat, 23 Mar 2002 02:23:37 GMT'
>LYmktime: clock=1016850217, ctime=Fri Mar 22 21:23:37 2002
>LYmktime: Parsing 'Fri, 22 Mar 2002 20:23:37 GMT'
>LYmktime: clock=1016828617, ctime=Fri Mar 22 15:23:37 2002
>HTMIME: MIME Content-Type is 'image/svg+xml', converting to 'www/present'
>HTFormat: Constructing stream stack for image/svg+xml to www/present
>HTFormat: Looking up presentation for image/svg+xml to www/present
>HTFormat: comparing image/* and image/svg+xml for half match
>StreamStack: found strong subtype wildcard match: image/*
>StreamStack: found weak wildcard match: www/present
>StreamStack: Using www/present
>short answer: I don't know if there's a way to override that (that is, to
>force that MIME type to be rendered as html).
>Thomas E. Dickey <address@hidden>

>; To UNSUBSCRIBE: Send "unsubscribe lynx-dev" to address@hidden

; To UNSUBSCRIBE: Send "unsubscribe lynx-dev" to address@hidden

reply via email to

[Prev in Thread] Current Thread [Next in Thread]