Slashdot Mirror

The software piece you mentioned for turning scans into nice clean rectangles exists as "unpaper". Here's one fork: https://www.flameeyes.eu/proje...

The people who have bothered to fork and improve unpaper probably did so because they did a project similar to yours, so you might ask them about other tips and resources.

As someone else said, while pdf is convenient for READING book, it's not a particularly great format for archiving a collection of images which you may want to convert to another format later. There are several good grayscale image fomats to choose from. To order those images into a cohesive document, perhaps with separate chapters, one could produce html via a tiny Perl or shell script. That would preserve the images in their native format for later conversion as needed in the future.

Also try
make V=0
to disable silent mode if it was a Makefile generated by automake.

In my opinion, it is designed pimarily so that Intel's embedded processors run Android well in the short term. Atom architecture in particular benefits in that some pointer offset calculations are faster when done in 32-bit vs 64-bit. Here are some great discussion links: http://blog.flameeyes.eu/2012/06/debunking-x32-myths http://lwn.net/Articles/503412/

Thanks for the link. Time to read up on CMake. When debug a broken build script in Gentoo, my personal experience is that I usually figure out what's wrong more quicker with Autotool than Cmake. The main reason is probably that I am more familiar with the former from reading this autotool online tutorial/reference: Autotool Mythbuster

There is a very thorough blog post about why nobody really wants FatELF at

http://blog.flameeyes.eu/2009/11/04/elf-should-rather-be-on-a-diet.

"If you didn't know to check for "x86_64" in 1998, your otherwise-functional i386 version won't be run, and the script fails."

... but FatELF has the same problem. A FatELF binary doesn't compile a new version of itself whenever it encounters a new arch; it merely selects among the existing bundled binaries to see which one is appropriate.

Now, sure, some backwards-compatible architectures might have issues with the script, but the solution to that is simple - add a shell/library/kernel/whatever function to determine "are you $ARCH-compatible?" and expose that to scripts.

So that particular problem, at least, is solvable by something far simpler than FatELF.

I found Flameeyes' post regarding FatELF to be enlightening.

He's just a plain troll.

I get the impression most of the Mono devs are immature little shitheads, too.

couldn't they have made GCC suck a bit more so the alternatives wouldn't look so bad?

No to worry; 4.3.3 is a big step towards producing a compiler that punches you in the balls without a -Wno_punch_in_the_balls option.