Re: Postscript Behavior...

Tim Berners-Lee <timbl@www3.cern.ch>
Date: Wed, 28 Apr 93 13:11:25 +0100
From: Tim Berners-Lee <timbl@www3.cern.ch>
Message-id: <9304281211.AA06297@www3.cern.ch>
To: marca@ncsa.uiuc.edu (Marc Andreessen)
Subject: Re: Postscript Behavior...
Cc: Mowgli C Assor <mowgli@magnus.acs.ohio-state.edu>, www-talk@nxoc01.cern.ch
Reply-To: timbl@nxoc01.cern.ch


>Date: Tue, 27 Apr 93 17:45:19 -0500
>From: marca@ncsa.uiuc.edu (Marc Andreessen)

>Mowgli C Assor writes:
>>   Um, I've been playing with various ways of getting postscript to  
display
>> via XMosaic (1.0). [...]
>>   However, when HTTP processes the file, it puts the line :
>> 

>> <PLAINTEXT>
>> 

>> in front of the rest of the document. Thus, when it gets back to  
Ghostview,
>> it chokes because <PLAINTEXT> is invalid PS. This may again get us  
to the
>> point of needing "type tags" for different types of files, but  
with the
>> coming various "multi-media" browsers, it seems to me to be a  
problem we
>> need to solve somehow (perhaps the URLs will help, but I don't  
think they
>> are the ultimate solution).
>> 

>>   I can just set up a filter for Ghostscript which removes the  
offending
>> line, but is there a better solution?

The problem here is twofold.  Firstly, the old HTTP version
only knows about two formats, plain text and HTML.  It distinguishes  
text from HTML by prefixing it with <PLAINTEXT>.  Now it is possible  
of course to get a postscript file returned as "plain text" and then
treat it as postscript.  Secondly, though, there is a bug in XMosaic
which causes it not to look at the <PLAINTEXT> let alone strip it  
off.  This is because (contrary to the protocol) it guesses from the
URL (which is specified as being opaque and meaningless to hte  
client) what sort of a format it is and pipes it directly to
ghostview.  I guess it doesn't strip off the PLAINTEXT because it
just wants to open up a pipe.

I have put a -DXMOSAIC-HACK patch into the W3 library to allow the
library to return data to clients which have not said they can handle  
it. before that they would just say "sorry" if you wanted a picture  
and could only handle plain text. I hadn't realised there was this  
extra problem with the <PLAINTEXT> with mosaic.  The trouble is, if  
the <PLAINTEXT> is left out, everything returned will be parsed
(by conforming HTTP0 clients) as HTML.

>The long-term solution is to move to HTTP2.  One short-term solution
>that you may want to explore is the NCSA public domain httpd, on
>ftp.ncsa.uiuc.edu in /Mosaic/ncsa_httpd, which will never do this to
>data files.

Beware of course that if you put up data using this server, there are  
lots of people out there with the line mode browers who, instead of  
getting the postscript in a usable form which they can print, will  
get it parsed as HTML!

Moving to full HTTP is better.  The line mode browser and various  
others include the version 2 cern library which includes the full  
HTTP (or at least, this part of it).  I hope it isn't too much in the  
long term for xmosaic.  All multimedia browers should use the full  
HTTP. Otherwise servers can only assume that they can only handle  
ASCII and HTML.

BTW Marc I have put in the porting mods from xmosaic's tcp.h
into tcp.h in the new library ...

This is all my fault for not getting libwww v2 out earlier in the  
xmosaic development schedule.

>Cheers,
>Marc

Tim BL