Reduce the File Size of PDF Documents with Preview on OS X

The PDF file format is ubiquitous for good reason, mostly because it allows for perfect preservation of a documents formatting, text, and other elements. However, sometimes PDF can be quite bloated and a file that should be not more than 200KB can suddenly be 1.5MB for no obvious reason. Adobe’s Acrobat X has functions to reduce/optimise the size of a pdf. On OSX you can achieve the same with Preview.

For PDF files that have not been optimized yet, the Preview app in OS X can often reduce the file size considerably by passing it through an export filter.
export-pdf-to-compress-file-size
reduce-file-size-filter-for-pdf-preview

While it works great for text heavy files, it’s not a perfect solution for image-heavy slides. The “Reduce File Size” Quartz filter will indeed drastically shrink the file size of a pdf but the great savings in size come at a price. It will also make the slides look thoroughly awful. This is because the filter achieves its file size reduction by scaling all the images down by at least 50% and to no more than 512 pixels on a side, plus it uses aggressive JPEG compression. So not only will the images suffer from compression artifacts, they will also tend to get that lovely up-scaling blur.

Fortunatenly, anyone can create their own Quartz Filter with the ColorSync Utility shipped with OSX. The following zip file: PDF compression filters contains various files that reduce the file size while trying to minimise the amount of artifcats introduced in the images. It’s nowhere near as aggressive as the default Quartz-Filter.

The ColorSync Utility will by default save your own Quartz Filters in the following directory: /Users/YourName/Library/Filters/.

In order for the Filters to appear in the Save AS/Export menu the *.qfilter files need to be moved into the following directory

/Library/PDF Services/ Notice not in home folder (~/) but system-wide.

Afterwards the filters will appear in the dropdown menu of the export function:
Screenshot 2014-11-28 13.43.34

NFSv4 performance woes on Debian

Over the weekend I took the opportunity to reinstall the OS on my workstation at home. Instead of choosing Debian unstable I decided to go with Debian stable + backports this time. The reason is simply to not deal with package upgrades braking the current system again. Manually fixing my local gitlab installation after a ruby upgrade annoyed the hell out of me and I simply can’t be bothered with manually going through package management and pinning down a working version of ruby and ruby-gems just to keep my current setup working.

When I started to configure system services such as ssh, nfsv4, ftpd etc. I noticed that mounting NFSv4 shares on Debian 7 (Wheezy) was quite slow (around 11 to 15 seconds). Oddly enough, once the NFS share was mounted into my local filesystem I was able to copy files as quickly as usual.

I checked dmesg and /var/log/messages after mounting the NFS share and noticed the following entries:

[bash]
[17603.799651] Key type dns_resolver registered
[17603.804909] NFS: Registering the id_resolver key type
[17603.804918] Key type id_resolver registered
[17603.804918] Key type id_legacy registered
[17618.828292] RPC: AUTH_GSS upcall timed out.
[17618.828292] Please check user daemon is running.
[/bash]

According to the following thread, rpc-svcgssd is responsible for the nfs Kerberos authentication at the server side. I have no intention of using Kerberos at home as the time required for the set-up outweigh the benefits of single-sign-on for just a single user. I can simply set-up the same account with the same credentials on my computers. Therefore kerberos authentication should also be optional at the client side. Well it actually is, but the implementation at the moment is rather tedious. It waits for a timeout that occurs after roughly 15 seconds which introduces the delay when mounting a share.

On Redhat’s bugtracker the following entry was posted: Bug 1001934 – 15 sec timeout when mounting with nfs4:
Marcindulak provided the following workaround to fix the issue until the client is updated

blacklist the rpcsec_gss_krb5 module on the client and reboot or simply unload the kernel module

[bash]
echo "blacklist rpcsec_gss_krb5" > /etc/modprobe.d/blacklist-nfs-gss-krb5.conf
reboot
[/bash]

or instead of rebooting you can simply use rmmod to unload the currently loaded module:
[bash]
rmmod rpcsec_gss_krb5
[/bash]

This should eliminate the delay when mounting NFSv4 shares on Debian.