From: Gordon Henderson on
In article <eC24l.37045$cx7.502(a)newsfe21.ams2>,
Will Kemp <will(a)xxxx.swaggie.net> wrote:
>Gordon Henderson wrote:
>> In article
><756015b5-358d-4888-8ae0-33f384c54c7b(a)z27g2000prd.googlegroups.com>,
>> Ian <ian.groups(a)btinternet.com> wrote:
>>> Dear All,
>>>
>>> For a research project I need to set up a PC which can
>>>
>>> a) Accept incoming phone calls through a modem, set up a PPP
>>> connection, and bridge across to a standard broadband connection
>>> through a router (ie being an ISP for one other computer) and
>>>
>>> b) run a web proxy which can convert all JPGs into GIFs and modify the
>>> pages it's passing on appropriately - not unlike T-Mobile does when it
>>> replaces images with lo-res versions. It would also be useful if it
>>> could block all flash content and replace it with an icon saying
>>> "Flash content blocked".
>>>
>>> Can anyone point me in the direction of Linux stuff to do this? I'm
>>> afraid the purpose has to be confidential for now, but if anyone who
>>> could help really feels a need to know, email me and I'll tell you
>>> what I can.
>>
>> Would you not be better off keeping the images as JPGs rather than convert
>> to GIF. I can imagine a browser being upset when it recieves a GIF file
>> in the data stream after requesting a JPG.
>
>You couldn't send the browser a gif file if it's requested a jpg file
>(well, not unless you called the jpeg somefile.gif - which might stop
>the browser rendering it properly anyway). You'd have to rewrite the
>html on the fly, changing "somefile.jpg" to "somefile.gif", so the
>browser requested the gif file instead (which you would then convert on
>the fly).
>
>> I'm sure AOL did it that way
>> at one point - all you need to do is re-code the jpg in transit with a
>> lower quality setting.
>
>Why the lower quality setting?

I guess the OP wants to save bandwidth for dial-up users?

eg.

http://unicorn.drogon.net/power.jpg

is 436KB bytes long. Re-coding it with a jepg "quality" factor of 10%
takes the filesize down to 52KB. See

http://unicorn.drogon.net/power10.jpg

To compare.

Incidentaly, saving it as a GIF file (web optimised pallet), took the
same image gown to 119KB. So jpeg "wins" here.

http://unicorn.drogon.net/power.gif

Another thing to factor is cput horsepower/time required to do the
image transcoding - saving as a GIF took a lot longer than saving as a
10% jpeg...

Gordon
From: anahata on
On Tue, 23 Dec 2008 08:26:28 +0000, Gordon Henderson wrote:

> Would you not be better off keeping the images as JPGs rather than
> convert to GIF. I can imagine a browser being upset when it recieves a
> GIF file in the data stream after requesting a JPG.

Why? It could requested a .PHP URL and get back a graphic...
The browser must respect the "Content-type: header" - only if no such
header is present is it entitled to attempt to guess the file type by
parsing the request string.

--
Anahata
anahata(a)treewind.co.uk ==//== 01638 720444
http://www.treewind.co.uk ==//== http://www.myspace.com/maryanahata

From: Theo Markettos on
Gordon Henderson <gordon+usenet(a)drogon.net> wrote:
> In article <eC24l.37045$cx7.502(a)newsfe21.ams2>,
> Will Kemp <will(a)xxxx.swaggie.net> wrote:
> >You couldn't send the browser a gif file if it's requested a jpg file
> >(well, not unless you called the jpeg somefile.gif - which might stop
> >the browser rendering it properly anyway). You'd have to rewrite the
> >html on the fly, changing "somefile.jpg" to "somefile.gif", so the
> >browser requested the gif file instead (which you would then convert on
> >the fly).

Would the browser actually pay attention to the extension? Given the
various wacky file extensions out on the net (saw a .jp yesterday which was
HTML), doesn't the browser just pay attention to the MIME type? So if you
force the MIME type to image/gif and send the file as sample.jpg, will
things break? It might cause trouble if it saves the file on disc without a
MIME type stored with it - do any browsers do that as parto f their
rendering?

I suppose it depends who your users are. Are they, say, corporate types who
have a fairly controlled browser environment, or will you get everything
from NCSA Mosaic to a WebTV dialling in?

Theo
From: Will Kemp on
Theo Markettos wrote:
> Gordon Henderson <gordon+usenet(a)drogon.net> wrote:
>> In article <eC24l.37045$cx7.502(a)newsfe21.ams2>,
>> Will Kemp <will(a)xxxx.swaggie.net> wrote:
>>> You couldn't send the browser a gif file if it's requested a jpg file
>>> (well, not unless you called the jpeg somefile.gif - which might stop
>>> the browser rendering it properly anyway). You'd have to rewrite the
>>> html on the fly, changing "somefile.jpg" to "somefile.gif", so the
>>> browser requested the gif file instead (which you would then convert on
>>> the fly).
>
> Would the browser actually pay attention to the extension? Given the
> various wacky file extensions out on the net (saw a .jp yesterday which was
> HTML), doesn't the browser just pay attention to the MIME type?

Yeah, good point. It probably would work. But it might depend on the
browser. It would certainly be worth trying, before writing the code to
rewrite the html (although that's fairly trivial, anyway).



--
http://NovemberEchoRomeoDelta.com
From: Ian on
On 23 Dec, 09:57, Will Kemp <w...(a)xxxx.swaggie.net> wrote:

> You couldn't send the browser a gif file if it's requested a jpg file
> (well, not unless you called the jpeg somefile.gif - which might stop
> the browser rendering it properly anyway).

Ha. All these kids today who don't remember - or weren't around to
remember - that the early browsers like Mosaic and Cello only did
gifs. This project will have people using those early browsers to view
modern web pages, hence the need for conversion.

Ian
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5
Prev: Cheap Cigarettes online UK
Next: Spamassassin and Sendmail