The 3rd try worked. but small file

[newtype]

The 3rd try worked. but small file. The datasheets I scanned at 300 dpi.
come out +2 megs. I'm using Xnews. the maxium file cut size is 900k, that
was the main problem. I'm going to have to make rar's for each datasheet
page.
I tried looking at a datasheet at 72 dpi and it's not good. 150 dpi is no
good either. if you are going to print these out, it's best to keep 300
dpi.

cya

 

[Mark Zenier]

In article <Xns972AE7FD2433Ares808c4earthlinknet@63.218.45.254>,
newtype <res808c4@earthlink.net> wrote:

The 3rd try worked. but small file. The datasheets I scanned at 300 dpi.
come out +2 megs. I'm using Xnews. the maxium file cut size is 900k, that
was the main problem. I'm going to have to make rar's for each datasheet
page.
I tried looking at a datasheet at 72 dpi and it's not good. 150 dpi is no
good either. if you are going to print these out, it's best to keep 300
dpi.

If you still have an account and can read this...

JPeg is the worst possible file format for datasheets. It's designed
to compress big blobs of color. It bloats when given tons of fiddly
little transitions that you get with a lot of text. You need to use
a pixel oriented file format with a fixed color palette with run length
encoding.

You need to:
1. use black and white
2. threshold the file so that there are only two possible values
for each pixel. (Black and white "line art" in your scanner driver)
3. Save as an indexed (limited color palette) file format:
GIF, or PNG, or postscript (to be distilled down to pdf).

Most popular would be to distill postscript down to a .pdf file.
..pdf seems to have one of the better compression schemes for monochrome
pictures, often half the size of a GIF.

AND PUT IT ON YOUR WEB PAGES
OR POST IT TO alt.binaries.schematics.electronic

I get 50-100k bytes per page at 300 dpi. (see the stuff in
ftp://ftp.eskimo.com/u/m/mzenier/ for examples).

Mark Zenier mzenier@eskimo.com
Googleproofaddress(account:mzenier provider:eskimo domain:com)