Adobe Acrobat Becomes Excessively Disability-Aware

I was using Adobe Acrobat 9 in Windows 7.  Suddenly it developed a sensitivity to diversity issues, particularly in the area of disability.  That is, it started offering accessibility services that I didn't want or need.  One message come up when I printed a .PNG image file to PDF.  As soon as Acrobat opened the PDF, it said this:

This page contains only an image of a scanned page.  There are no text characters.  Would you like to run character analysis to try to make the text on this page accessible?

I clicked the "Do Not Show Again" box and then OK.  The only alternative was Cancel, and I was afraid that would be construed as "please ignore what I just said."  Wrong guess:  it ran OCR on the page, which in this case meant it completely screwed it up.  I printed it again.  This time it didn't ask.  Fortunately, it seemed to be ignoring what I had just instructed it to do (i.e., run OCR without asking):  it didn't run OCR.  Another thing it did, when I printed an HTML page to PDF, was to flash a screen that said this:

Content Preparation Progress

Please wait while document is being prepared for.

At least I think that's what it said.  It flashed by pretty quickly.  It didn't say what the document was being prepared for.  But the result was a crappy-looking PDF.

I guessed that I must have hit a funky key combination that turned on some kind of accessibility feature.  I hadn't started this post when the problem first arose, but something had caused Acrobat's Accessibility Setup Assistant to spring into action.  There didn't seem to be any option to shut it off, at least not on the dialog that popped up.  I ran a search.  In one thread, someone commented that this sort of thing happened only when they had Speech Recognition turned on.  In Acrobat, I went into Edit > Preferences > Accessibility.  I unchecked everything and then printed that HTML page again.  No improvement.  Another person in that thread suggested going to C:\Program files\Adobe\Acrobat 8.0\Acrobat\plug_ins and renaming Accessibility.api to be Accessibility.old.  I tried that.  Now I got a new message:

No Screen Reader Support

This version of the Adobe Reader does not support screen readers.  Information about downloading a version with screen reader support is available at http://www.adobe.com/go/reader_download

Apparently the step of making the Accessibility.api file unavailable was to persuade the system that Acrobat was not available for this purpose, and it should use Adobe Reader instead.  In that case, it sounded like the instructions to use accessibility settings might be coming from Windows, not from Acrobat.  I clicked the "Do not show this message again" box and tried printing the HTML page again.  No, it still displayed the page in Acrobat, not Reader -- which, when I checked in Control Panel > Programs and Features, wasn't even installed on my system.  I decided that renaming Accessibility.api to be Accessibility.old had not solved the problem, so I changed it back.  I did take a look, nonetheless, at Control Panel > Ease of Access Center (formerly Accessibility).  I went into the "Make the computer easier to see" option.  The only thing turned on there was the first option, "Turn on or off High Contrast when ALT + left SHIFT + PRINT SCREEN is pressed."  I turned that off, clicked Apply, and tried printing the HTML page again.  No, still got lousy output.

I couldn't see anything else obviously wrong in the Ease of Access center, so I went back to that discussion thread for more ideas.  But there weren't any.  A How-To Geek webpage gave me the idea that maybe the full message (above) was, "Please wait while the document is being prepared for reading."  This page said that renaming or removing Accessibility.api would kill that "Please wait" message.  And that might have been true; I hadn't looked specifically at that part.  But that wasn't my main objection. My main objection was that I was getting crappy PDFs.  And when I put it that way, I realized that it might be a problem with the PDF printer.  I was using Bullzip.  Was there an option that had gotten set wrong somehow?  In Bullzip's Options > Image tab, the resolution was set to only 150.  Was that 150 dots per inch?  If so, that could explain part of the problem.  I set it to 300 and tried again.  No change.

Participants in another thread, describing similar problems, seemed to say that the problem arose, for them, when they used Acrobat's speech tools.  I wasn't familiar with them, but thought I might take a look.  I went into Acrobat with no document open.  In Advanced > Accessibility, the only option that wasn't grayed out was Setup Assistant.  I went in there and selected "Set all accessibility options" > Next.  This seemed to be taking me through the same options that I could have gotten via Edit > Preferences.  I noticed that "Disable text smoothing" was checked, so I unchecked it; text smoothing sounded good.  In the next screen, I left it as I found it, with only one thing selected, "Infer reading order from document."  In the screen after that, the only thing selected was, again, the default, "For large documents, only read the currently visible pages."  In the screen after that, "Disable document auto-save" had somehow gotten checked.  I wanted auto-save, so I unchecked it.  Evidently the funky key that I had accidentally hit, whatever it was, had told Acrobat that I had some kind of disability, and therefore it launched into a whole menu of disability assumptions.  Anyway, the only thing I left checked on that page was "Reopen documents to the last viewed page."  By this point, I was seeing that, yes, I could have achieved these same changes by going into Edit > Preferences, but the one-size-fits-all disability assumption seemed to cherry-pick options from a variety of different Preferences submenus.  This seemed to be a better way of detecting what it had messed up.

Anyway, that was the last screen.  I clicked Done, and tried printing my HTML document again.  This time it was better.  The font looked good.  So part of the solution was to go through the Accessibility Setup Assistant and reverse some of its settings.  I was still getting that message, "Please wait while document is being prepared for."  I renamed Accessibility.api to be Accessibility.old again and reprinted the HTML document.  No more "prepared for" message.  So the other part of the solution was to kill Accessibility.api.  Ah, but now I had a new problem.  When I tried to go into Edit > Preferences, I got an error:  "Failed to load an application resource (internal error)."  I restarted Acrobat and tried again.  Same error.  Apparently it couldn't go on living without its Accessibility.api.  I renamed Accessibility.old back to Accessibility.api and tried again.  Yes, now I could go into Preferences.  So it seemed I might have to cope with that "document is being prepared for" message.

One poster in that thread seemed to say that, if Microsoft Magnify was turned on when Acrobat started, Acrobat would detect it and would assume that the user had a disability.  This was an interesting possibility.  Was Acrobat detecting some running program and inferring disability from that?  I went into Start > Run > taskmgr.exe > Applications tab and took a look.  Nothing obvious.  Well, the Ease of Access Center was open.  I closed that and tried printing my HTML page.  Nope, that wasn't the answer; I still had the problem.  I right-clicked on an empty spot on the Taskbar and went into Taskbar tab > Customize.  I looked at the System Tray utilities shown there.  A couple of possibilities but, again, nothing obvious.  There was a troublesome utility that I'd had a hard time deleting, DropCommand, but I was able to delete it now.  I doubted it was the problem.

I rebooted into Safe Mode, thinking this would tend to simplify the picture somewhat:  fewer programs would be loaded and running.  Instead, Safe Mode gave me a new cluster.  No PDF printers installed.  I didn't know that about Safe Mode.  I tried installing Bullzip, but got an error when I got to the part of installing the Ghostscript part:  "Unable to register the DLL/OCX:  RegSvr32 failed with exit code 0x5."  I started Acrobat, but within a few seconds I got an error message there too:

Licensing for this product has stopped working

You cannot use this product at this time.  You must repair the problem by uninstalling and then reinstalling the product or contacting your IT administrator or Adobe customer support for help.

So, OK, at least this gave me an opportunity to reboot.  Back in Normal Mode, thankfully, I did not get a licensing error message.  So then, to return to the question:  what programs might be running that would trigger a belief, in Acrobat, that I needed a bunch of disability options to be installed without asking me?

I wasn't sure how to get an answer to that, short of a potentially very time-consuming process of eliminating programs, one by one, and rebooting, and seeing what happened.  This was problematic now because, for some reason, when I tried to print my HTML page, I didn't have any problems.  So it seemed that I might have fixed the symptoms, at least.

Instead, a day or two later, there were new developments.  Now Acrobat's toolbars were no longer functioning properly.  They had been erratic in Acrobat 8; less so in Acrobat 9; but now the Crop option was gone, and other toolbar settings would be disregarded.  I tried a repair:  Control Panel > Progams and Features > select Adobe Acrobat > Uninstall/Change > Repair.  This repair called for a reboot.  I'm not sure how that turned out; my notes are weak at this point.

I also had another problem.  When I opened a newly downloaded PDF, I got this message:

Reading Untagged Document

This 133-page document is untagged and must be prepared for reading.  While the document is being analyzed, your assistive technology will not be able to interact wiht this application.

I canceled out of that and went through the steps I had figured out so far:  change things back the way I wanted them in Advanced > Accessibility > Setup Assistant.  Then I reopened the PDF.  Still got that same "Reading Untagged Document" dialog.  I had that DropCommand program installed on that machine too, so I deleted it.  There wasn't an uninstall option that I could see.  As on the other machine, I had to move the executable to the Recycle Bin folder and then delete it after a reboot.  A couple of days passed before I did that reboot.  The problem was still there.

This problem was one of several, along with some major hardware changes, that prompted me to give up and reinstall Windows 7.  My best guess was that this problem was related to a sticky Shift key problem, and that several such issues ultimately stemmed from a failing KVM switch.

Adobe Acrobat: Adding JavaScript Addons; Flattening Form Fields

I was using Acrobat 9. I combined some PDFs into one.  One or more of those PDFs was a form, with blanks to be filled out by users.  Thus, my combined PDF also looked like a form.  Specifically, it had a purple banner across the top that read,

Please fill out the following form. If you are a form author, choose Distribute Form in the Forms menu to send it to your recipients.

I wanted to get rid of that banner. One way would have been to print the whole document to PDF, but that would have made it much larger. Among other suggestions, I liked the one pointing to the Flatten Page Content Tool.  It sounded like this would provide what I needed.

To make that tool work, I needed to install a Java script.  The instructions told me that installation simple required me to copy the script into an appropriate folder.  The folder could be Acrobat’s App folder or its User folder, but not both.  The difference was that scripts in the App folder would be available to all users, while scripts in the User folder would be available only to the individual user.
The writer of the instructions said that, on his/her machine, the App folder (which I intended to use) was located at C:\Program Files\Adobe\Acrobat 8.0\Acrobat\JavaScripts.  My system was apparently different from theirs.  The original tipster said that, on her machine, the folder was at C:\Program Files\Adobe\Acrobat 9.0\Acrobat\Javascripts folder.  I suspected (but was not sure) that mine was at C:\Program Files (x86)\Adobe\Acrobat 9.0\Acrobat\Javascripts.

The instructions indicated that there was a way to find the location of the App folder for sure.  I just needed to type “app.getPath("app","javascript");” in the Acrobat JavaScript Console.  The instructions said I could find that by going into Acrobat and hitting Ctrl-J.  But when I did that, I got a JavaScript Debugger that didn’t seem to have any way to do anything with the console.  I could type “app.getPath("app","javascript");” into the open space, but there was no Enter or Run button.  A guide said that, to “evaluate” (presumably meaning “execute”) a single line of Java code, I should put the cursor on that line and press Enter on the numeric keypad or Ctrl-Enter on the regular keyboard.

That worked.  I got “/C/Users/Ray/AppData/Roaming/Adobe/Acrobat/9.0/JavaScripts”.  So apparently my guess was wrong:  this was the folder where I needed to put the Flatten Page Content Tool script.  So I downloaded and unzipped that tool.  From the resulting folder, I moved the PDFScript_FlattenPages.js file to that C:\Users\Ray ... JavaScripts folder.  I had Acrobat running at the time, which was probably completely inappropriate.  I closed it, reopened the offending PDF, right-clicked on its toolbar, and chose More Tools.  There was an apparently new addition:  Add-on Tools Toolbar.  It was already selected.  And now, as I looked more closely at the toolbar, I saw that, indeed, I did have an icon for a hammer hitting  piece of paper – perfect for flattening a document.

The original tipster said this would permanently flatten the fields, but that they could still be edited in Illustrator, Photoshop, etc.  I didn’t care about that; I just wanted to lose the purple banner.  I hit the hammer icon.  It said, “Select Pages to Flatten.”  I chose all.  It was a large document, but the process was almost instantaneous.

About this time, I discovered that I could have just hit the button at the top left to hide that purple banner.  I really knew that already.  I'm sure of it.  Flattening didn’t reduce the PDF size for my purposes either.  OK, futile gesture.

Optical Character Recognition Freeware: JOCR and FreeOCR

I had some PNG images of text files.  I wanted to do optical character recognition (OCR) to convert their contents into text.

I already had Adobe Acrobat.  I tried printing the PNGs as PDFs in Acrobat, which was capable of doing OCR.  Unfortunately, its recognition was poor, even when I set its PDF printer to 1200 DPI.

Next, I turned to a fairly recent review of desktop OCR software.  It looked like the best-known OCR freeware engines might be the Cuneiform, the Tesseract, and the SimpleOCR.  I checked Softpedia for examples of those.  Cuneiform was virtually unknown, and SimpleOCR was making a mediocre showing, but FreeOCR (using Tesseract) seemed relatively popular.

That review also directed me toward JOCR, which was apparently designed to do OCR directly from the screen. The reviews of JOCR at CNET and Softpedia were underwhelming.  But because it was supposedly designed to do OCR directly from the screen, I decided to compare it against one of the others.  FreeOCR seemed to be the most likely candidate.  I might have gotten different results from one of the other OCR engines, or from another implementation of the Tesseract engine.

I let JOCR and FreeOCR try their luck with a screenshot taken from a maximized Notepad display of a text file, upsampled to 300 DPI.  (FreeOCR had frozen with a 600 DPI file, which JOCR had been able to handle without difficulty.)

Briefly, the FreeOCR output was visibly inferior to the JOCR output.  Of course, this was a test with text from an image, for which JOCR was specially designed.  There was no question, at least within the parameters of this brief test, that JOCR was producing better output.

Compared against the original text, the primary problem with the JOCR output was in the area of capitalization.  The recognized text was generally pretty accurate, with few dropped letters or other errors.  Overall, its output would have made a bad impression, if pasted directly into the body of a professional letter or memorandum; but its output was quite good for archival purposes of capturing the wording in an image.

Windows 7: Testing/Verifying/Validating PDFs

I had previously gotten the impression that I could test PDFs by using IrfanView to convert them to JPGs.  (This was different from the approach I had recently taken to merge scattered JPGs into multipage PDFs.)

In a dry run, IrfanView had balked at a bad PDF, but had converted the good ones.  So the scenario was that I would run the conversion; check the output folder; verify that it had the correct number of files; and if the numbers of files didn't match up, I would go hunting for whatever was missing.

Now I had a bunch of PDFs that I wanted to test, so it was time to try out that theory.  I had found it helpful to use an Excel spreadsheet to work up the list of files to test.  (The post on multipage PDFs, above, contained some discussion of how I used Excel to create and massage lists of files.  More information appeared in an earlier post on renaming thousands of files and in another recent post on using a batch file to sort files.)

The PDFs that I wanted to test were scattered across different folders.  The conversion scenario would have me create JPGs from these PDFs, where the JPGs would all be in one folder.  That way, I could easily count them, keep them from cluttering up other folders, and delete them after I was done counting them.  A problem with all those JPGs converging into one folder was that I might have two identically named source PDFs in different folders.  For instance, there might be something called File001.jpg in D:\FolderB, and another completely different File001.jpg in E:\FolderQ.  The JPGs resulting from these two different PDFs would either overwrite or fail to come into existence, depending on how I set IrfanView's conversion process.  This would screw up my count and would potentially fail to test some PDFs.  I could surmount this problem by batch renaming those files into unique names, as long as I kept the list of what I had renamed so that I could rename them back when I was done screwing around.  That approach would involve time-consuming extra steps, though, so I was hesitant.  (For more information, go to this webpage and search for "ZZZ_00001.jpg.")

There was another problem, as I thought about it.  A three-page PDF would presumably convert into three one-page JPGs.  So my file count would get messed up that way too.  I could probably opt to convert instead from mulitpage PDFs into multipage TIFs, but I wasn't sure what would happen if one page on a JPG was junk.  I would have to experiment to see if the TIF would swallow it or barf.

These reveries were interrupted by an actual test.  I tried using IrfanView to batch-convert three PDFs to JPG.  It gave me errors:  "Can't load D:\Current\Text\x1.pdf" (and likewise for x2.pdf and x3.pdf).  One was a single-page PDF, so multipage issues weren't the problem.  I couldn't understand it.  I had previously used IrfanView for this purpose.  The PDFs opened OK in Adobe Acrobat (and would presumably do so in a free or less expensive alternative to Acrobat).

It occurred to me that maybe I could use Acrobat > Advanced > Document Processing > Batch Processing.  I tried that on my test files, saving them as RTFs rather than JPGs to circumvent multipage issues.  It was surprisingly slow, and the resulting RTF files were empty.  Not a promising start.  Going back to somewhere near the original plan, I tried using Acrobat to convert to JPG instead of RTF, and that worked.  As expected, each PDF page became a distinct JPG.  For instance, x2.jpg became x2_Page_01.jpg and x2_Page_02.jpg and so forth.  I would have to do further filename massaging in Excel, or maybe run a series of DEL commands (e.g., DEL *02.jpg, DEL *03.jpg, etc.) to see if the number of output JPGs (or groups thereof) matched the number of PDFs tested.

I wondered, at this point, why I couldn't just batch print the PDFs being tested -- print them to PDFs in another folder, that is, and do the file count and then delete the prints.  Would a junk PDF print?  I created a junk PDF by taking a copy of one of my test files, opening it in Hexedit, looking a little ways down in the ASCII column for Root # 0 R (in this case, it was Root 124 0 R), changing it to Root 00 0 R (inserting 30 as the hex value for zero), and saving it.  Then I made Bullzip my default PDF printer, changed its settings so that it would print without stopping to ask questions (via the Options shortcut in the Bullzip program folder), selected all four of my test files, and went to right-click > Print.  It printed three of the four.  I didn't have the settings right -- it still asked for filenames -- but the test worked:  for the file I had just made into a junk PDF, Bullzip (or, actually, Acrobat, my default PDF reader) gave me an error message ("There was an error opening this document.  The root object is missing or invalid" -- which was, of course, exactly what I had changed), and no output PDF was created.  So this approach of trying to print to PDF would work to identify at least some kinds of defective PDFs.

Unfortunately, that error message didn't specify which file was defective.  So that approach would require me to subtract the files that had successfully printed from the larger set of files that I had requested to be printed.  That might be a pretty fast process, if I used the same output filenames, paused for five or ten minutes, and then used Windows Explorer to copy the output PDFs over the original PDFs and then sorted by timestamp.  The PDFs with the visibly older timestamp, after that maneuver, would presumably be the ones that had failed to produce anything that would overwrite them.  This approach would wipe out my originals, which I would not want, so it would probably be best done using copies of the originals.  If there was some need to reverse the timestamp, I could probably fiddle with the system clock before step 2, so as to produce artificially ancient output PDFs.

Another approach might have been to use an Acrobat-type program to concatenate many if not all of the PDFs being tested into one PDF.  I wasn't sure if junk PDFs would concatenate.  I selected my test files > right-click > Combine supported files in Acrobat.  Acrobat said, "There was an error encountered while combining files.  Do you want to open the combined file or return to the file list and try again?"  I told it to open the combined file.  Acrobat's Bookmarks pane showed bookmarks for each of the good files, but no bookmark for the bad one.  So that would be one way of getting a list of good PDFs.  Of course, the concatenation process could be slow, especially because the resulting document could be huge.  The size of that document might also cause the Acrobat-type program to crash.

But this still wasn't giving me a testing approach that would test PDFs in place, without requiring me to relocate them to a single folder where I could manipulate them.  I could try to work up a batch command that would print the PDFs on my list to a common output folder from where they were, but in that case I wouldn't have two simple lists to compare.  Unless I could persuade the batch command to report its errors to a log, I would apparently have to go through the printing process manually, making sure to write down or attend to each PDF that didn't print.

I ran a search, to see if Bullzip could escort me out of this situation.  This strategem led, strangely enough, to the Bullzip manual, to which I probably already had at least a link in my Bullzip program folder.  But the manual -- besides being no fun -- seemed to be oriented toward installation rather than usage.  A search in the Bullzip forum led to the suggestion that I look at a bioPDF webpage.  bioPDF seemed to be telling me that I could use a program called PrintTo.exe to do the job.  But where could I find this PrintTo.exe program?  I wasn't seeing a link to it there on the bioPDF site.  A search of files on my computer turned up nothing.  It didn't register when I typed "printto /?" on the command line.  Softpedia didn't have it.  And yet a search produced indications that Bullzip users were using PrintTo too.  Baffling.  Another search led, directly or indirectly, to a FineThatFile webpage where I was able to download printto.exe as part of a zip file containing other stuff.  I unzipped it and ran "printto /?" in the folder where printto.exe was unzipped to.  Turns out it was a biopdf.com product after all.  The syntax was simply "printto filetoprint printername" -- using the default printer if printername was not specified.

So, alright.  Bullzip was already my default printer, so I would be test-printing those PDFs to some temporary folder with a simple command:  printto filetoprint.  There didn't seem to be an option to specify an output folder on the command line.  Apparently I would have to do that in Bullzip.  It took some tinkering, but eventually it came together.  It didn't look like printto.exe was eager to print JPGs, but that was alright; I didn't need that now.  Right now, I was just doing PDFs.  I did get it to print designated PDFs to a designated output folder from the command line without pausing, except in case of overwrite; I did want to be notified about that.  Printto.exe had to be present in the folder where the command or batch file was running, I assumed, but that was manageable.  When it got to my bad PDF, printto.exe gave a command-line error:  "ERROR:  Invalid file name specified."  I had forgotten to put that file's name into quotes.  (Unlike the others, that name had a space in it.)  I added quotation marks and tried again.  This time, when it got to the bad PDF, it gave me the error (above), "There was an error opening this document."  When I clicked OK, my little test batch file continued to print the next file in line.  So it looked like this was going to work.

Regrouping, then, the situation was as follows:  I had set up Bullzip to print PDFs to a specified folder called Bullzip Output, without pausing for any dialogs except error messages and overwrites.  I had downloaded printto.exe, and it was now sitting in the folder where I had also saved a file, created in Notepad, called Printer.bat.  Printer.bat contained commands of this nature:

printto "D:\Folder Name\File to Test Number 1.pdf"

Printer.bat contained one line like that for each of the PDF files I wanted to test.  What was supposed to happen next was that I was supposed to be able to double-click on Printer.bat, or type "Printer.bat" on the command line, and it would try to print the PDFs I was testing.  It would put the resulting PDFs (that is, the Bullzip printouts of the PDF files being tested) into the Bullzip Output folder.  Unless it encountered corrupt files or potential overwrites, it would work -- slowly -- through the list of PDFs that I wanted it to test.  I hadn't seen an option to steer the error messages to a log instead of showing them onscreen.  A log would have been better:  the batch file wouldn't sit idle, waiting half the night for me to wake up and fix a problem.  And maybe Bullzip or some other PDF printer offered that.  I just hadn't seen it.  It would be something to look into next time.  Hopefully Printer.bat would not encounter many corrupt PDFs.

I decided to run Printer.bat from the command line, so that I could watch what was going on.  One problem emerged almost immediately:  after Bullzip created a PDF, Acrobat would open up, even though I had checked the Bullzip option that said, basically, do not open the document after creation.  So, fine, the document would not open, but Acrobat would.  It would just sit there with a blank page, and that was fine, except printto.exe would not proceed with the next file to be processed until I killed Acrobat.  I wondered if things would work differently if I designated a different PDF default reader.  To test that, I right-clicked on a PDF file at random and went into Open With > Choose Default Program > Always use the selected program to open this kind of file > Browse.  I browsed to FoxitReader.exe (which may not have been its original name) and selected it.  I double-clicked on a random PDF to make sure that it would now open in Foxit rather than in Acrobat.  When I tried running Printer.bat again, I got a rapid series of error messages.  The gist of these messages was, "No application is associated with the specified file for this operation."  There were no files in the Bullzip Output folder.  Operation failed.  Now what?

I guessed that I was getting those error messages, not because Foxit was not registered as the default PDF reader at this point, but because something about its status as a portable rather than an installed program was confusing printto.exe.  I was surmising, in other words, that printto.exe needed a PDF reader to be installed.  This suggested that Acrobat was opening after each printing of a PDF, not because of some failure in Bullzip, but because printto.exe needed that.  So then could I perhaps insert a batch file command that would kill Acrobat after printto.exe gratuitously started it up?  Or could I install some other (non-portable) PDF reader that would respond differently than Acrobat had done?  Or would it perhaps help, somehow, if I left Acrobat open to another PDF file before running Printer.bat?

Trying that last possibility, I restored Acrobat as the default PDF reader, opened a PDF in it, and tried Printer.bat again.  This time, Printer.bat took off like a shot.  It processed a couple dozen PDFs almost instantly.  Then it slowed way down, but it seemed this was only because Bullzip was printing the PDFs much more slowly than printto.exe was printing them.  Evidently having a PDF already open in Acrobat was the solution.  Don't ask me why.

Well, now that we had worked out the terms of engagement, printto.exe and Bullzip seemed to be poised to execute the balance of their little pas de deux with grace.  Every few seconds, another PDF would be printed into the output folder.  Ah, but then the overwrite warnings began popping up.  I didn't have time to rename one existing PDF, so as to make room for its brother, before another duplicate warning would interfere with the manual renaming process.  I could have let them go until the end, but I was afraid there might be a lot of overwrite warnings, and the computer would crash or I would get corrupted results.  This was a pretty clumsy operation in the end.  It did seem that it would have been advisable to detect duplicte filenames before starting, and to assign duplicates a temporary or visibly alternate filename for this process.

But anyway, when this was done, I had 147 items in the output folder.  There had been no error messages.  Sadly, Printer.bat contained 148 lines.  Somewhere, we had a laggard.  I took a stab at finding it.  Failed.  I guessed I had allowed something to get overwritten, but my approach was way too sloppy to figure out which test output PDF got wiped.  I decided that I probably already knew it was a good PDF, since I'd gotten no error message while printing.  So that was the end of this test.

Windows 7 Cannot Find Acrobat.exe

I was working in Windows 7.  I had installed Adobe Acrobat 9 Pro.  In Windows Explorer, I selected two PDFs, right-clicked, and chose the option to "Combine supported files in Acrobat."  I got an error message:

Windows cannot find 'Acrobat.exe'.  Make sure you typed the name correctly, and then try again.

I clicked OK to get rid of the dialog.  I noticed that I got this error only if Acrobat was not currently running.  If I had Acrobat open, I would not get the error; instead, I would get the expected Combine Supported Files dialog, and I would be able to go ahead and combine the PDFs.

Of course, I didn't want to have to open Acrobat in order to combine files, although doing so would give me the alternative option of combining the files from within Acrobat, instead of starting from Windows Explorer.  In Acrobat 9, the menu picks for that approach were File > Create PDF > Merge Files into a Single PDF.  And that approach did have the advantage, in at least some Acrobat installations, of not crashing Acrobat (or worse) when I would be trying to merge a large number of PDFs.

I wanted to recover ordinary functionality, so that I could right-click a selected group of PDFs in Windows Explorer and merge them using the "Combine supported files" option.  A search led to a thread that suggested adjusting Windows so that it would open PDFs in a slightly different way.  The instructions there were for Windows XP and Acrobat 6.0.  They suggested adding a certain command-line switch (a/k/a option, parameter, or flag) when Acrobat (or Adobe Reader) would open files.  A search led to an Adobe page that listed six switches:  /n (to start a new instance of Acrobat), /s (to suppress the splash screen), /o (to suppress the open-file dialog box), /h (to start Acrobat minimized), /p (to start Acrobat and open the Print dialog), and /t (to start Acrobat and print a specified file).  (One source seemed to indicate that there might be quite a few other switches as well, controlling such things as the document page that would open and the zoom factor.)

The suggestion that I had found was to add the /n switch to the command that opened Acrobat.  That suggestion seemed to have something in common with the discovery (above) that the Combine right-click option would work when Acrobat was already open.   The problem was that Windows 7 no longer made it possible for users to add switches as they could in Windows XP.  The Tools > Folder Options > File Types tab was no longer available in Windows Explorer.  It would have been possible to run Acrobat by adding the /n switch to the properties of a shortcut, but that didn't seem relevant for this Combine Supported Files project.  A better possibility was to use the Run with Arguments option in FileMenu Tools, but it would require a couple of steps every time, assuming I could get it to work.

I just wanted to restore, in Windows 7, the old ability to specify command-line switches for programs like Acrobat.  Some utilities seemed to offer that possibility.  A closer look at Types suggested that it wasn't right for the job, but it seemed that NirSoft's FileTypesMan might be.  FileTypesMan turned out to be a portable:  I just double-clicked on its .exe and it ran without any need for installation.  I did a Ctrl-F to search repeatedly for PDF file types.  I right-clicked on the line for the PDF extension and got a good number of choices.  A somewhat similar list of options dropped down when I clicked on the menu bar's Edit pick.  It looked like I would need to use the "Open file type in RegEdit" option.  That opened up the Windows 7 registry editor and took me directly to what looked like an appropriate place for Acrobat.

But now what?  I wasn't sure what to do there, so I ran a search.  It led to a few hints, but nothing clear.  I decided to search the registry, to see if I could find the location of the "Combine supported files in Acrobat" option.  A Ctrl-F for that phrase turned up nothing.  Nirsoft's ShellMenuView didn't indicate where that option came from either.

When I double-clicked on the .pdf file type in PC Magazine's old ContextEdit utility, it took me to an Adobe Acrobat Document entry.  On closer examination, I saw that this was actually the second of two such entries.  The first one seemed to indicate that the default program for such documents was Adobe Reader, not Acrobat.  Was that why Acrobat was acting funny -- had Reader screwed up my right-click context menu action?  I wasn't sure when Reader had joined the party.  I hadn't consciously intended to install it.  But now that I thought of it, I guessed that this was why the icons for my PDFs had changed slightly.

So, OK, in Windows Explorer, I right-clicked on a random PDF and went into Open With > Choose Default Program.  Reader was highlighted.  I highlighted Acrobat instead, made sure the checkbox at the bottom was checked ("Always use the selected program to open this kind of file"), and exited.  I selected two PDFs and tried the right-click Combine option.  No joy.  I wasn't sure whether a reboot would make a difference, but I rebooted just in case and tried again.  Still no go.  But, bizarrely, Reader was still highlighted in the Open With dialog.  I didn't need Adobe Reader, so I went into Control Panel > Programs and Features and uninstalled it.  I did the Open With thing again, and now Reader was gone.  I highlighted Acrobat once more in the Open With dialog -- and, yes, back in Windows Explorer, my PDF file icons returned to their old familiar Acrobat form.

I tried Combine Supported Files again, but I still got the error.  I started to go into Acrobat, with the intention of running its Help > Repair Acrobat Installation option.  But for some reason, the Windows Installer started up before Acrobat ran.  I guessed that the departure of Reader had left a gap, and now Acrobat was going to reconfigure itself to take up the slack.  After it was done, it called for another reboot.  I tried Combine Supported Files with two PDFs, but still got the error.  Apparently Reader wasn't the cause of the problem, or at least Reader's removal wasn't the cure.

Another change that I had noticed recently:  when Acrobat was updating, I commonly got errors referring to Error 1310, involving C:\Config.msi.  That had not happened previously.  I did not know whether this was related to Reader, or to the Combine Supported Files error.

Anyway, I went back into ContextEdit, to that second Adobe Acrobat Document entry.  I double-clicked on its Open option.  This opened a command line edit dialog.  The command line was the same as the one that people in that thread (above) had been revising.  Following their advice, I changed the command line so that it looked like this:

"C:\Program Files (x86)\Adobe\Acrobat 9.0\Acrobat\Acrobat.exe" /n "%1"

This just involved inserting that /n before the "%1" variable.  In the dialog's Menu Text box, I added "Open in New Acrobat Session," and then exited.  Sadly, no such option appeared in my right-click menu.  I rebooted, but that made no difference.  It seemed that ContextEdit must still be thinking in terms of the Windows 98 registry.  I went back in and removed that /n switch from its dialog box.

In case Acrobat hadn't fully repaired itself, I now went into its Help menu and ran a repair.  After another reboot, I tried Combine Supported Files again.  I still got the error.  I uninstalled Acrobat (via Control Panel > Programs and Features), rebooted, and reinstalled it.  (Note that Acrobat may have to be deactivated via Acrobat's Help menu before uninstallation, so as to avoid a hassle when activating after reinstallation.)  When it was reinstalled, there was no Combine Supported Files option.  I rebooted.  Still no such option.  It developed that I had made an error during the installation:  it was OK if the custom option to install the Create Adobe PDF was installed fully (white) or without some or all of its subfeatures (grey), but it could not be completely noninstalled (red X).  The red X would mean that the Combine option would not be available.  It occurrred to me that another possible way to fix the problem, short of completely uninstalling and reinstalling Acrobat, would have been to turn off that particular Create Adobe PDF option, reboot, and then turn it back on.

Uninstalling and reinstalling turned out to be the solution, at least with Reader out of the picture and with the other tinkering described above.  With the Create Adobe PDF option installed, the Combine option was there, without requiring a reboot.  And when I used it, it worked without an error.

How to Print a Long Webpage or Image File

I took this question to the Adobe Acrobat Windows forum. It drew a couple of responses, but no real answer. Here was the problem. Acrobat gives you the option of printing a webpage to PDF. Usually, it works just fine: you print the webpage, Acrobat breaks it up into a bunch of 8.5 x 11 sheets (if it's a long webpage), and you have a PDF document containing a reasonably good representation of the webpage. Sometimes, unfortunately, it does not work that way. Instead of printing the entire webpage to PDF, Acrobat prints just the first and last pages, or maybe just the first page. I think the reason must have to do with the HTML coding of the webpage. Whatever: point is, you can't PDF the webpage. This happens for some long image files too. For instance, I thought of using the ScreenGrab extension in Firefox to save the irritating long webpage to JPG or PNG format, and then using an image editor (e.g., the highly recommended freeware IrfanView) to print the PNG to PDF. But this didn't work either: I still got the same outcome. Likewise if I first saved the webpage to different forms of HTML files on my local drive. Eventually, though, I came to a simple solution. Instead of trying to print to 8.5 x 11-inch paper, save the long webpage to a PNG, and then set Acrobat to print to a sheet that is 92 x 92 inches. There are many webpages that are still too long for that, but it's not a bad size. If you need to convert that outcome to 8.5 x 11, then maybe you can print the 92" PDF to an 8.5 x 11 PDF size. In my experiments so far, this approach gives me fonts that look pretty much normal, viewed at a page width display setting. They are good enough to OCR in Acrobat.