Hello, welcome to my blog.
Since months I've been planning to update this site's layout and structure a bit. But you know how that goes: I'll do it next week :)
Anyway, the content should be pretty recent (at the time of this writing at least).
Stefaan
Occationally, I have to convert a PDF file to Postscript (e.g. for subsequent processing with some PostScript utility). In the Linux/command line area, I know two options: pdf2ps and pdftops. I also know that one of the two sucks has some issues and the other is better. But because their names are so close I can't manage to remember which one to take. This post should put an end to that!
[Spoiler alert and a questionable mnemonic: pdftops is da top.]
Here's an update of the post about the size tracking of the Drupal 7 issue queue I made more than a month ago. January has been a pretty fruitful month for Drupal core development: we hit the point were the critical D7 issue queue halved in size. It reached its maximum around 15 October 2009 (code freeze) with 440 critical D7 issues and on Wednesday 27 January 2010, it dropped below 220.
If you want to profile a Python applictation, you can get some basic functionality with the cProfile and pstats modules, as described in the Python Profilers documentation. After some curious experimenting, I discovered that the pstats module provides a handy interactive mode. To my surprising, I didn't found any substantial documentation about this time saver, so let me entertain you with a dump of my findings.
Some notes I made on DrupalCamp Ghent 2009 on 11 and 12 december. Mainly for my own reference, so please don't read any further.
Since May 2009, I'm monitoring the Drupal 7 issue queue sizes. I use a cron job in Python that goes out four times a day to drupal.org to scrape the issue queue sizes mentioned in the "contributor links" block.
The idea is to see if the time series can be used to have some estimate when Drupal 7 will be ready. For a long time, the overall trend was a rising one and simple extrapolation would tell that Drupal 7 would never be ready :)
Since the beginning of December 2009, it seems that the "critical D7 issues" queue is finally in shrinking mode, so I thought the time was right for releasing an overview of my current data. Moreover, there is now a public Drupal 7 issue size tracker with more web-2.0-shininess by Damien Tournoud (with less history however), so I should contribute my data instead of keeping it for myself.
Inkscape and the Gimp are trusty tools in my daily tool box for various vector and bitmap image editing. Being open source applications, they have firm roots in the Linux world, but luckily they are also available for Windows and Mac OS X. No wonder I have them installed on my MacBook too.
On OS X, Inkscape and the Gimp are not completely native applications, but they depend on X11.app. This extra layer makes the user experience unfortunately less streamlined than with native applications. Especially the keyboard interaction of an out of the box setup can be clunky.
In a previous post I listed some options for audio data manipulation (conversion of format, sample rate, bitrate, trimming, etc), with SoX, MPlayer and FFmpeg. The obvious question is now: which one is best?
In my day job, I regularly have to convert/transcode/re-encode audio data from one format to another. Because I typically have to do this in batch jobs, I'm mostly dealing with command line tools (on Linux) like Lame, SoX (Sound eXchange), MPlayer and FFmpeg. Having a cheat sheet of how to invoke them with the desired options has proven to be very useful, so here is mine. Note that I only cover the operations I mostly need, like format conversion, sample rate conversion, conversion to mono and trimming/cropping. If you need more/other functionality, look in the man pages or ask your favorite search engine.
[Update] also see a follow up blog post about an execution time comparison between SoX, FFmpeg and MPlayer.
When using default LaTeX styles, you get a rather small text width. This is for a very good reason: readability. However, when you want to add an image, figure or table, this width can be a bit limiting. If you naively add an image (or table) that is wider than the text width, the image will typically align on the left margin and extend into the right margin, which is not that pretty. Moreover, because you're not using the left margin, it limits the maximum width you can use.