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.

Major LaTeXTools news

Two major news items for the new year.

First, LaTeXTools now has a new co-maintainer: Ian Bacher. If you have reported issues on GitHub in recent months, you might have seen his handle, @ig0774. Ian has contributed terrific code, and has helped several users solve issues (and uncover/fix bugs!)

I am thrilled to have Ian on board. While I plan to stay involved (see the next item), it is a fact that my day job does not leave me a lot of free time to develop. In addition, Ian has been “cooking” a couple of major new features (take a look at his recent pull requests), one of which addresses a long-standing pain point for Linux users… I won’t say more for now! So, Ian brings both more man-hours and more (and better!) ideas to the table.

Second news item: I am porting LaTeXTools to the Atom text editor. The repository is here. I don’t want to rant about the long-term viability of Sublime Text. However, it is a fact that updates have been few and far between, and the developer has gone incommunicado. For commercial software, this is concerning. I saw this happen to my former favorite text editor, TextMate. I hope that development will pick up again, or alternatively that Sublime Text will go open-source, and thus stay viable in the long term. However, I think it’s good to look for alternatives.

Atom is still under development. Yes, it is slower than Sublime Text. However, it does have advantages. It is open source, but backed by a large organization (GitHub). Development is very active. There is a vibrant package (i.e. plugin) ecosystem. Oh, and since it’s based on Chromium, you get niceties such as decent scrolling and touch support for free.

Go to the LaTeXTools for Atom page and take a look. As you will see, a lot of functionality is already in place, including forward/inverse search, error parsing, ref/cite completion, multi-file support, and more.

LaTeXTools updates

Well, it’s been a while…

Unfortunately, I’ve been extremely busy at work lately, so LaTeXTools development has had to take a back seat. However, a number of contributors have submitted patches. Over the past couple of weeks, I’ve been able to incorporate some of the most useful and significant ones. Among them:

• Fill helper: think of this as reference/citation insertion, but for included files, graphics, and even LaTeX packages.
• LaTeX compilation options: the “traditional” builder supports these in two ways. One is to add a %!TEX option = line at the top of the file (or root file in a multi-file document). The other is to use the LaTeXTools.sublime-settings file: specify your options using the options setting in the Builder Settings section.
• Support for the LaTeX-cwl package. I don’t really use it, but it’s been requested often.
• Jump to included files, ability to hide the panel upon a successful build, and improvements to the delete temp files feature (including the ability to specify which files to delete, and which directories to leave alone).

Please refer to the README file for acknowledgements of the above contributions. My role has only been that of testing, integrating and sometimes documenting the new features. The credit for the actual code goes to the wonderful LaTeXTools community.

WordPress experiments

Hot on the heels of the latest LaTeXTools announcement, here is a useless post. This should show up automatically on both Google+ and Facebook. Hope it works!

LaTeXTools: a new, customizable build system

Edited 3/13/14: updated name of configuration file. Also, this code is now in the master branch! More details in a later post.

One of the requests I receive most frequently, especially from LaTeX power user, is the ability to customize the build process. In principle, this is possible. However, it requires modifying the LaTeX.sublime-build file. This is inconvenient for a number of reasons. First, the file must be copied to the User directory, or it will be clobbered by subsequent updates of the plugin. Second, the file also contains internal settings that cannot and must not be customized. Third, the Sublime Text build system is really designed to launch a single, command-line program, or else a “make”-like utility. Indeed, LaTeXTools uses it to invoke either texify or latexmk, which are essentially TeX-specific “make” utilities. In principle, one can write one’s own custom build script and use that in lieu of the default build command; however, most users will not want to do that. Also, one is somewhat limited by the fact that external scripts do not “know” about Sublime Text, and hence cannot meaningfully communicate with it.

Enter the new “master builder” system; you will find it in the mbuilder branch on GitHub. Here’s what’s new:

1. All user settings are now in the LaTeXTools.sublime-settings file. This includes the path to tex & friends, and all the settings discussed below. With the new code, LaTeX.sublime-build becomes effectively just an internal file that users need not and, indeed, must not modify. NOTE: if you want to play with the mbuilder branch, make sure to delete any stray LaTeX.sublime-build files you may have in the User directory. Also, as for any Sublime Text settings file, LaTeXTools.sublime-settings should be placed in User directory and customized there.
2. The build system is now split into two components. One is the “master builder,” which takes care of handling the Cmd/Ctrl-B command and manages the (delicate) threading infrastructure required to run external commands such as pdflatex or latexmk; this is the code in the file makePDF.py. The other is the actual “builder” or “build engine,”  which examines the tex root file, decides how to process it, and tells the master builder which external commands to run. Indeed, there are currently two build engines (called “traditional” and “simple”), with a third (“script”) coming soon: you will find the code in the builders directory.
3. The “traditional” build engine does exactly what the current code in the master branch does: it calls latexmk or texify (and also allows for the selection of a tex engine). The “simple” build engine, on the other hand, requires no external tools, and can be useful, for instance, if you don’t want to install latexmk on OS X or Linux. It runs pdflatex, then bibtex if needed, then pdflatex again, as needed, until references / citations are either resolved or just missing. Thus, the “simple” engine is an example of a (simple!) “make” tool for tex & friends that runs entirely in Python, within Sublime Text. I hope one day to write (or, better yet, receive as a user contribution…) an actual, robust replacement for texify / latexmk. For now, the “simple” engine serves as an example to aspiring contributors… Finally, the “script” engine, when ready, will simply invoke a user-specified external command.
4. All parameters of the build engines are configurable in LaTeXTools.sublime-settings. Again, you can forget about LaTeX.build-settings. In particular, the “builder” option selects your preferred build engine. When the “script” engine is ready, this is where you will specify which external script to use, and whether to set any environment variables, for instance.
5. Techie note: the beauty of this system is that build engines can access the Sublime Text API, as well as the whole Python library, but they do not need to know anything about threading. Instead, builders use the powerful Python mechanism of generator functions. Each time a build engine wants to run an external command (pdflatex etc.), it uses the Python yield command to send it to the master builder. The master builder runs the external command, captures its output, and returns it to the build engine.

The code is still beta quality; I’m running it daily myself, but I’m interested in feedback from adventurous users. When I’m reasonably confident that things are working, I’ll merge it into the master branch.

LaTeXTools: Sublime Text 3 support is now live!

I have just merged support for Sublime Text 3 into the main (master) branch. So, this is no longer in development: you will be getting it automatically via Package Control (update manually if necessary), or you can get it from GitHub.

As I explained in a previous post, the same code will work on Sublime Text 2 and Sublime Text 3. Hence, there will be feature parity on both versions of our beloved editor.

I have done my best to test extensively on various combinations of ST versions and platforms, but let me know if you see something strange.

Also, in case something is seriously broken, I have created an “st2” branch on GitHub hosting the code right before today’s merge. Consider this an emergency fallback only; the new code on the master branch should work fine.

LaTeXTools: two major new features

I’m in a bit of a rush, but I wanted to share the news as soon as possible. Over the last couple of days, I pushed one major update to the LaTeXtools plugin, and started a new branch that provides initial support for (yes!) the newly-beta Sublime Text 3 (ST3 for short).

The major update incorporates a revamped completion system for citations and references. Most of the new code comes from contributions by users westacular and jlegewie; I just did some cleaning up / harmonization, plus I incorporated other fixes and improvements to the previous code base. You just have to take a look at the README to see what this is about. The highlight feature is autotrigger: as soon as you type, e.g., “\ref{“, the quick panel pops up with a list of all labels in your file; and if you type “\cite{“, you get a nicely formatted and searchable display of your bibliography. (If you don’t like this behavior, you can turn it off). Also, you can finally insert multiple citations in one “\cite{}” command: the quick panel is autotriggered as soon as you enter “,” after an existing citation key, inside the braces. Again, go read the README!

Support for ST3 is based on the excellent work by phyllisstein. I couldn’t quite pull his code in as-is due to some divergence, and also (frankly) because I thought I’d learn more about the required changes by doing the work myself. Also, I wanted the same code to work for both ST2 and ST3. However, I cheated and copied profusely. First, phyllisstein sketched the essentials of the port in an issue report, and elaborated in  an email to me. So, I broadly knew what I had to do, and what to watch out for (great subject matter for a follow-up post!). Second, I kept his code open in my browser, and consulted it when I got stuck. In fact, I cut-and-pasted it whenever I could. Bottom line: thank you phyllisstein!

Remember: the st3 branch is still somewhat experimental. But, go ahead and try it! It is based on the most recent master branch, and hence includes all the ref/cite goodies above, plus all recent fixes and improvements.

To install it, get the .zip file from Github, unzip it in your ST3 package directory, restart ST3 if you have it running, and enjoy! Of course, you need to configure your previewer (SumatraPDF or Skim–evince on Linux should work out of the box, but I can’t test myself) to launch ST3, not ST2, for inverse search. Check the path to ST3 on your system.

I’m back!

Just a quick status update: after an embarrassingly long time, I’m finally able to resume work on the LaTeXTools plugin! I’ve already committed a few changes, as those running Package Control will have noticed. If not, head over to github and take a look.

Here is a list of things I’d like to work on next:

• Continue fixing the log parser (as in: handle more and more special cases…). This is a never-ending quest, I’m afraid, and not fun at all. Still, I’ll try. Keep sending me those log parsing error reports.
• Improve the cite completion panel. I have a great contribution from a user, which adds much needed flexibility. However, I need some quality time to merge it and make sure that nothing breaks on the side. But, it’s coming.
• In the same vein, I do plan to add support for biblatex cite commands.
• Power users have asked me to make it easier to customize the latex build process (e.g., choose a different engine). I have a couple of ideas in this regard (one radical, one less so), and will implement them in due course.
• Finally, I would like to prepare for the migration to Sublime Text 3. I’d like to have a solid code base for ST2 before I make the leap, but we’ll see.

Thanks, as always, for your support!

LaTeXTools: New Keybindings!

Heads-up: the keybindings for the LaTeXTools plugin have changed. Make sure to read the README file for details: go to https://github.com/SublimeText/LaTeXTools and scroll down (or click the “Read More” link near the project description).

Why change things? When I started working on this plugin, my objective was to emulate the functionality of the LaTeX bundle for TextMate. In particular, I tried to use the same keyboard shortcuts. However, this slowly led to an accumulation of problems. One was that, as I added features to the plugin, it became harder and harder to assign them to shortcuts that were not already used by Sublime Text 2 itself. The other problem is actually due to ST2’s greatest feature: it’s a cross-platform editor, and the plugin must also work equally well on Windows and Mac, with full Linux support also coming soon (yes!). However, different OS’s have slightly different conventions and expectations about what certain keys do. Bottom line: things were getting unmanageable.

Enter the new keyboard shortcut scheme. It’s actually very simple:

1. The build command is still bound to ctrl-b on Windows and Linux, and cmd-b on OS X. For the time being, the Goto Anything functionality is also still bound to ctrl-r / cmd-r.
2. All other plugin commands use ctrl-l or cmd-l followed by another key or key combination. That’s “ell” for LaTeX.

Example: to do a forward search (i.e. jump to the point int he PDF file corresponding to the current cursor position) on Windows, enter Ctrl-l followed by j. This is abbreviated as ctrl-l,j (the same convention used by Sublime Text). On OS X, this is cmd-l,j. In fact, from now on, I shall write C-l to mean either ctrl-l or cmd-l, depending on the platform.

I have tried to use mostly C-l plus a single keystroke, with reasonable mnemonics. For instance: “j” for jump to PDF, “c” for LaTeX command based on the current word, etc. Wrapping commands use the C- key twice: so, wrap in bold is C-l,C-b, etc. Reference and cite completion uses C-l,Ctrl-space (yes, even on OS X, that’s Command-ell, Control-space), but you can also use C-l,x (for cross-reference). Finally, to toggle the focus from/to the PDF upon compilation, there is a three-key sequence: C-l,t,f. I’ll try to reserve these for toggles and other less frequently used stuff.

Now, on ST2, the C-l shortcut is bound to “Extend selection to line”. That’s reassigned to C-l,C-l. The nice thing is that no other standard ST2 keyboard shortcut is affected.

As an additional benefit, these bindings are consistent with the “nice” (or “compact”) on-screen keyboard in Windows 8, which only has a Ctrl key (no Windows key, no Alt key).

Enjoy!

How to recover deleted photos and other files for free

If you have never accidentally deleted a file, or accidentally formatted your camera’s memory card, don’t read this post 🙂 Otherwise, here’s something I just found out, trying to help a friend whose SD card had mysteriously formatted itself (don’t ask), thereby nuking about 400 photos.

There are, of course, several commercial file recovery utilities for both Windows and Mac. I’m sure they can generally do a good job. In this case, I experimented with a few trial versions, which typically show you what’s recoverable but do not actually retrieve the files. Unfortunately, I had only very limited success with commercial offerings: very few pictures appeared to be recoverable, no matter which software I tried. That was what I expected, actually; for this reason, when I asked my friend to leave her supposedly dead or dying SD card with me, I made it clear that, short of miracles, her pictures were probably gone for good.

Well, I found a miracle-worker, and its name is PhotoRec. Actually, PhotoRec is part of a package called TestDisk, which does tons more than just recover deleted files, but requires more user intervention. If all you need to do is recover photos, PhotoRec is what you want.

This, ladies and gentlemen, is Free Software at its finest. Yes, it’s free-as-in-beer, as well as free-as-in-libre. Most of all, it’s quality software that does what it’s supposed to, and does it well. Once you point PhotoRec to the drive (hopefully still) containing your photos, and you give it some additional information (see below), you just need to wait while it works its magic. In my case, it was able to recover not just all the recent photos my friend was worried about, but also a lot of pictures that had been deleted up to two years ago. (Friendly advice: don’t rely on your camera’s “Erase All” function to get rid of embarassing pictures!) Last but not least, it’s multiplatform: it runs on Windows, Mac, Linux, and even other platforms. Win!

The downside of PhotoRec is that, well, it is Free Software at its finest 🙂 Let’s just say that user friendliness was not a key design requirement. PhotoRec is distributed as a zip file that you simply extract wherever you want (even your desktop, if you are lazy). Then, on Windows, you run the photorec_win.exe executable (I haven’t tried it on the Mac). However, if you are expecting a nice friendly Windows dialog, you will be disappointed: PhotoRec runs in the Windows console, and uses an 80s style menu interface. You use the arrow keys to highlight different options, and (generally speaking) Enter to select one of them and advance to the next screen, where new options are presented, until PhotoRec is ready to go to work.

But this makes the process sound harder than it really is. Here’s a very quick summary (refer to the instruction on the PhotoRec site). First of all, you must create a directory on your PC’s hard disk where you will store the recovered pictures. You need to do this before running PhotoRec. Second, once you run the PhotoRec executable, you will see the Windows UAC prompt, because PhotoRec must run as Administrator in order to perform low-level access to your drive. Third, PhotoRec needs to know the following (listed in the order the screens appear in the app):

1. Which drive contains (or used to contain…) your pictures. PhotoRec lists your drives, calling them something like /dev/sda (which most likely is your PC’s hard disk), /dev/sdb, etc. However, it also indicates the size and provides a device description. For instance, right now I have a 32GB MicroSDHC card in my Samsung 7 Slate, which appears as a “31 GB / 29 GiB – Generic STORAGE DEVICE”. That’s the kind of entry you should be looking for. In any case, don’t worry: drives are mounted read-only, so you can’t mess up your files!
2. Which partition on that drive should be used. This is usually easy to guess. On an SD card, either there is a single partition, or there is a small one containing “helpful” software from your friendly manufacturer, and a large one for your data. Pick the large one.
3. Which format the selected partition uses. PhotoRec will try to guess, but if you are recovering files from an SD card, it’s almost certainly going to be FAT or maybe NTFS.
4. Whether PhotoRec should look for pictures only in the space marked “free”, or on the “whole” disk. I chose “whole.”
5. Finally, where to save your recovered pictures. Here you have to navigate to a directory (folder) on your PC’s hard disk. Again, you must create this folder before running PhotoRec. Navigate to it, then hit “C” (don’t ask) to select.

At any time in the previous steps, you can hit Ctrl-C to quit—no questions asked, no mess. But, if you make it all the way to the end, just leave PhotoRec alone and it will do its job. Warning: this may take some time, so make sure your PC is plugged in, so it doesn’t go to sleep.

Finally, a disclaimer or two. Your mileage may vary, and indeed I’d be interested to hear your experience. Also, the safest form of data recovery is backing up! That said, PhotoRec performed admirably. This time, I earned my friend’s gratitude. Next time, it could actually save my own skin!