I am always amazed how far one can get by chaining the output of simple programs
to create something bigger. This time, I had to convert the pages of a PDF file
to a single PNG thumbnail image. As I learned in five minutes this is super
convert tool and a
Makefile to hook it
pdftoppm -png $< tmp
convert +append tmp-* -resize x320 -unsharp 0x1 $@
What I do here is calling
pdftoppm to generate numbered PNG files with a
convert reads them, appends them horizontally (denoted by the +
sign), resizes the final image to a height of 320 pixels and filters the output
with an unsharp mask to “recover” some of the lost sharpness.
To make the pages stand out you can also add a black single pixel frame and a
white separation border with
convert $<-*.png -resize x320 -unsharp 0x1 -bordercolor black -border 1x1 -bordercolor white -border 2x2 +append $@
tl;dr: On a stock Ubuntu 16.04. system build your presentation with pdfLaTeX or
LuaTeX and use Okular to display it.
TikZ animations are a great way to illustrate dynamic processes in your Beamer
presentations but are not suited for movies. So far, presenting movies on Linux
has been pretty dull but eventually I figured out what works (and what not).
First of all you, need to include
in your preamble which gives you the
\movie command in order to include a
reference to the movie file and a placeholder text/image/whatever that is
shown as long as the movie is not played:
In most cases, the first frame of the movie would be a good canditate as a
placeholder. To get the first frame you could use ffmpeg:
ffmpeg -i movie.wmv -vframes 1 -f image2 foo.jpg
Now, the first hurdle is to compile the presentation and unfortunately you will
find out that XeTeX does not work with the
multimedia package. So, either
compile with LuaTeX if you want to use system fonts or compile with regular old pdfLaTeX.
To display your presentation you could use Evince but it will display the
animation only in windowed mode, in the presentation mode nothing happens for
me. KDE’s Okular has no such limitation and works fine with a PDF containing a
movie. Note though that the movies are not baked into PDF but linked to. This
means, you must deliver all files side-by-side.
You might have noticed a slight visual change of this site. Well, I just pulled
the trigger and re-wrote this site’s CSS based on milligram in about an
hour. The sole reason for that was that the old CSS was an unmaintable, barely
responsive mess. I am not a CSS expert, so why not leverage one of the countless
minimal CSS frameworks and add a few customizations to get away from that
hip and modern low-contrast look?
With that came a few changes that made this site leaner and cleaner: I removed
the few Font Awesome icons thus avoiding one more stylesheet and loading of
a web font, changed the heading font from Lato to Roboto Condensed and removed the
Unica One font which was used only in the header bar.
All in all I am pretty happy with the change and the fresh look.
For the first time in a long time I felt happy about a piece of software: it’s
meson the build system. I wrote about my
adventures with CMake but in the end I was never really happy with it. Be it its
arcane syntax, intransparent build process or lack of following standards common
in the nix world. I used it but grudgingly because I could not let my colleagues
be burdened with Autotools.
I read about meson about the time it was first announced but did not dare to
dive into it because of lack of maturity and long-term perspective. However,
learning that a lot of GNOME and systemd related software is moving from
Autootools to meson, I changed my mind and read the great manual in order to
convert some of our bigger C projects over from CMake. And what a joy it was!
First the build language: it’s clear, simple and deliberately not
Turing-complete. Unlike what a lot of folks imply when they hear that meson is
written in Python, the language itself is a separate domain specific language.
Many features of this language do not feel like an afterthought but very helpful
to describe build artifacts and build related information. For example string
and list processing such as
foo = ' '.join([bar, 'baz'])
feels a lot more robust than CMake’s
Having a real boolean type reduces the amount of guesswork in situations
with conditionals considerably. Having a Turing-incomplete language with an
object-oriented approach seems verbose, I had the reverse feeling that I was
writing less but more explicit code. A good thing in my opinion.
The best part on Linux is that meson does not try to depart too much from the
./configure && make && make install dance.
meson works exactly
configure except for the fact that it enforces out-of-source builds. In
this step, meson uses
pkgconfig in a first class way to find a library’s
compile and link flags unlike CMake which for years suggested to use the
included modules. In the other direction, meson has first-class support for
pkgconfig file generation, with CMake having you to abuse
and still get it wrong. There other tool-specific modules such as the
module that let you finish your job in a few lines instead of constructing new
build targets with fragile command construction.
The configuration times for me with meson are almost ten times shorter than
CMake but this probably varies from project to project. The build times are
equally long if you opt-in to use CMake with Ninja,
the default build tool of meson. meson’s build output is a bit nicer because it
does not spam the console if there are no warnings or errors during the build.
For now I found only one thing that would have to let me go back to CMake once
in a while: meson requires Python 3.4 and newer. This is not the case on a few
machines I still have to work on, but time will let these phase out too.