Free design engineering book

It's quite likely I've mentioned it before. It's a shame it's so hard to find, but I think it's worth the effort.

Reply to
Ned Simmons
Loading thread data ...

Well, thanks, I've put it on my book list and I'll hope to get time to look into it. The title sounds interesting.

-- Ed Huntress

Reply to
Ed Huntress

I can understand somewhat with stuff still under copyright, but why do crappy work (a good scan/photo takes the same amount of time as crappy. Turning & positioning takes most of the time.) with stuff in public domain? I've looked at what others have done with this using the djvu format and it is quite good.

For instance, this series of books is pretty good (Turning and mechanical manipulation intended as a work of general reference and practical instruction on the lathe, and the various mechanical pursuits followed by amateurs - 1850):

formatting link
formatting link
formatting link
formatting link
If you want a local copy to peruse, click on the "All Files: HTTP" on the upper left side and download the djvu version from the file listing. If you click on the djvu version directly you will get the stream, which is for use with a browser plug-in.

This would be the link for volume 1 for instance:

formatting link
If you need a free djvu viewer there are a couple other alternatives besides what Lizardtech offers. See:

formatting link
formatting link
The latter set of tools can create simple djvu documents also.

You may find this listing of interest too, just don't expect too much if the original source was Google. The text is usually readable, but the diagrams and images can be poor:

formatting link
For the Google stuff I've found that the pdf version is usually a bit better. The djvu versions seem to be based on the pdf and thus suffer from compression artifacts.

I think I already have some of Fred Colvin's texts. Take a look at this listing:

formatting link
It is a fun place to poke around looking for old books...

Reply to
Leon Fisk

If the book is old enough to have discolorations you can need to tweak the scan parameters on each page to maximize the contrast in the print while minimizing the inclusion of changes from the stains and discolorations. This is especially so if you are scanning to single bit density (maximum compression possible), though you can get away with less care when scanning to color -- but the image sizes will be much larger and much more difficult to compress.

I know this from scanning manuals for various old machine tools.

Given the number of pages in a typical book, having to go through two or three trial scans for each valid scan can vastly increase the time the job takes.

Enjoy, DoN.

Reply to
DoN. Nichols

I've fooled round with this too and tend to agree somewhat.

Pretty much everything I have done is in grayscale and only

4 bit (16 shades) via flatbed scanner. I just try and concentrate on getting a straight scan and correct the contrast & brightness after the fact. Always save original in some lossless format like compressed tiff or png.

It looks like the stuff I currently like is being done with a camera and then saved in JP2 format (which could be lossless). I don't know what Google is doing but with the current crop of cameras on the market I would sure try that route before using a scanner.

Take a look at the example I gave earlier:

formatting link
especially the all files page:

formatting link
Note this file, "turningmechanica01holtuoft_raw_jp2.zip", which is around 240 meg. It is 512 images/pages long. They are taking some pretty good sized images. From what I can tell 400 dpi. Some other decent books I have are 500 dpi. If I had a high-speed connection I would download the raw zip archive and take a better look.

This is a nice book/document in highly compressed djvu format and completely text searchable. The OCR engine being used seems to do a pretty good job. I can't see any good reason why Google can't somehow do the same with their project.

Reply to
Leon Fisk

O.K. I scan on an old HP ScanJet 5p SCSI color scanner.

In the past, I used the HP application which I downloaded for a Windows system, but recently got the SANE system to work on my Sun Blade

2000, and I find it a lot better -- both the xscanimage (GUI interface), and the command-line scanimage which is really nice for batch mode, because it can automatically increment the numbers in the filenames.

Ouch! In xpdf it shows up terribly smeared. Going to Acrobat, it is a lot more readable, but shows print-through from the other side of the page -- wrong contrast and exposure settings.

And I don't know how them manage to make it so xpdf (the free unix-based PDF viewer) turns into terrible smears. Has Microsoft expanded the PDF format? :-)

And -- I can't view jp2 images. I guess that I need to download some more libraries and re-compile some programs.

Hmm ... the only programs which I can find for jp2 (jpeg2000) have a .exe extension -- and the only source for them is for Windows, so I'll have to wait a while before I can do anything with these.

"ddjvu" hits a problem:

====================================================================== ddjvu: [1-15108] Corrupted IFF file (Illegal chunk id). ======================================================================

Well ... if they have to use an image format which is not widely supported, I'm out of luck at least.

Enjoy, DoN.

Reply to
DoN. Nichols

See if there is anything you can use for viewing djvu from this page:

formatting link
They mention a binary for Debian towards the bottom of the page. Also a link for a Java version over along the left side.

I shied away from the djvu format for years and only recently became interested. It does a really nice job on old books if done properly.

Jpeg 2000 (jp2) files have been around for awhile already. I know GraphicsMagick has support for it. Seems to me that is available for Unix type systems.

Some info/history and possible sources here:

formatting link
I only mentioned the jp2 files to give you an idea of how much data they are getting from their image taking. I am curious to look over that data. May just have to suck it up and download one of the smaller archives sometime and take a peek inside.

Reply to
Leon Fisk

Hmm ... it is now downloaded, but I need to build two other packages to go under it:

djvulibre-3.5.21.tar.gz qt-x11-opensource-src-4.5.0.tar.gz

A Debian binary will amost certainly be an x86 binary, not much use on an UltraSPARC III CPU. :-) So, I'm going for the sources instead.

The qt-x11 claims to support Sun's Solaris, so we'll see. Only the 32-bit version, but the UltraSPARC can run both 32-bit and 64-bit, with the 64-bit being a bit faster.

Hmm ... might be able to use that.

When I got it some years ago, it was for some downloaded manuals for old equipment -- Electronics test equipment, IIRC>

I don't have GraphicsMagik, but I do have ImageMagick, and it was one of the ones which I tested on the jp2 files I downloaded. It simply complained that I did not have a codec for jpeg-2000.

Getting newer software is such a pain when I have to download and compile a half dozen libraries before I can compile the desired software. And often, those half dozen libraries need another half dozen before I can compile *them*.

It might be easier to load them into the OpenBSD systems, which tend to have a lot of the libraries as pre-compiled packages.

I stumbled across that while trying to find the libraries which I needed. Here is the major killer paragraph:

====================================================================== JPEG 2000 has been published as an ISO standard, ISO/IEC 15444. As of

2008, JPEG 2000 is not widely supported in web browsers, and hence is not generally used on the World Wide Web. ======================================================================

I just found and got the java version as well, so we'll see how that goes first. If that fails, I may spend a while before attacking the full compilation sequence, because I'm about to go in for cataract surgery, and don't know how well I'll be able to work until that is over. The first one this week, the second about a month later.

O.K. I've still got to compile the qt package to use the java version. I'm tossing it at the compiler, but if I hit any problems, it is going to wait until after the surgeries are complete. :-)

It is a big collection. The zipfile is 239MB in size, and took a long time to unzip because it created a lot of files. I've blown the directory of files away for the moment, and will recreate it when I have something to use on it.

Enjoy, DoN.

Reply to
DoN. Nichols

Good luck with all of that. Sorry I'm not much help. I'm pretty good at keeping my old WinNT4 running, but that doesn't help you any.

ImageMagick is suppose to have support for jp2 now. It turns up (jp2) here and there nowadays. I wouldn't knock yourself out trying to support it. Sooner or later though you will need it for something you really want.

I can relate in a way. A lot of the Windows stuff won't directly run on NT4 anymore. MS has seen to it that the newer compilers they sell don't build compatible executables unless you jump through hoops first. Thus most programmers don't bother making builds that are compatible with the NT4 libraries/dll's. With a bit of creative hacking I can sometimes get them to run anyway...

Every so often I see people requesting for Opera to start supporting jpeg 2000 directly. I follow/read several of their newsgroups. Eventually I suspect it will be supported by one of the big web browsers. The rest will have more incentive to follow suit then.

Best of luck with the eye surgery. Your comments and expertise will be missed, hopefully for only a very short while :)

Reply to
Leon Fisk

Nope -- but I expect problems with newer software standards. :-)

O.K. Perhaps I'll get the latest and try my hand at compiling it -- assuming that it does not require the same libs which I'm already having trouble compiling.

The "qt" package compile halted wit the following summary of errors:

====================================================================== "glextensi ====================================================================== typedef void (APIENTRY *_glBufferData) (GLenum, GLsizeiptr, const GLvoid *, GLenum); ======================================================================

so perhaps I need to find where GLsizeiptr is supposed to be defined. Whatever it is, it is screwing up the syntax of that line.

And it turns out to be in the "demos" subdirectory, so I could probably live without it. :-)

There -- it is a case of Microsoft apparently intentionally making support more difficult.

Here -- it is writers of packages depending on a ton of other packages which typically come with some linux distribution or other, but which you have to find, fight through the linux/unix differences, and force to compile before you can move on to the next stage.

It used to be fairly easy to wade through all the open source programs and to get most of them to work. Now, there are so many choices, some mutually incompatible, that it is getting more and more difficult -- almost easier to write the software from scratch yourself. :-)

Hmmm .... I just downloaded and installed Opera 9.64. I wonder whether that was a security hole fix, or a significant addition?

I do know that they have two problems with the static version for Solaris:

1) A file is present, but not in the directory which the install script looks in. 2) It uses an option to grep "-q" which is not present in the standard version -- only in the version in /usr/xpg4/bin/.

The solution to the first is adding a symlink before running the script.

The solutions to the second are:

a) Add "/usr/xpg4/bin/" in front of "grep" the one place where the "-q" option is used.

b) Add to the start of the script a line adding "/usr/xpg4/bin/" to the beginning of the path.

I've reported this problem to them once or twice, but it continues to occur.

Thanks!

Hopefully. I'll be at least spending a month with unbalance vision. The cataracts have shifted the natural focus from "sharp at a distance" to "sharp at 10", and the replacement lenses are supposed to give me something close to "sharp at a distance" again, so one eye will be very different from the other.

But if the surgery goes well (I've apparently got rather advanced cataracts, and this made it difficult to get a good measurement of the lens capsules, and may make removing the remains of the old lens more difficult as well), then I should have the eye on the side which faces the computer monitor (on an arm beside my chair, and quite difficult to switch to the other side) back to somewhere that I can use my own glasses instead of my wife's glasses for the computer.

I found it interesting that the cataracts shift the focus. Apparently they add volume in the lens cell, thus making it fatter and thus shifting to a much closer focus.

Thanks again, DoN.

P.S. Scheduling my surgery for 8:45 AM, with me needing to be at the surgery at 7:15 AM, and with me accustomed to going to bed at 2:00 AM and getting up at 12:00 or 1:00 PM means that I'm going to get very little sleep tonight. :-(

At least the *surgeon* should be quite alert, which is what matters. :-)

Reply to
DoN. Nichols

Just a quick follow-up that may answer this question:

formatting link
I've been using the Opera 10 alpha since last December. They are up to the 4th build now. The Windows version seems to be quite stable. More info here if you care to fool with it:

formatting link
And good luck getting some sleep. I normally get up ~5:45am. I will have my early morning walk done, simple exercises and probably some coffee already by the time you get to the hospital :)

Good luck with it!

Reply to
Leon Fisk

O.K. Security patches. I should have expected that with the increment in the third digit. :-)

Looks interesting. But the only version for Solaris is for the Intel version, not the UltraSPARC version.

I guess that I could try it on the Intel-based Mac Mini, but I almost never use the Mac for web browsing, and the one who does at the moment (my Rent-A-Daughter) is using Safari, so there is little point to trying that.

I notice several of the noted problems for the current one are associated with the mail functions, which I don't use in a browser anyway. :-)

Thanks! DoN.

Reply to
DoN. Nichols

formatting link

formatting link

Wow. 'Lots of stuff to look at. I have the DjVu plug-in but it only worked for a few pages and then crapped out. But I could see what you mean; the quality was quite good.

That Colvin book list looks pretty complete. My old boss at _American Machinist_, Andy Ashburn, knew Colvin and may have worked for him. It's a little vague in my recollection.

He sure was prolific. I wonder when he had time to write for the magazine.

-- Ed Huntress

Reply to
Ed Huntress

Get one of the djvu reader programs I had links to. I prefer the WinDJView one because it is pretty fast on my old computer.

If you (or anyone else for that matter) gets this version of "American machinists' handbook and dictionary of shop terms" by Colvin in the djvu format it is text searchable (using WinDJView at least):

formatting link
Direct link to the djvu version (~20mb):

formatting link
It was a competitor to the Machinery's Handbook at the time. Well worth having around for reference.

Just go look in the mirror Ed, should answer that last question :)

Reply to
Leon Fisk

formatting link

Yes, I have several editions. And I was the fifth (I think) editor since

1955 to try to revise and update it. I spent roughly a year on it in 1981 - 1982, and finally decided that it was so far out of date that the research and writing time wasn't worth it. Someone did finally do a re-write, but I got one look at it and didn't think the results were worth it, either.

Too bad. It was the standard for machine shop methods for decades. Machinery's Handbook had more numbers.

Ha! Well, having written chapters of three McGraw-Hill technical books, I have to say that the time spent per page on that kind of book writing far exceeds the casual writing here. It's a heck of a lot of work. Colvin must have been a workaholic.

-- Ed Huntress

Reply to
Ed Huntress

PolyTech Forum website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.