36. PDF and annotation/editing under linux -- no solutions

Update: There are newer posts here and here.


Galley proofs of scientific articles are typically provided in the form of pdf files with ambiguous passages and editorial suggestions marked. You are then expected to add comments to the pdf indicating whether you agree to changes and/or clarifications. Well, good luck doing that.

It does appear that Acrobat Reader (9.4.x under linux, 10.1.1 under windows) does not support annotation/commenting anymore. See picture for security settings:

I fooled around with pdf2ps + ps2pdf, pdftk allow AllFeatures etc. No luck. Still no annotation in acroread.

PDFedit didn't help much. It looks like an advanced piece of software, but it offers no obvious way of making post-it type comments. The best approximation is adding text to the margins, but it's not what I set out to do.

Sadly, using wine + pdf x-change viewer (http://appdb.winehq.org/objectManager.php?sClass=application&iId=5549) is at the time of writing the best solution. You can download the free version here: http://www.tracker-software.com/product/pdf-xchange-viewer (there's also a 'pro' version)

It really is a straightforward piece of software, and does the trick, so no complaints there. However, it is very unfortunate that such a central piece of functionality is unavailable under linux.

Also, it does seem that acrobat reader is intentionally crippled -- from what I understand there is no obvious reason why commenting isn't allowed (i.e. not the fault of the authors of the pdf) other than because Adobe wants you to shill out money for their 'Pro' version (...interesting how FOSS normally doesn't market itself by adding X or Pro to the name...)

35. Fixing: gnome alt+f2 broken, returns command not found -- debian testing current bug, description and solution

22/12/2011
An explanation and solution is here: http://forums.linuxmint.com/viewtopic.php?f=198&t=67502&p=510197#p512994

SOLUTION
--------------
My version of the solution above is a follows:

1. First, locate the file to edit

locate utils.js | grep misc

which returns

/usr/share/gnome-shell/js/misc/util.js

2. Next, confirm that argc is present (this is what's causing the problems)

cat /usr/share/gnome-shell/js/misc/util.js | grep argc

which returns

        let [success, argc, argv] = GLib.shell_parse_argv(command_line);
    let success, argc, argv;
        [success, argc, argv] = GLib.shell_parse_argv(command_line);

There are more elegant ways of doing this, but this is how I roll.

3. Edit /usr/share/gnome-shell/js/misc/util.js as root

sudo vim /usr/share/gnome-shell/js/misc/util.js (you can of course use gedit, nano, emacs etc.)

search for argc and remove all instances of of it, so that
[success, argc, argv] turns into to  [success, argv]
etc.

Once you've removed all argc, save and then hit alt+f2 in gnome, type r and enter to restart the shell. Then hit alt+f2 and type e.g. gedit to test it

It now works!

Reading through bug reports it seems it won't be fixed in Debian -- instead we'll have to wait until gnome 3.2 rolls out. Or just follow the instructions above.

-------------------------------
THE OLD POST
20/12/2011

(Current version of gnome-shell is 3.0.2-8+b1)

Hitting alt+f2 to start e.g. gedit or another program used to be straightforward.

During the past week it hasn't worked properly though -- instead the entry of any command has returned a 'command not found'. If you instead of simply typing in gedit type in /usr/bin/gedit, chances are the computer will experience an odd sort of freeze -- the top bar will be unresponsive, the black entry box will remain, the screen will be shaded, but gedit won't open. You will, however, be able to continue using your computer, but it'll be a dark experience.

Symptomatic descriptions of the bug and experiences are available here:
https://bugzilla.redhat.com/show_bug.cgi?id=719675
https://bugs.launchpad.net/ubuntu/+source/gnome-shell/+bug/816762

32. Apt-pinning in Debian -- simple example

---------------------------------------------------------
Summary:
* create an /etc/apt/preferences files
* add the repos to /etc/apt/sources.list
* put a hold on packages if downgraded
---------------------------------------------------------


I'm not an expert at this. However, I managed to get apt-pinning to work using this approach. I wish I had a better grasp of how .d directories work, but I don't, which is why a monolithic /etc/apt/preferences files is used

Anyway, apt-pinning is an interesting approach to having a system in which some packages are pulled from stable, some from testing and some from unstable. For example, if the Evolution version in stable is missing what you consider critical functionality, and a better version is present in the testing repos, you can install the testing version of Evolution, while still running a mainly stable version of debian. In other words, apt-pinning allows you to pull single packages from other debian releases.

You need to add the repos to your /etc/apt/sources.list
e.g.

deb ftp://ftp.au.debian.org/debian/ testing main contrib non-free
deb ftp://ftp.au.debian.org/debian/ stable main contrib non-free
deb ftp://ftp.au.debian.org/debian/ unstable main contrib non-free

You also need to create a file called /etc/apt/preferences
e.g.

Package: *
Pin: release a=testing
Pin-Priority: 990

Package: *
Pin: release a=unstable
Pin-Priority: -10

Package: *
Pin: release a=stable
Pin-Priority: -10

The example preferences file prioritises testing over unstable and stable. Default apt behaviour is to use the highest version and revision of each package is there are several alternatives i.e. without /etc/apt/preferences you will end up with the unstable/sid release. The Pin-Priority values are a science onto themselves.

Here's what
 man apt_preferences
 says:


P > 1000
           causes a version to be installed even if this constitutes a downgrade of the package

       990 < P <=1000
           causes a version to be installed even if it does not come from the target release, unless the installed version is more recent

       500 < P <=990
           causes a version to be installed unless there is a version available belonging to the target release or the installed version is more recent

       100 < P <=500
           causes a version to be installed unless there is a version available belonging to some other distribution or the installed version is more recent

       0 < P <=100
           causes a version to be installed only if there is no installed version of the package

       P < 0
           prevents the version from being installed

I think negative values for the unwanted releases is a good place to start, or you may start automatically pulling over packages that depend on the one package which you want.

A way to see if it's working is to (for the package Evolution)
apt-cache showpkg evolution

Package: evolution
Versions: 
3.0.3-3+b1 (/var/lib/apt/lists/ftp.au.debian.org_debian_dists_unstable_main_binary-amd64_Packages)
..
3.0.3-3 (/var/lib/apt/lists/ftp.au.debian.org_debian_dists_testing_main_binary-amd64_Packages)
..
2.30.3-5 (/var/lib/apt/lists/ftp.au.debian.org_debian_dists_stable_main_binary-amd64_Packages)
..

..

Provides: 
3.0.3-3+b1 - mail-reader imap-client 
3.0.3-3 - mail-reader imap-client 
2.30.3-5 - mail-reader imap-client 


Basically, it returns the different versions in the different release repos.

I've already described how to put a hold on a package so that it won't be upgraded, but here it is again (using the mpich2 package as an example):

sudo su
echo "mpich2 hold" | dpkg --set-selections