Installing Acrobat Reader DC

Like many other users, I have had a considerable amount of trouble installing Acrobat Reader DC on my laptop, now running Windows 10. The issue does not seem to arise with a fresh Windows 10 install; however, my laptop was upgraded from 8.1 to 10, and in general has gone through a lot of software installations.

The symptoms: upon running the Acrobat Reader DC Installer from Adobe’s page, you get an error saying that a “newer version is already installed.” If you Google this error, you will see that it is a very common occurrence for Reader and other Adobe software. For some users, running the Adobe Cleaner Tools (all versions) does the trick. However, this did not work for me. Here’s what did.

First, instead of using the aforelinked installer tool,  I downloaded the installer from Adobe’s Enterprise page. The difference is that the “normal” tool is just a small utility that downloads the actual Reader software, and then installs it; the “enterprise” tool actually contains the Reader software, and works like a regular off-line installer.

Second, it turns out that even the Enterprise installer errors out. However, the error message is more useful. Googling for “Error 1722” sent me to this Adobe support page, which finally provided me with the solution. TL;DR version: you need to install newer Visual C++ Redistributable binaries from Microsoft, from this page. Follow the instructions on the Adobe support page though: they are quite detailed.

I suspect that the “newer version” error reported by the standard installer is bogus. That is, in the background, the issue is the same–an incorrect library version is tripping up the installer. If so, this is an example of an insanely bad error message that will send users down a rabbit hole, trying to hunt down old Reader software versions in the murky corners of the Windows Registry, not to mention Windows’ obscure directory structure. In any case, all’s well that ends well. I hope this will save people some grief.

My Samsung 7 Slate

I might as well ‘fess up: after much pondering, I broke my multi-year allegiance to all things Apple, and bought myself a Samsung 7 Slate. Yep. A Windows 7-based tablet PC. You can read more about it in this in-depth review at Tom’s Hardware, or this more consumer-oriented, and overall quite negative assessment at Engadget.

Let me say, first of all, that I’m definitely not leaving the Mac platform! First of all, my office machine is a trusty 2008-vintage iMac that I have no intention of replacing, except with a newer iMac. Second, I still use my 2008 Macbook Pro, though rarely. Third, my wife uses a first-generation iPad and a 2010 Macbook Pro, and is very happy with both.

So why this, er, countercyclical (OK, contrarian) decision? Quite simply, I wanted a tablet that could double as a real, no-compromise, LaTeX-capable computer. Apple, sadly, does not make one. Yes, I know about the Modbook, basically a standard Macbook (Pro) retrofitted with a digitizer and tablet frame; it’s about twice as expensive, once you factor in the price of the Mac laptop, and weighs about three times as much as the Samsung 7 Slate — S7S henceforth.

I plan to post extensively on my experience with this machine. I certainly had to figure out ways to deal with the basic fact that Windows 7 and, more importantly, Windows apps (like Mac apps) are simply not designed for touch input at all (with a few notable exceptions). Let me start with a few thoughts, in no particular order.

Windows 8

The S7S is essentially identical to the developer machine that Microsoft handed out at the Build conference, where Windows 8 was first demoed in public. Microsoft has stated that any machine running Windows 7 today will be able to run Windows 8 as well, and the S7S is a very recent machine to boot. But, in addition, the S7S is one of the tablets that Windows 8, and Windows 8 apps, are being developed on! Thus, this machine will likely run Windows 8 well. Indeed, you can run the Windows 8 Developer Preview right now. Which brings me to my second observation…

The Tablet PC Review forum

If you own the S7S, you just have to follow the Samsung forum at Tablet PC Review. It is an amazing resource. Want to find out how to install and run Windows 8 on the S7S? Looking for cases that fit the still-new 11.6″ tablet form factor? Having issues with Samsung’s Easy (ha!) Software Manager? Want to check for potential issues before installing the latest BIOS update? It’s all there. People are extremely nice and helpful. The signal-to-noise ratio is very high.

Why not buy an iPad / Android tablet?

Because I don’t want to carry around two devices, when one will do just fine — actually, great, not fine. We already own an iPad, though I can’t really say I can use it: my wife and kids totally own it. That’s OK 🙂 The point is, getting another tablet for media consumption purposes and web browsing seems like a luxury I can’t justify. Plus, it’s inconvenient: if you have and use two devices, you most likely will want to sync them (photos, music, etc.). This is no problem if you are at home and have WiFi, but we travel quite a bit. Until we have pervasive broadband access via the cellular network, at reasonable prices, worldwide, syncing will be a pain (think iTunes). If your laptop is also your tablet, there’s no syncing involved.

Why not a Macbook Air?

This is a tough one. As far as portability is concerned, the MBA is every bit as good as the S7S, or any tablet for that matter. It is a (small) laptop, which means that you can work comfortably while holding it, well, in your lap. In this respect, it is definitely superior to a tablet, even if the tablet comes with a case stand or dock, and a keyboard, like the S7S does.

But the point is that you really don’t want a keyboard when you are reading a book using the Kindle app (or similar), and arguably even when you’re casually surfing the Web, or triaging email. By the way, the S7S comes with a beta of the Swype keyboard for Windows. It is simply amazing; I use it on my Android phone, but it is even better on a tablet. Hint: make sure you read the advanced tips on the Swype Web site.

The S7S provides many of the form-factor advantages of an iPad or Android tablet, but is a full-featured, relatively powerful PC (Core i5 processor, 128GB of SSD storage, 4GB of RAM, a decent Intel graphics processor). You can get real work done on this machine, no matter what your line of business.

By the way, this thing is fast. Try surfing the Web on the S7S and on an iPad side by side. There’s no comparison. And, yes, of course Flash runs just fine on the S7S, and while I loathe it, certain sites (fancy restaurants being the offenders I discovered more recently) just insist on using it.

Not for everyone

Lastly, I should be very clear about this: the S7S is not for everyone. If you want a pure consumption device, get an iPad. It lasts much longer on a charge, and it is designed for touch from the ground up. If you don’t care about the tablet form factor at all, get a laptop. Most Windows apps require adaptability and, above all, patience if you are using your fingers instead of a mouse or touchpad.

Watch this space for tips, tricks, and adventures in the world of Windows tablets!

LaTeXTools: updated SumatraPDF setup information

Just a quick heads-up: I just added detailed instructions in the README file on how to set up inverse search with SumatraPDF on Windows.

If you were using SumatraPDF with another text editor that supported inverse search, you probably didn’t have any trouble reconfiguring inverse search to work with Sublime Text. However, it turns out that a fresh install of SumatraPDF does not show a GUI for the inverse-search command, until you actually open a PDF file that has actual synchronization information in an accompanying .synctex.gz file.

The revised README file shows how to proceed. Basically, if you already have a PDF file with an attendant .synctex.gz file, open the PDF in SumatraPDF, and you’ll see the GUI when you select Settings|Options. Otherwise, you can either compile any latex document with pdflatex and sync information (i.e. compile with pdflatex -synctex=1 ), or else configure SumatraPDF from the command line. See the README file for details. As usual, you can read that file at Github (you may need to scroll down a bit).

I’m sorry things are not more straightforward. Good luck!

TeXlive is a go (plus, a better README)

Last night I pushed the changes I made to the LaTeX.sublime-build to GitHub. You may say that TeXlive is now “officially supported” on Windows, in addition to MikTeX. As I noted earlier, I fully expected Sublime Text 2 to eventually fix its handling of non-normalized file paths and different drive letter cases. As usual, Jon has come through: as of version 2120, everything works just fine!

Also, I finally got around to beefing up the README file for the plugin. It’s in Markdown format, so it’s human-readable, but you can see it in all its HTML-formatted glory if you just go to the LaTeXTools page at Github and scroll down. I hope this will encourage more people to give Sublime Text 2 and LaTeXTools a whirl.

One final note on the choice of TeXlive vs. MikTeX. As I see it, the trade-off is this: MikTeX’s management tools, and its DVI previewer Yap, are Windows-native, whereas TeXlive’s management tools feel like ports of Unix tools, which they are (even the GUI ones). On the other hand, TeXlive has full support for spaces in file names and paths, which MikTeX currently lacks. As a further advantage, TeXlive has a working version of latexmk, which means that it is very easy to change the tex engine from pdflatex to, say, xelatex: just change the appropriate line in LaTeX.sublime-build. Finally, TeXlive on Windows is essentially the same as, and package-wise in sync with, MacTeX on OSX, which may be convenient if you’re a platform hopper like me.

TeXlive on Windows: forward and inverse search

Yesterday’s post ended with a conjecture: TeXlive should be able to generate correct sync info on Windows. Today I decided to test that conjecture; I installed TeXlive 2011, which turned out to be surprisingly simple, with one caveat: the MiKTeX installer adds its binary directory to the system path, and if you run the TeXlive installer in user mode you obviously can’t change that. To fix this, you need to add the TeXlive binary path manually, before the MikTeX path. However, if you plan on using Sublime Text 2, you don’t even need to do that, and you can use both distros  side-by-side: read on.

Supporting TeXlive/Windows in the LaTeXTools plugin turns out to be trivial. You only need to modify the LaTeX.sublime-build file! Chalk that up to Sublime Text 2’s build system design, which my plugin’s makePDF command takes advantage of.

I’ll push the changes (commented out, so the default is still MikTeX) soon; for the time being, if you want to experiment, with TeXLive, modify the “windows” section of the file LaTeX.sublime-build so that the “cmd” option looks exactly the same as it does in the “osx” (i.e. Mac) section. This is not surprising: after all, the underlying TeXlive distro is the same. Furthermore, you can use the “path” option to specify the TeXlive binary directory, so you don’t even have to mess with environment variables (make sure to add “;$PATH” after the TeXlive path).

The result is that Sublime Text 2 now works happily with TeXlive! So, does synchronization (forward and inverse search) work, even with file names that have spaces? Yes! Well, I should be precise.

First, the .synctex.gz file is correctly generated. Recall that MikTeX 2009 does not generate it if the file name contains spaces, so this is an improvement.

Second, forward search works beautifully [an aside: Ctrl-Shift-J is now bound to a folding operation, so I need to change the keyboard shortcut. Use Ctrl-B for the time being: if no compilation is required, the net effect is the same, i.e. you jump to the right position in the PDF file. Again, I’ll push a fix soon].

Third, backward search (from the PDF to the tex file) sort of works. The problem is that the most recent version of synctex “extends” file paths so that

C:\Users\YourName\Documents\test.tex

becomes

C:\Users\YourName\Documents\.\test.tex

(the same is true on the Mac, btw). Clearly, both paths point to the same file. However, when you double-click in the PDF file, SumatraPDF invokes Sublime Text 2 (or whatever editor you designate) with the second, longer version of the the file name. Now, most likely, you already have the file test.tex open in a tab in Sublime Text 2; however, if you opened that file yourself (e.g. from an Explorer window, or from the Open dialog), the path name associated with the file is the first, “normal-looking” one. As a result, Sublime Text 2 opens a second tab, with the same actual file, but a different path name (the “extended” one). You can check for yourself by hovering on the two tabs: the path names are indeed different, as described above. On the positive side though, the cursor is positioned correctly, corresponding to the point in the PDF file where you double-clicked in SumatraPDF.

Now, this is not a Sublime Text problem: the exact same behavior results if you use TeXnicCenter. Furthermore, no such problem exists with Sublime Text 2 on the Mac (with the Skim previewer). Finally, neither Sublime Text 2 nor the underlying Mac OS do anything special to make sure that files of the form

/Users/YourName/Documents/test.tex

and

/Users/YourName/Documents/./test.tex

are treated as one and the same: you can try this for yourself by opening a file using the two above specifications of the file name from the Terminal.

Bottom line: it is SumatraPDF’s fault. Or, more precisely: on the Mac, the Skim app is smart enough to send a “normal” file name to your text editor when you perform an inverse search. SumatraPDF is not as smart.

Presumably, the problem does not arise if you use MikTeX because it uses a version of synctex that does not use “extended” path names—but that version, unfortunately, does not handle spaces in file names either!

The bottom line is that it’s a bit of a catch-22: either you use MikTeX, but avoid spaces in file names; or, you use TeXlive, but are forced to open files in Sublime Text 2 by using their “extended” pathname. This is easy to do: open your tex file normally, then build it, then double-click in SumatraPDF; when the second tab pops up in Sublime Text 2, close the first, and from then on work in the new  tab. Of course, you can also open the PDF file first, then double-click, and work in the tab that Sublime Text 2 opens for you. Ugly, but functional.

I will report the issue on the SumatraPDF bug tracker. Hopefully it will get fixed in a later version.

MikTeX synchronization and spaces in file names

In three words: it doesn’t work (does “doesn’t” count as 1 or 2 words though?).

A bit more detail. After a long hiatus, I fired up a Parallels 7 virtual machine and decided to use SumatraPDF and Sublime Text 2 under Win7 for my day’s work (which is, as usual, LaTeX-heavy). However, synchronization (i.e. jumping from the LaTeX source to the PDF output and conversely) kept failing with the particular file I was working on . This was both surprising and worrisome: I have been developing the LaTeXTools plugin for ST2 under Mac OSX lately, but my focus has been on cross-platform features; I assumed that the sync infrastructure, which is very platform-specific, was in a stable state by now. Still, one can never rule out new bugs with updates to both ST2 and SumatraPDF; this is the reason why I occasionally take a trip to the Win7 side, as I did today.

Ends up the problem is not with ST2 or with the LaTeXTools plugin: the sync infrastructure is still solid on Win7. Rather, the failure of synchronization is a well-known issue that affects the (otherwise excellent) MikTeX distribution. Like many other TeX distros, MikTeX relies on a library called “synctex” to generate the synchronization information (the “.synctex.gz” files that get created whenever you pass the “-synctex=1” option to pdflatex). Unfortunately, if the LaTeX source file name (more precisely, its full path name) contains a space, the generated sync information is incorrect.

I double-checked this two ways: first, if there are no spaces in the path name, ST2+SumatraPDF work just fine; second, if there is a space in the file name, then synchronization also fails in TeXworks. Google says it fails with WinEdt, TeXmaker and other editors as well. Incidentally, the TeXworks test exonerates SumatraPDF, because TeXworks and SumatraPDF use different libraries to render PDF files (although they both use synctex for backward and forward searches).

Now, in principle, the problem may be with the synctex library itself. However, on Mac OSX, synchronization works fine with file names that include spaces. The synctex code is largely cross-platform, so the problem must be in the way MikTeX incorporates or adapts it on Windows. One way to test this would be to run the TeXlive distribution on Windows; it, too, includes synctex, and the standard Mac TeX distribution, aptly named MacTeX, is essentially just TeXlive compiled under OSX, with some additional apps. Since MacTeX generates correct sync info with or without spaces in file names, I suspect that TeXlive under Windows does, too. If anyone has experience with this, please let me know in the Comments.

Bottom line: this is a Windows- and MikTeX-specific, back-end problem that unfortunately I cannot fix. I hope a future release of MikTeX will resolve the issue, because I do occasionally use spaces in file names. In the meantime, the fix is to, well, stick to file and directory names that have no spaces in them.

SumatraPDF 1.6 vs. 1.4

A quick post for Windows users of the LaTeX plugin. I just updated Sumatra PDF from version 1.4 to version 1.6. Unfortunately, forward search stopped working 😦 I checked, and this (mis)behavior has been present since version 1.5, which I had skipped. (Inverse search works fine, BTW).

I reported the issue to the developers; in the meantime, please use version 1.4, which works fine. You can get it from here (equivalently, navigate to the Download section of the SumatraPDF, and look for the link at the bottom of the page).

Edited (6/9/2011 at 11:45p): ends up there was a bug in my DDE code that Sumatra 1.4 forgave, but later versions did not. If you pull the most recent version from GitHub, you’ll be fine with Sumatra 1.6 as well. I am not sure I fully understand why the fix was needed, but I checked my code against this and figured out what I was doing wrong.

Trying out Windows Live Writer

I’m spending the week-end on the Win7 side of my MBP’s hard disk, so I decided I should try the Windows Live suite, including Mail (neat), Photo Gallery (serviceable) and Writer, which I am using to write this post.

Inserting links is straightforward enough. I wonder about code though:

def pyfunc(x):

y = x+2

return y*x

Well, yeah, it works, but it is ugly. However, it turns out that Windows Live Writer has a neat extension system. Moreover, a kind soul wrote a plugin specifically tailored for use with WordPress. In particular, the plugin inserts the right “shortcode,’’ so you get WordPress.com’s built-in code rendering. Here’s what you get:

def pyfunc(x):
  y = x+2
  return y*x

For other blogging platforms, GeSHi is also available. However, it does not seem to work as well with WordPress.com blogs.

(Re)installing Windows 7 on a MacBook Pro early 2008

My Windows 7 RC (release candidate) expired earlier this month, so I decided to install the actual release bits on my MacBook Pro (Early 2008, or MBP4,1 for those in the know). I had previously bought and installed Vista (full license) on my MBP, so I bought an upgrade license for Windows 7 Ultimate at an OK academic price and set about installing it.

One complication, which is actually documented, albeit not in the most transparent terms, is that you need to have a prior version of Windows installed on your computer in order to complete the installation and activation of a Win7 upgrade, even if you are planning to do a "clean install"; it is not enough to have the older version DVD available. Well, turns out that’s not strictly true from a technical point of view, but I wanted to play by the rules. Of course, when I installed Win7RC, I wiped out the existing Vista install; but, luckily, before doing so, I made a copy of the Vista partition using the excellent WinClone. So, the very first step (step 0, if you will) was to restore the Vista partition. That required updating WinClone, as the version I had did not run under Snow Leopard. Incidentally, for a few brief minutes I was worried that the updated version might use a different file format for their images, but luckily that was not the case.

I then started the Win7 installation process. I use rEFIt, so upon rebooting I was greeted with not one, not two, but five different boot options: Mac OS X, Vista, and, on the installation DVD, the “EFI64 monitor” (I think), Windows 7, and a “Legacy” OS. Not knowing better, I simply rebooted and held down the C key, thereby forcing my MBP to boot from DVD.

The first part of the installation process was uneventful. I was then asked to reboot, and here I encountered the first stumbling block. At this stage, the installation DVD is still required—it certainly was not ejected, and in fact it was accessed several times in subsequent steps of the installation process. However, what was not clear was whether I should reboot from disk or from DVD. I reasoned that the most user-friendly solution would be to reboot from DVD: after all, the user still has the media in the DVD reader, which means that most PCs will attempt to boot from DVD first; thus, it makes sense for the installation program on the DVD to detect that stage two of the process has been reached, and proceed as required.

But, of course, the Win7 installation program is not quite so smart. Upon rebooting, it cheerfully offered to start the process from scratch. Time to reboot! Henceforth, I figured that what I was supposed to do was boot from disk. I am not sure whether this is a Mac-only thing; perhaps there are ways for the installation software to determine the boot order via BIOS, and the Mac does not provide a good enough emulation of the PC BIOS for that to work. Certainly, Mac OS X system updates and OS upgrades seem to be able to force rebooting from a particular volume. Be that as it may, it was a bit of a stumbling block for me.

Anyway, after a few other restarts, I was greeted with the Win7 first-run dialogs, entered by license key, created a user, etc.. Then I was good to go; it was time to log in and install the Bootcamp drivers. However, being extremely risk- and virus-averse, I first downloaded and installed the Microsoft Security Essentials.

Installing Bootcamp is also a two-step maneuver. You must first use the Snow Leopard DVD to install Bootcamp 3.0, then reboot, then use Apple Software Update to install, you guessed it, the Bootcamp 3.1 update! And, yes, reboot once again. After many years on the Mac (and Linux before that), one forgets how rebooting is a normal part of life as a Windows user. One would have thought that the ubermodern Windows 7 would have dispensed with the need to reboot by now—heck, under Linux, you can even update the kernel without rebooting—but that’s not the case.

Anyway, I now have a fully licensed copy of Windows 7 Ultimate on my MBP. Oh, and it’s 64 bits, so Windows finally sees all 4GB of RAM. I’ll report on my experiences, in particular as regards battery life. I thought the additional RAM would decrease disk thrashing and hence extend battery life, but that does not seem to be the case so far.

Sublime Text LaTeX plugin: Beamer Slides

I have updated my LaTeX plugin for the Sublime Text editor with features that make life a bit easier when working on Beamer presentations.