str_word_count() beispielsweise scheitert an fast allen Punkten, obendrein noch an Bindestrichen, Zahlen … und UTF-8. Man kann daran vorbeieiern, aber der Aufwand lohnt sich einfach nicht.

Bleiben wir pragmatisch, nehmen schlechtes Deutsch seufzend hin und zählen einfach die Leerzeichen, ja?
Nein. Manche Leute haben immer noch die Angewohnheit, hinter einen Punkt zwei Leerzeichen zu setzen, und im Markup tauchen sie selbstverständlich auch auf.

Also nochmal: Gegeben sei ein String …

$string = '<p class="foo bar"> hello world.  two späceß.<br />
bla</p>'

… aus dem wir erst das Markup entfernen:

$text = strip_tags( $string );

… dann die Leerzeichen am Anfang und am Ende:

$text = trim( $text );

Und jetzt entspräche die Menge der nicht aufeinanderfolgenden Leerzeichen plus eins der Menge dessen, was wir als Wörter akzeptieren. Wir müssen aber nicht addieren, sondern kleben einfach ein Leerzeichen hinten an und lassen einen trivialen regulären Ausdruck durchzählen:

$word_count = preg_match_all( '~\s+~', "$text ", $m );

Ergebnis: 5.

Nicht neu, aber bisher ungebloggt: Das Plugin Germanix wandelt Umlaute und viele andere Nicht-ASCII-Zeichen in einen passenden Ersatz um und erstellt daraus Permalinks und Dateinamen. Es ersetzt das längst nicht mehr gepflegte Plugin o42-clean-umlauts.

Germanix schlägt zu, wenn man eine Datei hochlädt oder einen Artikel anlegt. Bei neuen Schlagwörtern, Kategorien, eigenen Taxonomien und Post-Typen natürlich auch.

Ein Beispiel: Einem Artikel mit dem schönen Titel »12 m³ Scheiße« gibt WordPress ohne weitere Plugins den Slug 12-m³-scheise. Jetzt haben wir ohne Not ein Nicht-ASCII-Zeichen darin, und ein entstelltes ß.

Germanix hingegen produziert 12-m3-scheisse. Das paßt besser.

Das Plugin besteht eigentlich aus zweien: Germanix URL für URLs und Dateinamen und Germanix Translate für Übersetzungen im Backend. Beide Plugins lassen sich separat anschalten. Das Übersetzungsplugin werde ich vermutlich irgendwann fallen lassen – außer der Umwandlung von »Dashboard« nach »Übersicht« brennt darin nichts; manche Einträge sind sogar veraltet.

Fehler und Vorschläge wirf bitte in den Bugtracker. Da finde ich sie wieder.
Oder besser noch: Erstelle einen Fork, baue deine Ideen selber ein und sende einen Push-Request zurück.

Solange das Plugin nur bei GitHub liegt und ich keinen eigenen Updateserver eingerichtet habe, wird es keine automatische Aktualisierung geben, nur Hinweise per Twitter. Sorry!

Ich habe neulich ein anderes Plugin – Remove Redundant Links – testhalber im offiziellen Verzeichnis abgelegt und bin schon jetzt so genervt von SVN, daß ich auf weitere Experimente damit wenig Lust verspüre. Ja, git-svn kenne ich. Das nervt auch.
Schließlich geht es mir bei solchen Projekten auch um den Spaß an der Sache, also nicht um SVN.

Momentan wird der Windows-Livewriter noch nicht unterstützt. Wer das braucht, dem empfehle ich Frank Bültges Alternative. Die erfaßt weniger Zeichen und wird im Sprachverzeichnis abgelegt, wo sie sich nicht so einfach abschalten läßt wie ein Plugin. Dafür wandelt sie auch maskierte Zeichen um – das habe ich bisher weder gebraucht noch geschafft.

Weitere WordPress-Plugins

• Magische Widgets
• Icon to Link
• Backend Style Enhancements
• Canonical Permalink
• Tutorial: Ein Framebreaker-Plugin schreiben
• Basic Settings
• Remove Redundant Links

Quelle: CollegeHumor.

›Do not use PHP references‹, empfiehlt Johannes Schlüter, denn Referenzen kosten Tempo, Übersicht und Flexibilität. Ob seiner klaren und verständlichen Darstellung dieses kniffligen Themas möchte ich den Artikel jetzt schon in die Liste der zehn besten dieses Jahres rücken.

Nicholas C. Zakas: History of the user-agent string. Warum die UA-Strings heute oft so sonderbar aussehen. Die neue Kennung des IE 9 lautet:

Mozilla/5.0 (compatible, MSIE 9.0; Windows NT 6.1; Trident/5.0)

Anhängsel irgendwelcher Zusatzsoftware werden nicht mehr eingebaut; damit schrumpft die Liste der möglichen Kennungen gewaltig – was es Proxys erheblich erleichtert, gespeicherte Versionen einer Webseite auszuliefern. Das erklärt Billy Hoffman gut in: ›The Big Performance Improvement in IE9 No One is Talking About‹. Er rät auch dazu, die gzip-komprimierte Version nur noch anhand des Accept-Headers zu versenden und den User-Agent zu ignorieren, damit beispielsweise ein Safari-Nutzer die Version bekommt, die der Firefox-Nutzer zuvor in den Proxy gehievt hat.

Man kann dezimale Zeichenreferenzen mit beliebig vielen führenden Nullen versehen. So läßt sich das A als A schreiben oder als &#000000000000000000000000000000065;
›hakre‹ hat mal ausprobiert, wie weit man damit gehen kann: ›HTML Entity Boundaries – Zero Padding‹.
Ein Experiment, dessen praktischer Nutzen sicher weit unter seinem Unterhaltungswert liegt. Doch zeigt es, wie weit die Entwickler vorausdenken und wo sie die Grenze ziehen zwischen ›das versuche ich noch‹ und ›das wird zu langsam‹. Wenig überraschend frißt Firefox die meisten Nullen – bis zum Erstickungstod.

Anne van Kesteren hat auch ein Experiment mit gewaltigem Geekpotential hingestellt: Live style sheet editing!
Und da muß ich einfach mal den Quelltext zitieren:

<!doctype html>
<html>
 <head>
  <title>Live style sheet editing!</title>
  <style style="white-space:pre /* hack for Opera */" contenteditable="">
html {
margin:.2em;
font-size:2em;
color:lime;
background:purple
}
head, title, style
{
display:block
}
body {
display:none
}
  </style>
 </head>
 <body><!-- nothing is needed here --></body>
</html>

Zum Schluß noch ein Link für die Freunde der Maus: Harmony, ein Zeichenprogramm in Javascript und Canvas. Das macht wirklich Freude.

UTF-8 ist eine Zeichenkodierung für Unicode. Damit können wir alle Zeichen aus Unicode benutzen, ohne sie zu maskieren: das deutsche Alphabet und das chinesische, Währungszeichen, Musiknoten, Pfeile und Schachfiguren.

In E-Mails mag UTF-8 noch nicht immer angebracht sein; im Markup jedoch können wir nicht mehr darauf verzichten:

• In unseren Formularen wollen wir jedes Zeichen verarbeiten können. Wenn wir kein UTF benutzen, riskieren wir, wichtige Daten zu verlieren.
• Alle XML-Parser müssen UTF-8 verstehen (und UTF-16). Newsfeeds, SVG, XSLT, RDF – all diese Formate sollten wir nur in UTF-8 oder UTF-16 schreiben, damit jeder sie gewiß verarbeiten kann.
• Alle wichtigen APIs der großen Webdienste liefern UTF-8 aus: Flickr, Twitter, Youtube oder Delicious. Wenn wir diese Daten verarbeiten wollen, sollten wir uns nicht den Umweg einer Konvertierung zumuten.
• UTF-8 ist im Unterschied zu UTF-16 bedingt kompatibel zu US-ASCII, denn alle ASCII-Zeichen werden deckungsgleich kodiert. Zeichen oberhalb des Dezimalwerts 127 freilich brauchen zwei Bytes. Deshalb ist es in allen Sprachen, die eine Variante des lateinischen Alphabets verwenden, sehr kompakt.
• Die meisten Browser verwenden für Nicht-ASCII-Zeichen in URLs UTF-8. Wenn wir das nicht erwarten, werden wir unsere Besucher sicher bald frustrieren.
• UTF-8 können wir validieren: So finden und reparieren wir falsch kodierte Zeichen, ehe der Leser sie sieht.
• UTF-8 braucht kein BOM. Auch ein Vorteil gegenüber UTF-16 und UTF-32. Anleitung: Bom entfernen.

In einigen Programmiersprachen – Perl oder PHP beispielsweise – hängt die Implementierung der Multibytekodierungen noch ein bißchen. Aber mit ein wenig Lektüre können wir auch diese Probleme meistens lösen. Nie entschuldigen sie allein den Verzicht auf UTF-8.

Zu diesem Artikel wurde ich durch zwei Diskussionsbeiträge inspiriert: einen schlechten und einen guten. Der gute stammt von Björn Höhrmann, dem ich deshalb ausdrücklich danken will.

Für einen Kunden, der in drei Sprachen bloggt und bei gleicher Wortmenge oft sehr unterschiedlich lange Auszüge produziert, habe ich einmal diese Extrafunktion geschrieben:

/**
 * Erzeugt einen Auszug mit genau definierter Zeichenzahl.
 *
 * @param int $chars Menge der Zeichen.
 * @param bool $echo Aus- oder Rückgabe
 * @return string
 */
function excerpt_chars($chars = 100, $echo = TRUE)
{
    global $post; 

    $out = strip_tags($post->post_content);
    $out = substr($out, 0, (int) $chars);
    $out = end_on_word($out) . ' …';
    $out = xwp_autop($out); 

    if ( $echo )
    {
        echo $out;
        return;
    } 

    return $out;
} 

/**
 * Wandelt Zeilenumbrüche in HTML-Code.
 * wpautop() ist hier nicht nötig
 * @source http://photomatt.net/scripts/autop
 * @param string $pee zu formatierender String
 * @param bool $br
 * @return string
 */ 
function xwp_autop($pee, $br=1)
{
    // cross-platform newlines 
    $pee = preg_replace("/(\r\n|\n|\r)/", "\n", $pee);
    // take care of duplicates
    $pee = preg_replace("/\n\n+/", "\n\n", $pee);
    // make paragraphs, including one at the end
    $pee = preg_replace('/\n?(.+?)(\n\n|\z)/s', "<p>$1</p>\n", $pee);
    // optionally make line breaks
    if ($br) $pee = preg_replace('|(?<!</p>)\s*\n|', "<br />\n", $pee);
    return $pee;
}

Diese beiden Funktionen kommen mitsamt der Funktion end_on_word() in die functions.php.

Im Template wird die Funktion dann anstatt des the_excerpt() benutzt:

// Die ersten 200 Zeichen
excerpt_chars(200);

Bei ipaddresslocation.org oder proxyserverprivacy.com bekommt man Listen aller IP-Adressen, die zu einem Land gehören. Die muß man jetzt nur in die CIDR-Notation konvertieren; damit die .htaccess einigermaßen übersichtlich bleibt.

Ich habe mir dazu ein kleines Script geschrieben, das ihr gerne benutzen dürft: IP-Adressen nach CIDR konvertieren. Dort stehen ein Beispielcode zum Ansehen und fertige Listen für China und Südkorea zum Download.

Beim Zusammenstecken des Formulares ist mir aufgefallen, daß die Filterfunktionen in PHP zwar ein »sanitize« für alle möglichen Datentypen mitbringen, nicht aber für IPv4.

Ich brauchte eine Funktion, die aus 127.0. ein 127.0.0.0 macht, weil ich manche Blöcke bisher über gekürzte IP-Adressen gesperrt habe.

/**
 * Repariert unvollständige IPv4-Adressen.
 * Usage:
 *      sanitize_ip('127.0');
 * Result:
 *      string(9) "127.0.0.0"
 * @param string $ip
 * @return string
 */
function sanitize_ip($ip)
{
    // Standardverhalten plus Punkt.
    $ip = trim($ip, "\n\r\t\x0B\0. ");

    if ( ! preg_match('~(\d+\.?)*~', $ip) )
    {   // Hat nicht die Form 127.0 oder 127.0.0.
        // Man könnte auch alle falschen Zeichen rauswerfen,
        // aber das wäre zu … weich.
        return FALSE;
    }
    // Mehrfache Punkte entfernen.
    $ip    = preg_replace('~(\.)+~', '.', $ip);
    // In Abschnitte zerlegen.
    $parts = explode('.', $ip);
    // Wieviele haben wir eigentlich?
    $c     = count($parts);
    // Fehlende Abschnitte mit 0 ergänzen.
    for($i = 4 - $c; $i > 0; $parts[] = 0, $i-- );
    // Zusammensetzen und raus damit.
    return implode('.', $parts);
}

Das kann man sicher noch verfeinern. Vorschläge nehme ich gerne entgegen.

Opera benutzt UTF-8, Firefox und Internet Explorer aber verwenden die Zeichenkodierung, die als lokaler Rückfallwert eingestellt wurde, auf einem deutschsprachigen System also meistens ISO-8859-1.

Der Apache kann – soweit ich weiß – nicht automatisch erkennen, ob eine Zeichenkette in UTF-8 kodiert wurde. Und diese Kette entsprechend umzuwandeln geht dann vollends über seine Fähigkeit und Kompetenz hinaus.

Mit PHP hingegen ist das sehr leicht möglich, wenn es als Modul arbeitet und nicht per CGI.
Hier will ich mal eine einfache Methode vorstellen, Umlaute in Benutzernamen und Paßwörtern zu erlauben. Ich habe diesen Code 2005 geschrieben; etwas später habe ich ihn auf PHP 5 umgestellt, und seither verwende ich ihn immer wieder in kleinen Projekten.
Die Funktionen is_utf8_compatible() und force_utf8() sollten in einer separaten Klasse liegen; ich habe sie hier nur der Übersichtlichkeit halber direkt in die Authentifizierungsklasse gesetzt.
Im ZIP-Archiv liegt auch eine Datei, die den praktischen Einsatz demonstriert.

Download: PHP-Klasse: HTTP_Auth.

Um die Diskussion zu erleichtern, sei hier der Quellcode im Original wiedergegeben:

class HTTP_Auth

<?php
/**
 * Sendet Authentifizierungsheader
 *
 * @category HTTP
 * @author   Thomas Scholz <http://toscho.de>
 * @version  1.0.1 (10.06.2009)
 * @access   public
 */

class HTTP_Auth {

    /**
     * Texte
     */
    private $messages = array(
        'realm'          => 'Passwortschutz!',
        'wrong_name'     => 'Der Nutzername stimmt nicht.',
        'no_password'    => 'Bitte geben Sie Ihr Passwort ein.',
        'wrong_password' => 'Das Passwort stimmt nicht.',
        'login_failed'   => 'Tja, Pech!<br>Zur <a href="/">Startseite</a>.</p>'
        );

    /* Constructor */
    public function __construct()
    {
        /* Nichts zu tun. */
    }

    public function set_message($name, $text)
    {
        $this->messages[$name] = $text;
    }

    /**
     * Prüft Nutzernamen und -paßwort
     * @param array $array_users Array aus name => password je in md5()
     * @return boolean
     */
    public function is_authuser($array_users)
    {
        if ( !isset ( $_SERVER['PHP_AUTH_USER'] ) )
        {
            $this->require_auth($this->messages['realm']);
        }
        else
        {
            $name = md5( $this->force_utf8($_SERVER['PHP_AUTH_USER']) );

            if ( !array_key_exists($name, $array_users) )
            {
                $this->require_auth($this->messages['wrong_name']);
            }
            if ( !isset ($_SERVER['PHP_AUTH_PW']) )
            {
                $this->require_auth($this->messages['no_password']);
            }
            elseif ( $array_users[$name] != md5(
                    $this->force_utf8($_SERVER['PHP_AUTH_PW']) )
                )
            {
                $this->require_auth($this->messages['wrong_password']);
            }
            else
            {
                return TRUE;
            }
        }
    }

    /**
     * Sendet Authentifizierungsheader.
     * @param string $realm Nachrichtentext
     * @return string
     */
    public function require_auth($realm)
    {
        header('WWW-Authenticate: Basic realm="' . $realm . '"');
        header('HTTP/1.0 401 Unauthorized');
        echo $this->messages['login_failed'];
        exit;
    }
    /**
     * Prüft einen String auf UTF-8-Kompatibilität.
     * RegEx von Martin Dürst
     * @source http://www.w3.org/International/questions/qa-forms-utf-8.html
     * @see http://toscho.de/2009/utf-8-erzwingen/
     * @param string $str String to check
     * @return boolean
     */
    public function is_utf8_compatible($str)
    {
        return preg_match("/^(
              [\x09\x0A\x0D\x20-\x7E]            # ASCII
            | [\xC2-\xDF][\x80-\xBF]             # non-overlong 2-byte
            |  \xE0[\xA0-\xBF][\x80-\xBF]        # excluding overlongs
            | [\xE1-\xEC\xEE\xEF][\x80-\xBF]{2}  # straight 3-byte
            |  \xED[\x80-\x9F][\x80-\xBF]        # excluding surrogates
            |  \xF0[\x90-\xBF][\x80-\xBF]{2}     # planes 1-3
            | [\xF1-\xF3][\x80-\xBF]{3}          # planes 4-15
            |  \xF4[\x80-\x8F][\x80-\xBF]{2}     # plane 16
            )*$/x",
            $str);
    }
    /**
     * Versucht, einen String nach UTF-8 zu konvertieren.
     *
     * @param string $str Zu kodierender String
     * @param string $inputEnc Vermutete Kodierung des Strings
     * @return string
     */
    function force_utf8($str, $inputEnc='WINDOWS-1252')
    {
        if ( $this->is_utf8_compatible($str) )
        {
            // Nichts zu tun.
            return $str;
        }

        if ( strtoupper($inputEnc) == 'ISO-8859-1')
        {
            return utf8_encode($str);
        }

        if ( function_exists('mb_convert_encoding') )
        {
            return mb_convert_encoding($str, 'UTF-8', $inputEnc);
        }

        if ( function_exists('iconv') )
        {
            return iconv($inputEnc, 'UTF-8', $str);
        }

        else
        { /* GAU! */
            return $str;
        }
    }
}

Eine Nutzerverwaltung gehört natürlich in separaten Code, denn sie sollte vom Authentifizierungsverfahren unabhängig sein.
Ich habe hier MD5-Hashwerte verwendet – diese gelten nicht mehr als sicher. Je nach Sicherheitsanforderung sollte man also einen anderen Algorithmus benutzen oder besser eine ganz andere Authentifizierungsmethode. Denn bei der hier vorgestellten Variante werden Nutzername und Paßwort im Klartext an den Webserver gesandt. Wenn das ein Problem ist, dann dürfte die Erzeugung des Hashwertes die kleinste Sorge sein …

Anwendungsbeispiel example.php

Hier wird hoffentlich klar, daß es ausreicht, nur die Hashwerte der Namen und Paßworte auf dem Server zu speichern – die Klasse arbeitet allein damit, muß die Originale also nicht kennen. Generell gilt: Speichere niemals Paßwörter im Klartext! Nicht in der Datenbank, nicht im PHP-Skript und auch nicht in Textdateien.

<?php
require_once 'class.HTTP_Auth.php';
header ("Content-Type: text/html;charset=utf-8");

$auth = new HTTP_Auth;

$users = array(
        // 'ö'   => 'ßüß'
        'a172480f4e21d0a124bac19c89569c59'      => '994510e17c01e8680c3147df0c8ea605',
        // So lieber nicht!
        md5('Gröfaz') => md5('Laß mich rein!')
    );
if ( $auth->is_authuser($users) )
{
    echo '<p style="padding: 20%; font:2em/1.5 serif">Hallo <b>'
        . $auth->force_utf8($_SERVER['PHP_AUTH_USER'])
        . '</b>, dein Passwort ist <b>'
        . $auth->force_utf8($_SERVER['PHP_AUTH_PW'])
        . '</b>!</p>';
}

Einschränkungen

In Deutschland leben etwa 7 Millionen Ausländer oder Menschen mit einer anderen Muttersprache als Deutsch.
Wer Türkisch als Muttersprache hat, wird die Daten vielleicht in ISO-8859-9 kodieren, wer vorrangig Russisch spricht, ISO-8859-2 – und so weiter. Da die übertragenen Daten zu kurz für eine automatische Erkennung sind, scheitert der hier vorgestellte Weg notwendig an solchen Problemen.

Der Zugriff auf Nicht-PHP-Dateien ist immer noch ohne Kontrolle möglich. Hierbei hat der Schutz per Server klar die Nase vorne. Man könnte natürlich sämtliche Aufrufe im zu schützenden Verzeichnis über das PHP-Skript schicken. Das finde ich aber nicht sehr … praktisch.

Finden

Ob eine Datei überhaupt ein BOM hat, kann man festellen, indem man sie sich mit einem Hex-Editor ansieht. Ein BOM sieht darin so aus: EFBBEF. Das können wir hier gleich löschen – und den Rest dieses Artikels überspringen. Manche Editoren versauen dann aber die komplette Datei (PSPad beispielsweise), deshalb seien hier noch andere Wege genannt.

Wer sich zum Betrachten keine zusätzliche Software installieren möchte, kann die Datei auch einfach im Browser öffnen und die Zeichenkodierung der Ausgabe manuell auf ISO-8859-1 festsetzen. Steht ganz oben , haben wir ein BOM erwischt.

Online: UTF-8 BOM tester.

Entfernen

Gut, wir haben das BOM entdeckt – jetzt müssen wird es irgendwie loswerden.

Linux und Mac OS X

Hier ist es ganz einfach: Wir öffnen die Datei in Vim, geben :set nobomb ein und speichern sie. Fertig.

Windows

Mit Bordmitteln werden wir das BOM – soweit ich weiß – nicht los. Spätestens jetzt müssen wir einen zusätzlichen Editor benutzen, beispielsweise Notepad++: Öffnen, unter Format »UTF-8 ohne BOM« einstellen, speichern, fertig.
Für dieses Programm gibt es auch ein Hex-Editor-Plugin; damit können wir gleich prüfen, ob es geklappt hat.

Ein Tip von Andreas Borutta: Christoph Schneegans bietet ein VB-Script zum Entfernen des BOMs an. Auf der Seite ganz unten die Datei delete-utf8-bom.vbs herunterladen, auf dem Desktop ablegen und die »bomifizierte« Datei mit der Maus draufziehen – fertig.

In jedem brauchbaren Editor kann man einstellen, daß alle Dateien oder nur bestimmte Dateitypen als UTF-8 ohne BOM gespeichert werden. Wenn dein Editor das nicht anbietet, dann wirf ihn weg.

Seither versuche ich, einigermaßen auf dem aktuellen Stand zu bleiben. Ich lerne, und ich suche nach Inspiration. Dabei helfen mir ein paar Weblogs, die ich heute mal vorstellen will.

Richard Rutter: The Elements of Typographic Style Applied to the Web

Leser dieses Blogs kennen Richard Rutter spätestens seit meinem Artikel über das Problem ignorierter Mindestschriftgrößen. Auf webtypography.net schreibt er seit 2004 ein Handbuch zur Webtypographie, das ich jedem dringend als Lektüre empfehlen möchte.

Eigentlich ist es kein Blog, aber da die Seite einen (leider gekürzten) Newsfeed hat und einigermaßen regelmäßig mit frischem Inhalt versorgt wird, nehme ich mir die Freiheit, meine Liste damit zu beginnen. Englisch.

Lesetip: Set ragged if ragged setting suits the text and page. Warum Blocksatz eine Sünde ist.

Jürgen Siebert c/o FontShop AG: Fontblog

Ein »Firmenblog«, das über neue Schriften, Wettbewerbe und kleine Alltagsgeschichten berichtet. Für mich vorrangig eine Linkquelle. Volltextfeed, deutsch.

John D Boardley: I love typography

Einmal pro Woche kann man sich hier eine mit Links und und Nachrichten eindecken, die bequem für zwei Wochen reichen. Zwischendurch gute Artikel zu Spezialfragen und zur Terminologie.
Lesetip: Who shot the serif?. Volltextfeed, englisch.

Stephen Coles: Typographica

Hier wird über Schriften und Bücher berichtet … allerdings ist die Aktualisierungsrate inzwischen bei Infraschall angelangt. Volltextfeed, englisch.

FontShop: The FontFeed

Stephen Coles schreibt auch hier, gemeinsam mit Jürgen Siebert, Yves Peters und Erik Spiekermann. Ein hochkarätiger Autorenstamm, der uns mit News, Links und Inspiration versorgt. Hin und wieder auch mal ein schöner Technikartikel wie dieser: Styles, Weights, Widths — It’s All in the (Type) Family.
Leider nur mit kastriertem Feed, englisch.

Erik Spiekermann: SpiekerBlog

Typographie wird nicht nur von Menschen genutzt – sie wird auch von ihnen gemacht. Spiekermann vermittelt die persönliche Note mit viel Humor und der Gelassenheit eines Mannes, der wirklich nichts mehr beweisen muß. Volltextfeed, deutsch.

Christoph Koeberlin: Typefacts

Noch ganz frisch ist Christoph Koeberlins Blog Typefacts. Laßt euch vom englischen Titel nicht ablenken: Christoph schreibt klares Deutsch. In die Artikel hat er kleine interaktive Tests eingebaut, die ich wirklich mag. Und da seine Texte ein paar meiner Entwürfe inhaltlich »umzingeln«, fühle ich mich angenehm unter Druck gesetzt …
Auf meine Bitte hin gibt es jetzt auch einen Volltextfeed.

Dies ist natürlich nur eine kleine Auswahl. Ich habe mich auf Webseiten mit dem Schwerpunkt »Typographie« konzentriert, die man auch per Feed lesen kann. Eure Tips?