Ray Woodcock's Latest: Adobe

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.

For several years, I had been using Blogger.com to host this blog. Blogger had a nasty habit of screwing up my formatting: it would insert spaces where I didn't want them, and would invent and repeat various codes that I did not want in my HTML. That is, even if things did look fine and function reasonably in the Compose view in Blogger, they could be a complete wreck in the Edit HTML view -- and in the final outcome. Blogger had often messed up my final posts, so that they would look different from how they had looked while I was editing them. Sometimes, things went to bizarre extremes. Here's an example:



<div style="text-align: center;">



Conclusion







<div style="text-align: left;">







<div style="display: inline ! important; text-align: center;">




<div style="display: inline ! important;">


</div>
</div>
</div>
</div>

Now, what was that all about? In normal view, it was just one word, "Conclusion," surrounded by a bunch of blank lines -- which, incidentally, I had not inserted; the webpage just took it upon itself to introduce all that junk into my *final* product. (Note that, even here, the foregoing example is surrounded by extra spaces that I did not insert.)

I posted a question about this in a Google help forum. One response pointed me toward a Blogger post on this Blogger problem. That post offered these tips:

Before creating your post, arrange your paragraphs using a word processor like MS Word, then paste it into Blogger.
Minimize changes (e.g., repositioning paragraphs) in the editor.
Preview before publishing to view initial output and put changes on it.

I felt that these were imperfect tips. On the first one, I had discovered that Word would add its own HTML codes when I pasted material directly into Blogger. I found it was better to copy the Word text into Notepad, which would tend to strip away that stuff, and then move it from Notepad to Blogger (or just do the editing in Notepad). The third one was not very helpful to me either, as the attempt to fix problems observed in Preview would sometimes just make things worse.

It seemed to me that the second of those three tips was the heart of the matter. Blogger's internal editor was just not up to the task of managing text editing. What I needed to do, I believed, was to try using some kind of HTML editing program, get my text all set up there, and then copy it over and post it without any further changes. I say an HTML editor, rather than a word processor, because I would want to insert links and make sure that the formatting was right in HTML terms.

About.com, which I had found to be a good general-purpose source of information, had a list of the 10 Best Windows WYSIWYG Editors. The ones topping the list, from Adobe and Microsoft, cost hundreds of dollars. In the past, I had used Microsoft FrontPage, which was part of Microsoft Office up through 2003, but seemed to have vanished thereafter. I was still running Office 2003, so I could have gone with that. I was trying to get away from relying on Microsoft software, however, and in any event About.com also listed four freeware HTML editors at the bottom of its Top 10 list. Of those four, SeaMonkey ranked highest, and had versions for Linux and Mac as well as Linux. It was also described as being appropriate for HTML newcomers. I was not that, but I was certainly not the alternative in their descriptions, i.e., a professional web designer. About.com also ranked SeaMonkey third in its list of Linux-specific HTML editors. On another list, though, SeaMonkey ranked only 17th, well behind Amaya (for professional web developers), which was ninth on the About.com list. Between the two, as I looked at their webpages, I felt that SeaMonkey was probably more the direction I wanted to go.

Before pursuing that choice further, I recalled that there was another possibility, namely, to use a blogging tool. Wikipedia offered a list of the blogging software used by what it described as the Top 20 blogs. Just two programs, Moveable Type and WordPress, dominated that list. The latter could be confusing: it was also the name of a blog hosting website, like Blogger, through which bloggers could easily use the WordPress blogging tool to prepare their own blogs. That last observation raised the question of why someone would use Blogger instead of WordPress to host a blog. The answer, in my case, was that I had started out with Blogger, I had a lot of stuff on there, and anyway I already had a WordPress blog, with a different orientation, and found it convenient to host this other blog somewhere else. I was already familiar with the WordPress website, though, and a brief glance at features suggested that it might be more approachable than Moveable Type. That said, a search for blogging tools introduced me to a number of factoids: that Twitter, among others, was considered a micro-blogging tool; that there was a free version of CoffeeCup, which had appeared on that About.com list; that PC Magazine gave me a comparison of blogging tools, and that Xanga -- the only one they rated with four stars (out of five) -- was free and seemed to offer good features, and that it just turned out to be another place to host a blog.

So now, I felt, my choice was down to the free tools (not blog hosting sites) offered by SeaMonkey, WordPress, and CoffeeCup. SeaMonkey came out sounding pretty good in Smashing Magazine's list, whereas one of the comments posted in response to their list said that CoffeeCup had the very problem I was experiencing, of having a lot of superfluous code generation. Another comment said positive things about SeaMonkey. As some of the foregoing comments suggest, WordPress seemed to be for web designers above my ability or interest level -- intended, among other things, for a direct link between the blogging tool and the blog host website. That seemed like a potentially more complex arrangement than I could justify at present.

I took one last look around and decided not to explore htmlArea's long list of WYSIWYG HTML editors. Instead, for purposes of my dual-boot and VMware-based machines, I downloaded the Windows version and installed the Ubuntu version via Synaptic. The latter was then available at Applications > Internet > SeaMonkey. I opened the program and selected File > New > Composer Page. (I wasn't able to install the Windows version right away because I had other programs running in my virtual machine, but I suspected the functionality was largely the same.) I went over to the webpage I was composing in Blogger and then realized that I wasn't sure whether I should copy my HTML or my normal text from Blogger into SeaMonkey. I went back to SeaMonkey and clicked the "HTML Tags" tab at the bottom. And -- whoa -- the program vanished. Not good! I went back to Applications > Internet > SeaMonkey and started it again. This time, I clicked on the HTML Source tab at the bottom of the screen. No problem: it opened a nearly empty HTML editing page.

I went over to Blogger, went into its HTML view, copied everything, and pasted it into that SeaMonkey page, between the two "body" codes. I clicked on the Normal tab and there it was, in more or less normal layout. I went back to the HTML Source tab and saw that it had not actually removed any of those excess codes. I cut and pasted the code out of there, put it into gedit (similar to Notepad), did a bunch of Find and Replace operations to remove the excess codes, and then pasted it back into the HTML Source tab. That removed all of my paragraph breaks, so I had to reinsert them manually. The location of paragraph breaks was easier to spot in the HTML Source tab. But then, when I flipped to the Normal view and back, the paragraph breaks that I had inserted by just using an extra Enter keystroke were gone. So I had to either do my paragraph breaks in Normal view or else use <p codes to break my paragraphs in HTML Source view. Also, lines were wrapped in a weird way. I didn't know how to remove unwanted line breaks in gedit or OpenOffice Writer, so I saved the HTML code as a text file, went into my virtual machine, and used Microsoft Word to replace ^p with a spacebar space, and then brought it back into the HTML Source tab -- but then it just reverted to how it was before. Also, the print in SeaMonkey was a bit small for good proofreading, but I couldn't figure out how to make it larger.

When I was done tinkering, I flipped back and forth between the Normal and HTML Source tabs a couple of times. It looked good; it did not stop looking good; and it did not seem to be inserting any unwanted new codes. Now, I needed to get all that nice HTML from SeaMonkey back into my Blogger webpage. SeaMonkey had a Publish Page option, wher it appeared that I could have just sent the result directly to Blogger. I wasn't sure how to do that, and anyway I wanted to look at the result in Blogger before publishing it. So I switched into HTML Source view, in SeaMonkey, and copied everything into the Edit HTML tab in Blogger (having deleted whatever was there before). I switched to Blogger's Compose view. This did not look too good. I clicked on Blogger's Preview button. It was a train wreck, mostly because lines were ending all over the place -- after one word, two words, three words, whatever. I looked again at the Edit HTML view in Blogger. The weird line endings and extra blank lines were there too. But they definitely weren't in the HTML in SeaMonkey.

I tried a different approach. I wiped out everything in Blogger and copied over again from SeaMonkey. This time, though, I copied from SeaMonkey's Normal view (i.e., not HTML Source) to Blogger's Compose view (i.e., not Edit HTML), and then I clicked on Blogger's Preview button. This was much better. Now lines were wrapping in sensible places. The problem now seemed to be that I was just getting line breaks (i.e., just the start of a new line) instead of paragraph breaks (i.e., with a blank line between paragraphs). So, OK, in SeaMonkey's HTML Source view, I tried doing a global replace (Ctrl-F) of with . I looked at the result in SeaMonkey's Normal view. Now most of my paragraph breaks were extra wide. Again, I copied this Normal view into Blogger's Compose view. But that wasn't it, either. Eventually I figured out that what I needed was to forget about and just use , so that took another global replacement in SeaMonkey, followed by manual adjustment of a lot of paragraph breaks. Later, I found SeaMonkey's Edit > Preferences > Composer option that said, "Return in a paragraph always creates a new paragraph." That was not checked, but I checked it. It would take another project to determine whether that would help.

The next problem was that, in Blogger's Preview, the first two paragraphs were in a larger typeface. They looked fine everywhere else; but in Preview they were wrong. I took a look in Blogger's Edit HTML view. Sure enough, Blogger had inserted this before the first word of my code: . Don't ask me why. I deleted it and took another look in Preview. That fixed that.

Now I had a few remaining random line breaks. The problem appeared to be that, somehow, some of my ordinary spacebar spaces had gotten replaced with nonbreaking space codes (i.e., " "). In SeaMonkey's HTML Source view, I did a temporary global replace of the space-nonbreaking space combination (i.e., " " ") to @@@. (Likewise when the two appeared in reverse order.) Then I did a search for all remaining occurrences of nonbreaking spaces, and replaced most of them with regular spaces. Not the ones at the starts or ends of lines, though: I had noticed that SeaMonkey did not search correctly for items wrapping over its own line breaks. So if a space occurred at the end of one line and a &38nbsp; occurred at the start of the next, SeaMonkey's find-and-replace would not find and replace. But making these decisions manually, for the hundreds of occurrences that may appear in a long post, was beyond my patience at this point. So I just made it global. Finally, I replaced the @@@ with the space-nonbreaking space combination again, and then took a look in SeaMonkey's Normal view. It looked good.

I belatedly realized that I had not yet tried SeaMonkey's Preview view, so I tried that now. It still looked good. I copied it from Normal view over to Blogger's Compose view again. I had to go into Blogger's Edit HTML view again to remove that funky starting font code again.

After hours of futzing around, it was done, and I posted it. Even with the aid of SeaMonkey, it was a hassle. SeaMonkey was definitely better than Blogger; my changes were making an improvement each time, and it was not undoing things that I had just fixed, and I did wind up with a satisfactory result. There seemed nonetheless to be some glitches in the way SeaMonkey worked, and I thought that I might want to try a different HTML editor next time. The foregoing review suggested that WordPress might be the weapon of choice, unless something new came along in the meantime.

Ray Woodcock's Latest

Pages

Saturday, January 14, 2012

Windows 7 Cannot Find Acrobat.exe

Monday, June 14, 2010

Making a Post Look Right on Blogger

Support This Blog

Total Pageviews

Archives