× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.


  • Subject: Re: eRPG; where are my images
  • From: "Jim Franz" <franz400@xxxxxxxxxxxx>
  • Date: Sat, 24 Jun 2000 14:11:51 -0400

I love standards - it irritates many programmers because they feel like
their creativity is impaired. Baloney! Almost started a riot in our shop in
the 80's for suggesting "standard" field naming, file design, date routines,
subfiles, etc. No one appreciates a monument to non-standard code that only
the author can work on.
For the Netscape/IE evolving "standards", check out the HTL Writers Guild
http://www.hwg.org/
Many good tips/techniques.
Jim Franz

----- Original Message -----
From: <booth@martinvt.com>
To: <MIDRANGE-L@midrange.com>
Sent: Saturday, June 24, 2000 12:00 PM
Subject: Re: eRPG; where are my images


> My experience is that nothing is lost and universality is won when one
> stays to an 8.3 naming convention.  Everyone's software understands
> myfile.txt and mypic01.jpg.  Longer names are nice but mixing cases,
> inserting blanks, and hidden extensions just cause unneeded troubles,
> especially when the Internet is still so new.  As the world begins moving
> to the new Internet Appliances and hand-helds we are going to see more and
> more browser incompatibility imho, so staying with the lowest common
> denominator makes sense unless there is a compelling argument to the
> contrary.
>
> _______________________
> Booth Martin
> Booth@MartinVT.com
> http://www.MartinVT.com
> _______________________
>
>
>
>
> Rob Dixon <rob.dixon@erros.co.uk>
> Sent by: owner-midrange-l@midrange.com
> 06/24/2000 05:55 AM
> Please respond to MIDRANGE-L
>
>
>         To:     MIDRANGE-L@midrange.com
>         cc:
>         Subject:        Re: eRPG; where are my images
>
> John
>
> I found that whilst Netscape would not access image with blanks in their
> name,
> Internet Explorer would.
>
> i.e. if any of your users use Netscape, you should use
>
> my_image.jpg
>
> and NOT
>
> my image.jpg
>
> This applies from Netscape 3.0 to 4.72 .
>
> In addition, even the file extension must be in the correct case.
>
> I also always send the browser the full URL with IP address for my own
> system but
> with domain name for other systems.  Hans gave the example -
>
> <img src="http://www.abc.to/dirname/images/image.gif">
>
> (Has Toronto moved to Tonga?)
>
> I store only
>
> dirname/images/image.gif
>
> for images on my own system and use code to generate the remainder
> including my
> own system IP address.  This has the advantage of less typing and so less
> room
> for error and if you change system, you do not need to retype all your
> image
> URL's.  Using the IP address means that the address does not have to be
> looked up
> and this should improve performance.
>
> For systems over which I have no control, I store
>
> www.abc.to/dirname/images/image.gif
>
> and generate the rest.
>
> I find jpg gives better quality images than gif.
>
> One advantage that Netscape has over IE (apart from the fact that it is
> not an MS
> product) is that if you send a larger image than you wish to be displayed
> initially and generate appropriate "HEIGHT" and "WIDTH" parameters so that
> it is
> displayed initially in the smaller size, users can right click on an image
> and
> select "view image" in which case it will be displayed in the maximum
> size.  I am
> not aware that you can do this in IE unless you send a request back to the
> server
> and the server sends a larger image file.
>
> I generally send ten images at a time, together with any data or text
> retrieved
> from my database, and display these in two rows of five images each with
> their
> own data.  Anyone requiring a more detailed image can just right click on
> it. If
> I know that only one image will be sent, then I send it in the larger
> size.
>
> Sending all images in larger size means that more traffic is sent down
> your
> network when users only look at the small size but less when they look at
> two
> sizes if you use a method that depends on sending a second file for the
> same
> image.  I find that using jpg files with minimal quality and so maximum
> compression means that a black and white image say 772 x 600 pixels is
> about 37k
> which is not too bad on a local network and works OK over the Internet.
> Colour
> images tend to be larger so I reduce the maximum size when creating the
> jpg file.
> Given that the quality of the very best screens is relatively poor, the
> difference in image quality on a screen between pictures with zero
> compression
> and those with maximum is not so great.  Maximum compression allows people
> to
> look at quite large images for identification purposes yet those images
> are not
> of adequate quality for them to steal and publish in printed form (unless
> on a
> postage stamp).  The maximum size that you transmit will obviously depend
> on the
> use to which the images are put.  The amount of compression that you can
> get away
> with will depend on whether the image is tonal - e.g. a photograph or
> painting -
> or is made up of lines - an engineering or architect's drawing or an
> etching.
>
> I hope this helps.
>
> BTW, can anyone tell me how to get image details such as image size from,
> say, a
> jpg file directly into an AS/400 file.  At present these have to be typed
> in.
>
> Rob Dixon
>
>
>

+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.