I am new to the phenomenon of scanned documents using a color scanner being very large in size. An 8 page document that was about 105K when originally delivered to me as a PDF file ended up being about 12.5M after I had printed it out, signed my signature and scanned it to a PDF file again.
Looking around the web, it seemed like there were many suggestions on reducing the size of a scanned document. There are software that will compress the size of your scanned PDF file, but nothing free. Ultimately I played around with the settings of my scanner (which is a Canon MP620 Pixma printer/scanner/copier combo) and found that the following settings reduced the size of the scanned image drastically.
The single change that had the biggest impact was to change the scan settings so that the document was scanned as a Black & White image instead of a Color image. Another setting that reduced the size further was to use 150dpi when scanning instead of 300dpi which was set as the default. Finally a big reduction results when you choose high compression when converting to a PDF file. Finally I went with just the Black & White scan setting only (since changing the other settings also reduced the quality of the resulting PDF file) and I was able to get a PDF of about 2M instead of the 12.5M that I was originally getting. So a decent amount of reduction in size.
IMPORTANT: See update to this below after the image
After several attempts at searching the WordPress site and googling around, I came across this forum post. Based on this forum post, I found that first configuring define(‘SCRIPT_DEBUG’, true); in wp-config.php and then refreshing my admin screen fixed the problem. Subsequently I removed this config line and refreshed my admin screen again and it stayed fixed.
This was with WordPress 3.3.1.
To fix my problem, I used the following shell scripts to detect files having the problem and to fix them.
Remember that I provide these scripts as an aid to anyone encountering the same problem and provide them as-is without any warranty. USE THEM AT YOUR OWN RISK. PLEASE MAKE BACKUPS OF YOUR FILES BEFORE RUNNING THESE SCRIPTS SINCE THEY WILL MODIFY FILES. The regular expression I used worked for me, but they may not necessarily work for you. BACKUP, BACKUP, BACKUP. Also the below may not be sufficient to rid your site of this mal-ware. I don’t know what else needs be done to completely rid your blog of the mal-ware.
To find all the files with this injected php code, I used the following script:
(In the above scripts, please fix the quotes and the double-quotes — pre-formatted code doesn’t wrap, so had to use regular formatting which messes with quotes and such)
Now I wait and watch to see if the problem re-surfaces, if it does, then I know there is more I need to do.
This happened yet another time and I cleaned up in the same manner. I also searched some more and found that someone had installed the infamous c99 shell to allow them backdoor access into my setup. They were using this backdoor access to periodically inject additional php code into my php scripts. I found the c99 shell by searching for the string “gzdef.ate.base.._encode” (I am using . instead of the actual character to prevent security tools from thinking this page has a security issue. Replace the dots with ‘l’, ‘6’ and ‘4’ in order). I removed the backdoor, but I am yet to find the vulnerability in the existing script that was exploited by someone to install the backdoor shell in the first place. Looking…