Hartwork Blog

Until recently, page margins in LaTeX had more control over me than I had over them. I already heard that package geometry could be of use here, but quick hacks seemed more fun than going through the docs of that package.

I had a closer look now and geometry turned out to be much more convenient than I expected in the end.

The code that I experimented with can be reduced to this snippet:

%% Demo by Sebastian Pipping <sebastian@pipping.org>
%% Released to the public domain
\documentclass[a4paper]{article}
\usepackage[hmargin=2cm,vmargin=1cm]{geometry}
\begin{document}
\rule{\textwidth}{\textheight}
\end{document}

So I am abusing \rule here to draw a filled rectangle that spans the whole content area. I am asking for horizontal margins of 2cm width and vertical ones of 1cm height.

Strangely, the output I received did not match my expectations. Look how much bigger the left margin is than the right one.

It turns out that indentation of the first line of a paragraph is at work here. The insertion of \noindent solved that problem.

This release features build system changes and fixes. Please check the change log for details. This release is both source- and binary compatible.

Download:
https://sourceforge.net/projects/uriparser/files/Sources/0.7.6/

Change log:
http://uriparser.git.sourceforge.net/git/gitweb.cgi?p=uriparser/uriparser;a=blob;f=ChangeLog

LWN.net brought my attention to this: Microsoft confirms UEFI fears, locks down ARM devices

Dass man RFID-Chips in Kleidung einbauen kann, war mir klar, aber dass es wirklich gemacht wird, hat mich dann doch ziemlich vom Hocker geworfen:

FoeBuD enttarnt RFID-Chips in Kleidung

Very interesting attack/issue, check it out.

Intro

I recently got bitten by the hyphenation of LaTeX and learned a few things in return. I noticed that two other LaTeX users in my environment were running into similar hyphenation trouble or were about to start a bigger text document without sufficient knowledge of hyphenation. So I would like to summarize a few essentials here.

Why care about hyphenation?

By default, LaTeX does hyphenation for you. If it gets things wrong the reader will attribute that error to you, not to LaTeX. Sometimes bad or wrong hyphenation even affects the layout of the page and makes text go into the margin area. Maybe a reader attributes that to LaTeX; however, it still doesn’t look very professional.

Why hyphenation needs to be correct from the very start (and for every word)

Imagine you work on a document 20+ pages long. You pass a snapshot of the document to someone to read, get some corrections back, start integrating corrections. If you modify content on page 10 there is a chance that hyphenations on pages later in the document change: it may happen the the set of hyphenated words before and after do not share a single word. What that means is that as long as you work on the document, places of hyphenation change. That means errors that no reviewer had a chance to see before. Ouch.

Common pitfalls with hyphenation

Words containing hyphens, e.g “well-understood”

If you use words that contain hyphens, e.g “well-understood”, LaTeX breaks these at the very place of the present hyphens only. It may even write the end into the margin area of the page, if it exceeds a certain length. The following example illustrates the issue.

Let’s look at a document made of the text

Hyphenation is well-understood. Maybe not.

six times. Without manual work you get output as shown in the following excerpt. Focus on the right border.

\documentclass{article}
\usepackage{hyphenat}
\begin{document}
Hyphenation is well\hyp{}understood. Maybe not.
[..]
\end{document}

This time the output respects the size of the text area. Again, focus on the right border.

Mixing languages, e.g. English and German

If you mix two or more languages within the same document you have to tell LaTeX which words belong to which language. (Once you get used to it, it’s bearable; there isn’t much of a way around it.) Otherwise you end up with things like German hyphenation applied to English words, i.e. wrong hyphenation.
In a case where the main text is written in language A it makes sense to mark selected words as language B.
To mark English words in an otherwise German document I use a simple self-made command \ENG:

\usepackage{babel}
[..]
\newcommand{\ENG}[1]{\foreignlanguage{english}{#1}}

An example use would be

UnionFS ist ein \ENG{Stackabe file system}.

Mapping that to other combinations is left to the reader

Debugging tool \showhyphens

The command \showhyphens can be used to query all the places where LaTeX dares to hyphenate a word (or compound word). The output however does not go into the actual document but to the shell and the log file. If you feed the following document to LaTeX

\documentclass{article}
\usepackage{hyphenat}
\begin{document}
\showhyphens{well-defined}
\showhyphens{well\hyp{}defined}
Dummy
\end{document}

you can spot this output on the shell:

...
[] \OT1/cmr/m/n/10 well-defined
...
[] \OT1/cmr/m/n/10 well-de-fined
...

In case you have a script extracting all used words from a LaTeX document for another view on spelling mistakes you could combine that with the results of \showhyphens to a make a single list with all words and their hyphenation for review.

Futher reading and sources

• Wikibook LaTeX -> LaTeX/Formatting -> Hyphenation
• Multilingual LaTeX with the Babel Package
• \showhyphens #1
• \showhyphens #2

I recently discovered that the sound of rain makes a great ambient sound for working. Unlike with real music I do not have to switch artists or albums every few hours and there are no foreign words injected into my thinking process so it’s easier for me to focus.

Finding a good recording of rain can be a bit difficult. What I ended up using is these two CC-BY-licensed samples in loop at the same time:

• rain.wav by mystiscool
• rain_on_car_roof.flac by 833-45

The Freesound website makes that kind of playback possible without even involving sound editors. All you need is two tabs (or even one) kept open in a browser.

I recently  noticed 200MB waste from /usr/share/locale from languages that I never configured. So I turned to the gentoo-user mailing list and got

• a detailed reply by Mike Edenfield (quoted below)
• a hint on app-admin/localepurge by walt/w41ter

As I liked the explanation by Mike, I asked for permission to quote it as CC-BY-SA/3.0 here, which he confirmed:

Different packages include different levels of support for filtering their installed localization messages, typically one of “install everything”, “install what’s requested”, or “whats a locale?”

The reason you mostly have files under LC_MESSAGES is because that’s 99% of what is needed to localize a package. The files in there are string resource packages, translations of the strings used by the program, which are picked up by the localization library (gettext) automatically based on your locale settings. (coreutils installs file into LC_TIME for locales with date/time formatting requirements; I don’t think I’ve ever seen any other locale files.)

The standard way to inform a package which languages you want is to set your LINGUAS variable in /etc/make.conf to the locale name(s) you want installed (without the charset specifier). LINGUAS works like any other portage expansion variables: for those packages that support it, you get a set of USE-flag-like language keywords set on build. (LINGUAS is the well-known environment variable used by most autotools-based packages to select languages, but portage provides support above and beyond that.)

Unfortunately, proper locale support is spotty — mostly due to upstream maintainers being too lazy to properly add it to their builds. Instead, the package will install every message file it has available all the time.

You can safely delete any folders from /usr/share/locale for locales that you don’t have installed, since the normal locale support in glibc will never ask for them. But they’ll just get put back next time you upgrade the package.

–Mike

The latest system update pulled GDM 3.2.x into my ~amd64 Gentoo system. While GDM 2.x felt just right, GDM 3.x is not my thing at all. To bring back GDM 2.x I added these masks

>=gnome-base/gdm-3
>=gnome-base/gnome-control-center-3
>=gnome-base/libgnomekbd-3
>=net-wireless/gnome-bluetooth-3
>=gnome-base/gnome-settings-daemon-3

and re-emerged the latest 2.x versions of these packages. Works.

I ran into error 24 today: “Too many open files”. Ooops.

The solution that I eventually went for is not among the first Google hits for “increase limit open files” so I felt like blogging about it here.

There are two functions getrlimit and setrlimit that allow querying and modifying certain resource limits, e.g. the maximum number of open files for a single process (and they do have a shared, detailed man page). For each of the resource limit types, there is a hard and a soft limit: the soft limit, is the one you run into. In my case the soft is 1024, the hard one is 4096. The cool things is: Any non-root process can increase the soft limit to the hard one. That’s my rescue.

Simplified, this is what I do:

#include <sys/time.h>
#include <sys/resource.h>

...

struct rlimit open_file_limit;

/* Query current soft/hard value */
getrlimit(RLIMIT_NOFILE, &open_file_limit);

/* Set soft limit to hard limit */
open_file_limit.rlim_cur = open_file_limit.rlim_max;
setrlimit(RLIMIT_NOFILE, &open_file_limit);

Works like a charm.