JPEG issues
Bijan Parsia
bparsia at email.unc.edu
Thu Dec 20 02:05:55 UTC 2001
On Wed, 19 Dec 2001, Michael Rueger wrote:
> Bijan Parsia wrote:
>
> > If it's any clue, the start of the retrieved collection is:
> >
> > a ByteArray(60 33 68 79 67 84 89 80 69 32 72 84 77 76 32 80 85 66 76 73 67
[snip]
> Which translates nicely to
>
> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
[snip]
D'oh!
Can I kill myself now?
Hmm. I seem to be misled, at least partially, by the fact that if I save
the graphic to disk from a web browser, it still doesn't want to open up
in Squeak. Thus, it *may* (since my tract record the past couple of days
is, well, *lousy*, I wish to be cautious) be both an HTTP and a JEPG
issue.
Hmm. Yes. It is both.
As Duane Maxwell, it's a progressive JEPG and raw Squeak can't handle it.
But the other problem is that the server is unwilling to return the JEPG
if we say we only accept 'application/octet-stream' mimetypes. The
following change will fix HTTPSocket class>>httpJPEG
httpJpeg: url
"Fetch the given URL, parse it using the JPEG reader, and return
the resulting Form."
| doc ggg |
doc _ self httpGet: url accept: 'image/jpeg'. "The change."
doc binary; reset.
(ggg _ Smalltalk jpegReaderClass new) setStream: doc.
^ ggg nextImage.
I forget off hand how to pass multiple accept types to the HTTPSocket, but
unless someone beats me to it, I'll try to package up a fix in the next
couple of days.
After all, Scamper *should* work with such servers, given that Squeak can
in fact handle such mimetypes (by and large).
Whew, I hope I've redeemed myself *a little*.
Cheers,
Bijan Parsia.
More information about the Squeak-dev
mailing list
|