[alex_d]

I also do dilation and resizing differently from RasterFarian. I render the PDF/DJVU at the dilation DPI, without specifying a page size. So Ghostscript or DJVU automatically create a image with size appropriate for that resolution. I don't know what the size is up front at all, and in fact it varies from book to book.

That's what I was saying. The boldness intensification changes from book to book.

Hmm, I think that I'll go the image -> pngnq -> pnmremap route.

Use pnmremap only. Pngnq is designed to try to find the best 16 colors out of your monitor's 16M. It then sets up a 16-entry mapping table whose elements are 24-bit rgb. This will of course look good on your PC, but those colors it will find (e.g. a gray that's 250,250,250) just don't exist on the 16-color Iliad. The image's mapping table can't be optimized, it must simply be the one that the Iliad/Reader/etc can natively support. Pngnq might be useful if you want a 4-color bitmap for displaying on a 16-color device, but I don't think pngnq lets you input the right settings for that (I think it always picks out of 16M rgb). Lastly, the "dithering" step (the mixing of pixels after you figure out which pixels to mix) is done just as well by pnmremap as by pngnq. Running pnmremap and pngnq will perform dithering twice, actually reducing quality. (Running pngnq and then displaying on a Reader also does double dithering).

Hmm, I think that 7 does a little too much edge-enhancement, but I'm willing to change it. Actually, what would be nice if someone could volunteer to test various parameters and report what looks the best. Any volunteers?

Yes, we need a poll. I've done extensive testing, but I'm only one opinion. Also, the Sony Reader seems to best like settings which look too harsh on an LCD. But on your 1100, different settings will probably look better (but dude, quit doing image quality testing on your pc!)

[Bitmap autohinting is] done by all desktop PDF Readers I've seen, and I think it would be rather processor intensive, even if you do it in C.

No, I don't think anyone has tried bitmap autohinting before. PDF viewers (and operating systems) do regular autohinting where they look at the vector information itself. That approach can't be applied because by the time I increase the boldness of the font via dilation, I've lost all the vector info. I'll have to shift the pixels themselves.

It might be easier to just go back to the font vector-changing efforts and see if I can get better results out of that. Thing is that it's easy to take embedded fonts out of a PDF, a bit hard to deal with the various formats, and nearly impossible to modify the vectors (there is one commercial program that can do it, and this program is scriptable, but it obviously can't be distributed). What I haven't done, though, is research how to write a program that does the vector modifying itself. However, I think the math of scaling bezier curves and etc is beyond me. The worst part, though, is i'm not sure how it'll all turn out after rastering. Ghostscript's autohinting engine, for example, isn't optimized to antialias. It treats it like it's higher-res and then downsamples. OpenType autohinting isn't supported. In the end, the letters seem to turn out blurry and require edge-enhancement anyway. Also, unfortunately, it probably won't be able to make any use of the font's internal hinting information (since it'll likely become meaningless after the vectors change).