CAPTCHAS

Wer kann's lesen?

Die wohl zuverlässigste Methode um Spam-Bots zu behindern und echte Besucher auf lange Zeit zu vergraulen nennt sich CAPTCHAS. Eine in eine Grafik eingebettete Zeichenfolge soll vom Benutzer erkannt und in ein Feld eingegeben werden. Der Vorteil dieser leider sehr verbreiteten Methode besteht lediglich darin, dass der Seitenbetreiber diesen Schutz sehr schnell in seine Seite integrieren kann. Aus der großen Popularität resultiert aber eben auch eine zunehmende Zahl an Programmen, die diese Bilder auf unterschiedlichen Wegen entschlüsseln oder umgehen können. Unnötig zu erwähnen, dass solche Lösungen nicht nur Barrieren aufbauen, sondern auch nerven. Nur wenig besser (aus Sicht der Zugänglichkeit) sind in Klartext formulierte Logikfragen oder Rechenaufgaben, deren Antwort in ein Feld geschrieben wird. (»Warum muss ich hier eingeben, wieviel Beine ein vierbeiniger Tisch hat?«)

Ich halte prinzipiell von Methoden Abstand, in denen sich der Benutzer als Mensch beweisen muss. Die eingangs gestellte Frage sollte man auch so stellen und nicht anders herum!

(Zentrale) schwarze Listen

Ein anderer Ansatz zur automatischen Erkennung von unerwünschtem Spam ist das Anlegen schwarzer Listen um bestimmte Regelmäßigkeiten in Spamkommentaren zu dokumentieren und jeden Kommentar gegen diese Listen abgleichen. Je größer dabei die betrachtete Menge der Kommentare, desto genauer und umfangreicher werden solche Listen. Zentrale Filterangebote wie Akismet werten alle Kommentare der teilnehmenden Websites aus und erstellen so effektive Filter, von denen alle Teilnehmer profitieren. Doch ist mir bei diesem Gedanken etwas unwohl, da die Formulardaten erstmal eine Reise um die halbe Welt antreten um durch die zentralen Server des Unternehmens zu laufen. Dazu kommt, dass nicht behobene falsch-positive Spamerkennungen einen unbedarften Kommentator gleich auf unzähligen anderen Websites ausschließt.

So effektiv und komfortabel Akismet auch sein mag, hier kommt es vorerst nicht zum Einsatz.

Handarbeit

Vorgefertigte Lösungen wie CAPTCHA-Dienste oder Akismet bedienen auch eines: die Bequemlichkeit dauergestresster Webmaster. Allerdings sind beide Lösungen nervig und/oder datenschutzrechtlich zumindest bedenklich. Dennoch habe ich keine Lust täglich zig Spamkommentare zu löschen. Also habe ich mir mit etwas Handarbeit ein eigenes Plugins gezimmert, in dem ich unterschiedliche Methoden zur Erkennung von Bots anwende. Dabei gehe ich von selbst aufgestellten, oder allgemein bekannten Thesen aus um daraus Filtermethoden abzuleiten.

1. Bots sind dumm

   oder zumindest häufig auf populäre Systeme zugeschnitten. Bei komplexeren Formularen mit mehreren obligatorischen Angaben kann eine Kontrolle der einzelnen Angaben auf Korrektheit schon eine menge Unsinn abfangen. Allerdings sollte man die Filter nicht zu streng auslegen. Eine URL muss nicht zwangsläufig mit ›http://‹ beginnen. Ein Name hingegen endet nur äußerst selten auf ›/index.html‹. Fakultative Felder sollten leer bleiben (Spambots können sich oftmals nur schwer bremsen und füllen gerne alles aus), oder eben den Ansprüchen der Logik genügen: Buchstaben z.B. haben in einer Telefonnummer oder Postleitzahl nichts zu suchen. Wem das zu heikel ist, der sucht nach bestimmten Zeichenketten (›http://‹), man kann sich ja mal vertippen.

   Auf vielen WordPress-basierten Seiten ist die Angabe eines Namens und der E-Mailadresse gefordert, wenn man einen Kommentar hinterlassen will. Wahrscheinlich können die Spamprogramme deshalb die Namens-Attribute der Input-Felder lesen. Wir machen es ihnen aber auch einfach: geschätzte 99,9% aller WordPress-Installationen verwenden für die Namens-Attribute ›author‹, ›email‹, ›url‹ und ›comment‹. Ich habe nicht schlecht gestaunt, als das Spamaufkommen hier um gut 90% zurückging, nur weil ich diese Attributwerte durch zufällig generierte Zeichenketten wie ›df4928j‹ ersetzt habe. Die Bots hier verstehen offenbar noch keine Labels.

2. Bots sind schnell

   Auf dieser Seite beträgt die Zeitspanne zwischen Aufruf des Artikels und Eintrag des Kommentars bei automatisiertem Spam im Durchschnitt 2,5 Sekunden. Selbst wenn ein Mensch den gesamten Artikel schon kennt, und einen vorbereiteten Kommentar einfach nur einfügt und absendet, dürfte er bedeutend länger brauchen. Momentan habe ich die Grenze bei 6 Sekunden gesetzt.

3. Bots lesen keine Stylesheets

   Diese Theorie kann man sich zu nutze machen um eine Falle zu platzieren. Ein zufällig platziertes weiteres Formularfeld wird per Stylesheet für alle Parteien aus dem Sichtbereich geschoben bzw. gar nicht mehr angezeigt. Ist das Feld dennoch ausgefüllt, war mit sehr hoher Wahrscheinlichkeit ein Bot am Werk. Wer auf Nummer sicher gehen will, kann hier auch eine Logikfrage platzieren, für den seltenen Fall, dass ein Textbrowser verwendet wird, der kein CSS interpretiert.

Die Kombination dieser Methoden klappt momentan so gut, dass ich auf die Angabe von Name und E-Mail inzwischen verzichten kann und Kommentare auch sofort eingetragen werden können, ohne von mir überprüft zu werden. Schlägt einer der Filter an, wird der Kommentar nicht gänzlich gelöscht, sondern nur als Spam markiert. Notfalls hole ich sie von Hand wieder zurück.

Auf statischen Seiten habe ich auf diesem Weg sehr gute Erfahrungen gemacht. Die Umsetzung als WordPress-Plugin ist noch in der Testphase. Wenn irgendwo Probleme beim Kommentieren auftreten, würde ich mich über eine kurze Problembeschreibung per E-Mail sehr freuen.

Mir ist bewusst, dass auf einer vergleichsweise kleinen Seite wie dieser andere Bedingungen herrschen als auf den großen Blogs und dass der Kampf gegen automatisierten Spam wahrscheinlich bis zum jüngsten Tag andauern wird, da sich auch Spambots weiter entwickeln. Solang ich aber mit etwas Handarbeit auf CAPTCHAS und Akismet verzichten kann, werde ich es auch tun.

Im Großen und Ganzen bin ich ganz zufrieden mit dem Ergebnis. Wenn hier und da noch ein paar Macken auftreten, die werden sicher bald behoben sein. Falls ihr irgendwo noch über rumliegende Farbeimer stolpert, würde ich mich über einen kurzen Hinweis freuen.

Und wie findest Du, lieber Leser, das neue Outfit?

Für diesen Beitrag würde das so aussehen: PHP, Wordpress. Kurz und knackig, aber ein ordentlicher Satz lässt sich daraus nicht formulieren, dazu fehlt das „und“ zwischen den beiden (letzten) Stichworten.

Um solche Aufzählungen in einen vernünftigen Satz einbinden zu können habe ich mir folgenden Code-Schnipsel in die functions.php des Themes geschrieben:

/*
*  Ersetzt das letzte Komma durch ein ' und ' 
*/
function mytheme_tag_list($a) {
 
    //wenn mehr als ein link vorhanden ist
    if(substr_count($a,'<a href="') > 1) {
 
        $pattern = '#</a>\s*,\s*<a ([^>]*)>([^<]*)</a>\s?$#';
 
        $replace = '</a> und <a $1>$2</a>';
 
        $a = preg_replace($pattern,$replace,$a);
    }
    return $a;
}
add_filter('the_category','mytheme_tag_list');
add_filter('the_tags','mytheme_tag_list');

In dieser Form greift der reguläre Ausdruck nur Auflistungen heraus, die durch ein Komma (und evtl. Whitespace) getrennt sind. Aufzählungen ohne oder mit anderen Trennzeichen bleiben unberührt.

Nun kann ich formulieren, dass dieser Beitrag die Themen PHP und Wordpress behandelt.

Um in PHP eine E-Mail zu versenden reicht theoretisch folgendes Codebeispiel aus:

mail(
         'mustermann@mail.de',
         'Urlaubsgrüße',
         'Hallo Max, Urlaub an der Ostsee ist toll!'
       );

Der Funktion mail() werden drei Parameter übergeben: Empfänger, Betreff und der eigentliche Nachrichtentext. Nun besteht eine E-Mail nicht nur aus diesen drei Informationen. Genauer genommen, setzt sich eine E-Mail, ähnlich wie ein HTML-Dokument aus zwei Teilen zusammen: einem Kopf (Head) und einem Körper (Body). Im Head(er) werden wichtige Informationen über die E-Mail mit gesendet, unter anderem auch die verwendete Zeichenkodierung. Wenn die Zeichenkodierung nicht angegeben wird, muss der Empfänger „raten“, rät er falsch kommt es zur fehlerhaften Darstellung von Umlauten und Sonderzeichen.

Für die Lösung des Problems sind zwei Schritte nötig:

1. muss dafür gesorgt sein, dass die Daten des Formulars in einem bestimmten Zeichenkodierung zum Server gesendet werden und
2. muss diese Zeichenkodierung in der E-Mail angegeben werden.

Die Zeichenkodierung des Formulars

Der Inhalt eines HTML-Formulars wird in der Zeichenkodierung gesendet, in der auch das HTML-Dokument an den Browser gesendet wird. Die zuverlässigste Art, den Browser über die Zeichenkodierung zu informieren ist das entsprechende HTTP-Headerfeld „Content-Type“. Auf dem Apache Webserver geht das recht unkompliziert, in dem man im Wurzelverzeichnis seiner Website die .htaccess-Datei um folgende Zeile ergänzt:

AddDefaultCharset UTF-8

Diese Methode setzt voraus, dass auch alle Text-Dokumente (Skripte, Stylesheets) in dieser Zeichenkodierung vorliegen.

Ob die Zeichenkodierung im HTTP-Header einer Seite gesendet wird, kann man online testen, oder z.B. in Firefox mit verschiedenen Plugins.

Darüber hinaus kann es nicht schaden, die Zeichenkodierung zusätzlich als Meta-Element in den Quelltext des HTML-Dokumentes zu übernehmen:

Eine weitere Möglichkeit bestünde darin, das Formular um das Attribut „accept-charset“ zu erweitern.

<form accept-charset="utf-8">
</form>

In der Regel reicht es jedoch aus, die Zeichenkodierung im HTTP-Header zu senden.

E-Mails versenden mit Köpfchen

Der E-Mail Header, den die Funktion mail() generiert umfasst nur die nötigsten Informationen und  kann durch einen weiteren Parameter beeinflusst werden. Dabei werden die einzelnen Feld-Wert-Paare durch einen Zeilenumbruch (\r\n) voneinander getrennt. Die Zeichenkodierung wird im Feld „Content-Type“ angegeben. Mit dem „MIME-Version“ Feld wird gesagt, dass die E-Mail MIME formatiert vorliegt.

$email_header  = "MIME-Version: 1.0 \r\n";
$email_header .= "Content-Type: text/plain;charset=UTF-8 \r\n";

Die Variable $email_header wird als vierter Parameter der Funktion mail() übergeben:

//E-Mail senden
mail($address, $subject, $content, $email_header);

Damit hat sich der Zeichensalat erledigt. So lange im E-Mailheader keine Sonderzeichen vorkommen, sind Unicodezeichen im Text der E-Mail ab jetzt kein Problem mehr. Wenn aber z.B. der Name und die E-Mailadresse des Absenders in den Header aufgenommen werden, oder der Betreff im Kontaktformular vom Benutzer eingegeben werden kann, dann muss man davon ausgehen, das nicht nur ASCII-Zeichen in den Header gelangen. Aber nur diese sind dort erlaubt.

In dem Fall müssen die Zeichenketten für den Header kodiert werden. Dazu gibt es zwei Möglichkeiten: Base64 und Quoted-printable. Die kodierten Abschnitte werden von der Zeichenfolge =?utf-8?q? eingeleitet und von ?= beendet. Der einleitende Tag gibt die Ursprüngliche Zeichenkodierung (hier UFT-8) und die Kodierungsmethode (q für Quoted-printalbe und b für Base64) an.

Für die Kodierung bedient man sich der PHP-Funktionen base64_encode() für Base64 bzw. imap_8bit() oder quoted_printable_encode() für die Quoted-printable Methode. Allerdings ist die Funktion imap_8bit() an die IMAP-Extention geknüpft und quoted_printable_encode() gibt es erst seit PHP Version 5.3.

Der Betreff der E-Mail würde wie folgt kodiert werden:

$subject = $_POST['subject'];
 
//Quoted-printable
 
$subject = '=?utf-8?q?'.imab_8bit($subject).'?=';
 
//alternativ: Base64
 
$subject = '=?utf-8?b?.base64_encode($subject).'?=';
 
//senden
 
mail($address, $subject, $content, $email_header);

Theoretisch sind beide Varianten legitim, in der Praxis scheinen einige Freemailanbieter noch Probleme mit UTF-8 in der ein oder anderen Methode zu haben. Die Web.de Webmail-Oberfläche z.B. zeigte die dekodierten Betreffzeilen in der Übersicht an, in der Einzelansicht allerdings nicht. Thunderbird und auch Outlook (mobile Version) haben hingegen keine Probleme mit der Dekodierung.

Spätestens wenn die Komplexität der zu sendenene E-Mails über ein simples Kontaktformular hinaus geht, empfielt es sich, vorgefertigte Klassen wie phpmailer zu verwenden. Notwendige Kodierungen werden damit intern abgehandelt und die E-Mail automatisch zusammengefügt.

Die Frage die ich aus den Artikeln und Kommentaren lese: „Darf man erklärte Feinde der Demokratie mit undemokratischen Mitteln bekämpfen?“

Nach Rosa Luxemburg

Früher war ich häufig der Ansicht, man solle um eine Demonstration von Neonazis nicht mehr Wind machen, als unbedingt nötig. Durch gezielt organisierte Gegenaktionen würde man nur unnötige Aufmerksamkeit darauf lenken und polarisieren. Denn nicht selten enden solche Konfrontationen damit, dass auf Krawall gebürstete Linke sich mit der Staatsgewalt in die Haare bekommen. Eine schlechte Presse über „gewaltbereite Autonome“  relativiert dann das eigentliche braune Problem und die stille Zustimmung aus den Wohnzimmern mit den „eigentlich doch friedlichen Nationalen“ gibt es oben drauf.

Zu unseren Grundrechten gehört das Demonstrationsrecht – damit ist auch eine Demonstration der NPD durch das Gesetz legitimiert. Dieses Argument habe ich öfter gelesen, daran gibt es nichts zu drehen und zu wackeln. Die Demokratie lebt davon nicht nach Gutdünken die Freiheit anderer zu beschränken. Eine genehmigte Demonstration zu be- oder verhindern ist eine Ordnungswidrigkeit, entsprechend ist der Aufruf dazu ebenfalls gesetzlich verboten, weswegen die Seite dresden-nazifrei.de kürzlich gesperrt wurde.

Als überzeugter Demokrat und Dresdner steht man vor einer Zwickmühle: man schaut tatenlos zu, wie das braune Unheil durch seine Stadt zieht, oder man stellt sich quer, wissend, dass man anderen die Freiheit nimmt, für die man doch selbst einsteht.

Meine „laissez-faire“-Haltung gegenüber Nazidemos kann in diesem Fall keine Lösung sein. Im vergangenen Jahr wurde Dresden von 6000 Neonazis heimgesucht, dieses Jahr werden es sicher nicht weniger. Viel mehr öffentliche Aufmerksamkeit kann man gar nicht darauf lenken. Offiziell will man der Dresdner Opfer „in Würde gedenken“. Was inoffiziell dahinter steht, kann sich jeder vernunftbegabte Mensch ausmalen: Geschichtsrevision, Verharmlosung der deutschen Kriegsverbrechen und im Endeffekt blanker Rassismus.

Der vom NS-Regime gewollte und begonnene zweite Weltkrieg hat 55 bis 60 Millionen Menschen das Leben gekostet.  Es ist auf eine groteske Art beschämend und abstoßend zugleich, dass die Sympathisanten der faschistischen Ideologie, die zu diesem Krieg  führte, heute immer noch Menschen gegeneinander abgrenzen und Opfer aufzählen. Damit verhöhnten und missbrauchen sie jeden einzelnen Menschen, der in diesem Krieg gestorben ist. Allein der Gedanke daran macht mich wütend und ich kann jeden verstehen, der diesen Aufmarsch aus diesem Grund verhindern will.

Frau Oberbürgermeisterin Orosz ruft alle Dresdner zu „Erinnern und Handeln. Für mein Dresden“ auf. Eine Menschenkette soll symbolisch die Innenstadt vor den Nazis schützen. Immerhin ein gutes Zeichen dafür, dass Dresden nicht einverstanden ist mit dem braunen Pack – wenn genügend Menschen mitmachen. Das ungute Gefühl der scheinbaren Tatenlosigkeit bleibt dabei trotzdem. Ich würde mir eine Aktion der Front Deutscher Äpfel wünschen. Dabei habe ich wenig Hoffnung, dass die Rechten das verstehen, es ist aber eine aktive und intelligente Art des Protests.

Am Ende zählt es als Dresdner zu zeigen, dass wir auf Nazis verzichten können auch wenn man sich nur symbolisch in den Weg stellt. Wie dieser Protest aussieht, muss jeder für sich selbst entscheiden.

Nachtrag 29.01.

Es kommt noch mehr Bewegung in die Sache. Dresden hat Auflagen erlassen nach der die Nazis nur eine Kundgebung, aber kein Aufmarsch durchführen dürfen. Wieder bleibt ein fader Beigeschmack, da doch dafür erst kürzlich das Versammlungsrecht vom Landtag geändert wurde.

Nachtrag  08.02.

Das Verwaltungsgericht Dresden hat entschieden, dass die Einschränkung der Nazidemo unzulässig ist.

Die richtige Antwort

Wenn man eine URL Aufruft, zu der keine passende Ressource gefunden wird, landet man für gewöhnlich auf einer weißen „404 – not found“ Seite, die vom Server automatisch generiert wird. Mit etwas Glück ist diese Seite aber im Design der Website und bietet mögliche Alternativen zum nicht gefundenen Inhalt. In beiden Fällen antwortete der Webserver auf die Anfrage mit dem Statuscode „404“ der besagt: „Es wurde nichts gefunden“.

Ändern sich bei einem Umzug die URLs der Seiten, so landet jeder Aufruf der alten Links in der Sackgasse obwohl die Seite noch existiert. Folgerichtig wäre die korrekte Antwort vom Server: „der gesuchte Inhalt ist jetzt unter einer neuen URL verfügbar“. Der richtige Statuscode für diesen Fall ist „301 – Moved Permanently“.

Einige Seiten sind auch komplett verschwunden. Zum Teil weil sie in andere eingebunden wurden (Kontakt und Impressum können durchaus auf einer Seite unterkommen), andere waren einfach veraltet. Anfragen auf gelöschte Seiten beantwortet man ordnungsgemäß mit dem Statuscode „410 – gone“, der soviel bedeutet wie „Diese Seite ist von uns gegangen“. Somit ist auch gleich dafür gesorgt, dass Google & co. bescheid wissen und ihre Indizes aktualisieren können.

Die Umzugskisten auspacken

Während andernorts noch diskutiert wird, ob Wordpress als CMS taugt, setze ich es ein. Nicht zuletzt weil Anpassungen wie diese kinderleicht zu integrieren sind. Um alte URLs ihren neuen zuzuordnen und gelöschte Seiten zu kennzeichnen, ergänze ich die functions.php des eingesetzten Designs um folgende Funktion:

/** umleiten alter Permalinks auf die neuen
*/
function translate_permalinks() {
 
    $_301 = array(
                    '/startseite.html' => '/'
                    '/kontakt.html' => '/kontakt',
                    '/mannschaften.html' => '/mannschaften',
                    '/news.html' => '/aktuell',
                    '/links.html' => '/weblinks',
                    '/impressum.html' => '/kontakt#impressum',
                );
 
    $_410 = array ( '/alt.html',
                    '/javascript/altes_script.js',
                    '/css/altes_stylesheet.css',
                    '/weg.html'
                   );
 
    if(array_key_exists($_SERVER['REQUEST_URI'],$_301)) {
 
        header('Location: '.
                   ($_SERVER['HTTPS'] ?
                          'https' :
                          'http'
                   ) .
                   '://'.$_SERVER['SERVER_NAME'] .
                   $_301[$_SERVER['REQUEST_URI']],
                   true,
                   301);
        exit();
    }
 
    elseif(in_array($_SERVER['REQUEST_URI'],$_410)) {
 
        header(
                  ($_SERVER['SERVER_PROTOCOL'] == 'HTTP/1.1' ?
                        'HTTP/1.1' :
                        'HTTP/1.0')
                   . ' 410 Gone'
                 );
        header('Content-type: text/html;charset=utf-8');
        echo '
<h1>410 - Gone</h1>
Dieses Dokument existiert nicht mehr bei uns.
         Besuch bitte unsere <em>neue</em> Website:
         <a href="http://domain.tld/">http://domain.tld</a>';
        exit();
    }
 
    else {
        return;
    }
}

In dem Array $_301 ordne ich die neuen Links den alten in der Form zu:
/link/zur/alten-datei.html => /neue_datei.
Alle nicht mehr vorhandenen URLs werden in dem Array $_410 lose aufgelistet. Die Elemente beider Arrays werden mit der Request-URI verglichen und im Falle einer Übereinstimmung erfolgt die Weiterleitung bzw. die Antwort mit dem entsprechenden Statuscode.

Der Funktionsaufruf erfolgt am Anfang der functions.php. Je nach Umfang der Website ist das etwas mehr Handarbeit die sich aber lohnt.

Nachtrag:

In den Kommentaren hat mich Thomas darauf hingewiesen, dass es schneller geht, die Umleitungen in die .htaccess-Datei zu schreiben, da so nicht jedesmal das ganze System geladen wird. Wer also auf die Performance achtet, oder ein anderes System als Wordpress nimmt, schreibt die Umleitungen und gelöschten Dokumente besser in die .htaccess.

Für diese Zwecke ist die Redirect-Direktive des Moduls „mod_alias“ geeignet. Alle permanenten Umleitungen werden so notiert:

Redirect permanent /alte_seite.html http://domain.tld/neue_seite

Hier muss man darauf achten, dass die URL zur neuen Seite vollständig angegeben werden muss, da Weiterleitungen nicht zwangsläufig auf eine Domain beschränkt sind.

Für gelöschte Dokumente lautet der Eintrag:

Redirect gone /alt.html

Der vollständige Eintrag für die oben behandelten Seiten:

<IfModule mod_alias.c>
Redirect permanent /startseite.html http://domain.tld/
Redirect permanent /kontakt.html http://domain.tld/kontakt
Redirect permanent /mannschaften.html http://domain.tld/mannschaften
Redirect permanent /news.html http://domain.tld/aktuell
Redirect permanent /links.html http://domain.tld/weblinks
Redirect permanent /impressum.html http://domain.tld/kontakt#impressum
 
Redirect gone /alt.html
Redirect gone /javascript
Redirect gone /css
Redirect gone /weg.html
</IfModule>

Mit der Redirect Direktive kann man nicht nur einzelne Dokumente sondern auch Verzeichnisse handhaben, wie im Fall der Stylesheets und der Skripte zu sehen ist.

Damit Anfragen auf die entfernten Dokumente nicht mit einer lieblosen Standardantwort abgespeist werden, kann man noch ein Error-Dokument in der .htaccess anlegen:

ErrorDocument 410 /entfernt.html

Um mit dem schnöden Einheitsbrei zu brechen und diesem Blog ein würdiges Jahresabschlusspost (zu Deutsch: Beitrag) zu verpassen erlaube ich mir einen kritischen Beitrag von Nico Semsrott zu verlinken, einem sehr begabten Nachwuchskomiker, der die Zeichen der Zeit erkannt hat – wir haben nichts mehr zu lachen.

Was fällt der Stadtobrigkeit eigentlich ein? Nächstes Jahr darf ich an den Adventssonntagen nicht mehr shoppen? Es gibt für mich einfach nichts Schöneres als an einem Sonntag sich durch ein Kaufhaus zu drängen, in den Wühltischen zu kramen und sich mit Fastfood zu stopfen um anschließend das nächste Kaufparadies zu entern. Und nun wird es mir mit fadenscheinigen Argumenten verboten.

Ich bin doch ein mündiger Bürger, der selbst entscheiden kann wann er wo sein Geld ausgeben will. Warum soll diese Entscheidung also von Anderen getroffen werden als mir? Es ist ja auch nicht so, dass sonntags niemand arbeiten müsste. Ärzte und Polizisten müssen doch auch ran und ich selbst hab schon Wochenendschichten geschoben, warum sollte es den Verkäufern besser gehen als mir, dem König Kunde? Deren Familien können doch auch schoppen gehen, dann tun sie wenigstens was für die Wirtschaft.

Wo wir gerade dabei sind, die Rechnung ist doch ganz simpel: Max Mustermann gibt jeden Tag 100€ beim shoppen aus. Ergo sind das 100€ mehr Umsatz für den Einzelhandel, wenn Max auch sonntags einkaufen geht. Pro Woche also 16,7% Umsatzsteigerung. Das können wir uns nicht leisten, darauf zu verzichten – gibt es einen besseren Weg aus der Kriese? Auf die Touristenscharen, die Dresden dann davonrennen, kann auch keiner verzichten. Die fahren dann lieber nach Riesa oder Meißen und kaufen Ihre Fernsehgeräte dort. Die obligatorischen Frauenkirchensouvenirs kann man auch im Internet bestellen, da muss man nicht extra herkommen.

Dabei könnte es so entspannt zugehen, wie heute schon auf dem Neustädter Bahnhof. Dort kann ich an allen Feiertagen noch gemütlich und entspannt shoppen gehen. Es ist schon zu oft vorgekommen, dass man den Braten am 25. verrissen hat und die Ersatzgans noch tiefgefroren im Froster lag. Wohl dem, der da zu Weihnachten noch schnell zum Fleischer spurten kann . In dem Sinne,

frohes shoppen!

Hi, I’m Stef.

And I’m Greg.

We’re cool.

We’re from google.

*winkt in die Kammera*

We use wave.

Oh yes, wave ist cool.

E-mail is uncool.

It’s so old

My granny uses e-mail.

Bah, we need some new stuff.

Why?, you ask?

I don’t understand the question, you Greg?

No, but… erm, here ist wave!

It’s totaly new and great.

And new …

Von allem ein Wenig

Nach dem sich die Beiden aus dem Video so große Mühe gegeben haben, die unzähligen Vorteile von Googles neuestem Streich „Google Wave“ anzupreisen, musste ich das auch mal ausprobieren. Also hab ich nach einer Einladung Ausschau gehalten um zum erlesenen Kreis der Tester zu gehören, denn der Dienst befindet sich noch im Teststadium.

Mein erster Eindruck: Google versucht mit Wave die eierlegende Wollmilchsau 2.0 auf die Beine zu stellen. In Wave vereinen sich zentrale Kommunikationsmechanismen, die das Internet (z.T. schon sehr lange) zu bieten hat. Das „Neue“  ist also eher eine Mischung aus Internetforum, Chat  und etwas E-Mail ohne die spezifischen Nachteile der einzelnen Methoden zu verbessern. Im Gegenteil. In einem Forum und bei E-Mail kann ich jeder Nachricht einen Titel bzw. einen Betreff geben. Waves haben keinen Titel. Dafür kann man an einer (oder einem?) Wave mehrere Kontakte teilhaben lassen und sie sogar öffentlich zugänglich machen. Was im ersten Moment sehr praktisch klingt, wird schon bei nur zwei Teilnehmern schnell unübersichtlich, denn jeder kann in Echtzeit in den Nachrichtenverlauf an beliebiger Stelle herein schreiben, sogar die Beiträgen der anderen Adressaten verändern. Eine durchdachte Struktur (optisch wie semantisch) vermisse ich hier sehr. Unter der Haube handelt es sich bei dem Wave Benutzeroberfläche um eine fettige Div-Suppe mit Tabellenwürzung.  Dabei wird beim Einloggen dringend empfohlen, entweder Firefox 3.5, Safari 4 oder den neuesten Google Chrome zu verwenden. Warum also nicht auf HTML 5 setzen, dass eine Vielzahl an Struktur-Elementen bietet, also wie geschaffen wäre für komplexe Dokumentenstrukturen wie Wave?

Überhaupt, Tippen mit Echtzeitübertragung… Jeder der Online ist, sieht die Cursorposition des Teilnehmers, der gerade in der Wave schreibt, jeden Tippfehler, jede falsche oder undurchdachte Formulierung, alles. Sieht mit unter lustig aus, nervt aber wenn man, wie ich, ein bis zwei Anläufe braucht, bis man die richtige Formulierung hat.

Für Windowsnutzer ist Google Wave (zur Zeit) eine reine Webanwendung, d.h. ich kann nur mit dem Browser „waven“, was noch sehr langsam und stockend vor sich geht, selbst mit Firefox 3.5 oder Opera 10 (Googles Hausbrowser Chrome habe ich nicht). Eine Desktopanwendung gibt es wohl nur für Mac-User. Die können dann auch gleich aus iPhoto Bilder per Drag&Drop in ein Wave einfügen. Das kann man mit jedem vernünftigen E-Mailprogramm auch unter Windows.

Natürlich gibt es auch Schnittstellen für Twitter und Blogs. So kann man Waves mit einem Blog „verknüpfen“ um dann von der Wave in das Blog zu schreiben und anders herum.

Schaut man sich das ganze an, wird einem schnell klar, dass wenn sich der Dienst durchsetzt, er sehr ressourcenintensiv werden dürfte. Globale Echtzeitkommunikation mit Konferenzschaltungs-Charme, das braucht Rechenpower. Rechenpower, wie nur Google sie „kostenfrei“ bereit stellen kann.

Kosten und Nutzen

Die Frage nach dem Sinn und Zweck von Google Wave hat sich mir eigentlich gleich zu Anfang gestellt. Ich komme wunderbar mit E-Mail, ICQ und ein paar Internetforen zurecht. Allerdings ist die Frage nach dem „Warum“ im Web 2.0 aussichtslos. Irgendwo werden sich immer neue Bedarfsnischen auftun, die gefüllt werden wollen.  Am Ende muss die Frage nur jeder für sich beantworten können. Für mich bleibt der fade Beigeschmack, dass mit Wave ein riesiger Konzern wie Google noch genauere Profile von seinen Kunden bekommt.

Fazit: Google Wave ist im jetzigen Stadium ein unübersichtliches, zäh zu bedienendes Medium, dessen Mehrwert gegenüber bisher Vorhandenem sich mir nicht erschließt. Wer es selbst einmal probieren möchte,  ich habe noch „Einladungen“ zu vergeben.

:)

Jeder der schon mal Dresdens Zentrum gesehen hat könnte meinen, die Kaufkraft der Dresdner und ihrer Touristen sei durch ein Überangebot an Einkaufsmöglichkeiten erschöpfend ausgereizt. Zwischen Altmarkt und Hauptbahnhof kann man entweder einen acht Minuten Spaziergang machen, oder mehrere Stunden damit verbringen sein Geld in alle möglichen und unmöglichen Dinge zu tauschen. Vom Sekundenkleber bis zu Feinkostwaren gab es bereits vor einem Jahr alles was das Käuferherz begehrte. Die Altmarktgalerie, eine arkadenförmige Ansammlung von über 100 Geschäften, Karstadt, drei Modehäuser, unzählige kleinere Modeboutiquen, Mobilfunkläden, Schuhgeschäfte, Cafés, Fastfood, Fitnesscenter – die typische City eben. Man hat auch nichts vermisst, es war also nicht so, als ob noch was gefehlt hätte, im Gegenteil.

Offenbar hab ich mich in beiden Fällen getäuscht, denn seit gut einem Jahr wird an einem weiteren Kaufpalast gewerkelt. In den letzten Wochen war es schlicht unmöglich zu übersehen, dass die Eröffnung nun kurz bevor steht. Tagtäglich brummte ein Zeppelin gefühlte 24 Stunden über Dresden. Auf der Außenhaut prangte das Logo der neuen „Centrum Galerie“ und nachts wurde die Eröffnungsbotschaft in Leuchtschrift auf die Hülle projiziert. Die Marketingabteilung hat offenbar keine Kosten gescheut um auf die neue Galerie aufmerksam zu machen. Dummerweise schien das Geld am Ende nicht mehr für den Internetauftritt zu reichen, der nicht mal ansatzweise die Atmosphäre und das Design der durchaus gelungenen Architektur widerspiegelt und auch sonst eher abschreckt.

Im Inneren erwarten einen nicht die typisch hellen Sandsteintöne und Vollglasgeländer wie man es von Arkaden wie der Altmarktgalerie gewohnt wäre. Verkaufspsychologen haben offenbar herausgefunden, dass mein Kaufrausch mit dunklen Tönen und verschnörkelten Fassaden effektiver stimuliert wird. (Die Schnörkel könnten aber auch ein clevere Assoziation zum Standort sein – Dresden, Barockstadt und so…) Insgesamt sieht es im Inneren wie auf einer Zukunftsmesse aus den 70ern aus. So hat man sich damals vieleicht das 21. Jahrhundert vorgestellt. Dunkle Fußböden, dunkles Holz für die Handläufe, dunkle verspiegelte oberflächen und indirektes violettes Licht. Ansonsten ist die Aufteilung eher gewohnt. Im Untergeschoss Fastfood und darüber Modeboutiquen, Mobilfunkläden, Schuhgeschäfte, Cafés usw. Kann man ja alles öfter gebrauchen. Neu sind dagegen Geschäfte, deren Angebot scheinbar ausschließlich aus neonfarbenen Flüssigkeiten besteht, die man in seltsam geformten Glaskaraffen kaufen kann (wtf?), sowie eine Lounge in der man in Sitzsäcken die bunten Lichter und die Flatscreens bewundern kann und die insgesamt den Eindruck erweckt, als ob unter der Ladentheke das Meskalin ausgeteilt wird.

Und endlich, ja endlich haben wir in Dresden ein „Starbucks“. Ich wollt schon immer mal erwachsenen Menschen dabei zu sehen wie sie ihren, mit Aromen gepanschten, „Coffee“ aus Pappbechern nuckeln, die in ihrer Form an Schnabeltassen erinnern. Gut, das ist jetzt kein Alleinstellungsmerkmal dieser Kaffeehauskette und auch ich habe meinen Kaffee auch schon mal „to-go“ konsumiert, aber bei Starbucks hat das doch mehr Stil und wirkt so weltoffen.

Besonders fasziniert bin ich von einer dieser Intershops 2.0. Eine Art Drogerie-Spielzeug-Feinkost-Kurzwaren-Kette, die die Möglichkeit bietet vom Tampon bis zum Legospielzeug einfach alles in einem Geschäft zu kaufen – das ist echt ungeheuer praktisch.

Genug gemeckert, denn das Ganze hat ja auch sein Gutes. Im Radio sprach man von 1000 neuen Arbeitsplätzen, die in der Centrum Galerie „entstanden“ sind. Mir fällt das ein bisschen schwer zu glauben, angesichts der Tatsache, dass zwei der größten Mieter nicht neu hinzugekommen sind, sondern einfach von der gegenüberliegenden Seite in die neuen Räume umgezogen sind (die jetzt übrigens leer stehen), aber wenn es denn so ist, kann man ja froh sein.

Und da geht offensichtlich immer noch was. Um den Kaufmannsladen-Overkill komplett zu machen, baut auch die Altmarktgalerie ihre Verkaufsfläche derzeit weiter aus. Ich bin gespannt, wie lange sich das alles halten wird.

–

Als hätte ich es geahnt, scherzte ich noch vor der Landtagswahl hier in Sachsen, „man müsse die Sonderausgabe der ad.rem“ (eine Studentenzeitung) zur Wahl „aufheben“. Darin prangten groß das Gesicht von Herrn Tillich und darunter die Worte:

Mein Wort gilt: Vom Vorschuljahr bis zum Master bleiben die Bildungsangebote gebührenfrei.

Ich hab die Ausgabe natürlich nicht aufgehoben, doch zum Glück gibt es sie auch online (Seite 13).

Okay, dass Wahlversprechen selten das Papier wert sind, auf dem sie stehen ist jetzt nich so neu. Dennoch würde ich dieses Blatt gern ausdrucken und der gesamten Sachsen CDU unter die Nase reiben, da man zusammen mit der FDP nun doch Studiengebühren für „Langzeitstudenten“ einführen will. Langzeitstudenten, dass sind Studenten, die länger als die Regelstudienzeit brauchen. Regelstudienzeit, die kennen wir alle, ist die Anzahl an Semestern in der das Studium theoretisch zu schaffen wäre, wenn man sich keine Gedanken um das liebe Geld machen muss, nie durch eine Prüfung fällt und zufällig einen Studiengang erwischt, der nicht überfüllt ist.

Ich hoffe, dass sich dagegen auch so großer Widerstand formieren wird, wie gegen das neue Hochschulgesetz, auch wenn die Erfolgschancen eher gering sind.

Rette deine Freiheit und geh wählen!

Worum es geht

Dieses kurze Tutorial soll zeigen, wie man in Wordpress die Kommentare fortlaufend nummeriert. Der Semantik wäre schon genüge getan, wenn man jeden einzelnen Kommentar als Punkt einer nummerierten Liste (<ol>) auszeichnet. Manchmal will man aber die Nummern Ziffern mit in die Gestaltung einbeziehen und mit CSS aufhübschen. Wie man die Nummer für jeden Kommentar als Zahl in den Quelltext bekommt, soll hier gezeigt werden.

Die Idee

Der HTML-Code für die Kommentare wird erzeugt, in dem die Datensätze in einer Schleife durchlaufen werden und für jeden Durchlauf der entsprechende Kommentar sein HTML-Kleid bekommt. Für unser Vorhaben reicht es also, vor dem Schleifenaufruf eine Zählvariable zu definieren (ich nenne sie hier mal $comment_counter). Innerhalb der Schleife setzen wir einen Befehl, der den Variablenwert um den Wert 1 erhöht.
Vor der Version 2.7 musste man diese Schleife noch von Hand schreiben und die Zählvariable konnte man bequem mit unterbringen. Das Kommentartemplate (comments.php) sah bis 2.7 schematisch etwa so aus:

< ?php
/**  comments.php
*/
// Unsere Zählvariable
$comment_counter = 1;
 
//der Kommentar-Loop
foreach ($comments as $comment) {?>
 
   <li id="comment-<?php comment_ID(); ?>">
        <p><cite>< ?php if(function_exists('get_avatar')) echo get_avatar(/*[…]*/); ?>
        < ?php comment_type('von', 'Trackback', 'Pingback'); ?>
        < ?php comment_author_link(); ?> – < ?php comment_date(); ?> um <a href="#comment-<?php comment_ID(); ?>">
        < ?php comment_time(); ?></a></cite>
        < ?php edit_comment_link(); ?></p>
 
        < ?php // Hier z.B. die Kommentarnummer ausgegeben: ?>
        <p class="nummer">< ?php echo $comment_counter; ?></p>
 
	< ?php comment_text(); ?>
    </li> 
 
      < ?php
      //zum Schluss setzen wir die Zählvariable noch eins hoch:
      $comment_counter++;
}
?>

Soweit, so gut.

Umsetzung seit Version 2.7

Seit Version 2.7 muss man die Schleife nicht mehr von Hand starten, sondern hat dafür die Funktion wp_list_comments() zur Verfügung. Diese Funktion organisiert den Schleifendurchlauf automatisch und erzeugt gleichzeitig das HTML, auf welches man geringfügig Einfluss nehmen kann, in dem man der Funktion bestimmte Parameter übergibt. Eine Nummerierung der Kommentare ist leider nicht vorgesehen.

Um das erzeugte HTML komplett selbst zu bestimmen (und somit die Kommentarnummer einzufügen), akzeptiert wp_list_comments() eine sogenannte Callback-Funktion, die man selbst schreiben muss und in der man die HTML-Maske für die einzelnen Kommentare bestimmt. Eine solche Funktion, man könnte sie z.B. mytheme_comment() nennen, schreiben wir in die functions.php. Der Name dieser Funktion kann beliebig gewählt werden, allerdings muss sie dem folgendem Schema genügen, um die Funktionalität zu gewährleisten:

< ?php
/** functions.php
*/
function mytheme_comment($comment, $args, $depth) {
 
      $GLOBALS['comment'] = $comment; 
 
      //Ab hier kann der Kommentar beliebig gestalltet werden 
?>
      <li <?php comment_class(); ?> id="comment-< ?php comment_ID() ?>">
 
        <h3 class="comment-author vcard">
            <cite class="fn">< ?php comment_author_link();?></cite>
        </h3>
 
        <div class="comment-meta">Geschrieben am < ?php comment_date();?> um < ?php comment_time(); ?></div>
 
        < ?php if ($comment->comment_approved == '0') : ?>
            <p class="commentinfo moderation">Dein Kommentar muss erst durch den Administrator freigeschaltet werden</p>
 
        < ?php endif; ?>
            <div class="comment-content">< ?php comment_text(); ?></div>
 
       < ?php
        /**
        *   Das schließende </li>-Tag für den einzelnen Kommentar
        *   setzt die Funktion wp_list_comments() von selbst, der 
        *   darf hier nicht gesetzt werden!
        */ ?>
}
?>
</li>

Um diese Callback-Funktion aufzurufen, übergeben wir deren Name als Parameter in Form eines Strings an die wp_list_comments():

< ?php
/**
*   der Aufruf in der comments.php
*/
?>
<ol id="commentlist">
     < ?php wp_list_comments('callback=mytheme_comment');?>
</ol>

Um auch hier die Kommentare mit ihrer Nummer zu versehen, definieren wir die Zählvariable wieder außerhalb der Schleife, also noch von dem Aufruf der Funktion wp_list_comments():

< ?php
/**
*   comments.php
*/
?>
<ol>
   < ?php
            $comment_counter = 0;
            wp_list_comments('callback=mytheme_comment');
   ?>
</ol>

Da diese Zählvariable außerhalb der Funktion mytheme_comment definiert wird, ist sie innerhalb der Funktion auch noch nicht „sichtbar“. Da wir sie nich einfach als Parameter an die Funktion übergeben können, müssen wir sie innerhalb von mytheme_comment als global definieren um darauf zugreifen zu können. Anschließend kann man sie per echo-Befehl an der gewünschten Stelle ausgeben und setzt deren Wert zum Schluss noch um 1 höher:

< ?php 
/** functions.php
*/
function mytheme_comment($comment, $args, $depth) {
 
      //Zugriff auf die Zählvariable (startet bei 0)
      global $comment_counter;
      //Zähler heraufsetzen.
      $comment_counter ++;
 
      $GLOBALS['comment'] = $comment;
      //...
 
      echo '<p class="comment_number">'.$comment_counter.'';
 
 
 
 
< ?php
}
?>

Ab jetzt hat jeder Kommentar seine eigene Nummer, die man per CSS beliebig gestalten kann.

Die Idee, ich habe sie mir bei Thomas Funktion end_on_word() abgeschaut, ist so simpel wie effektiv: Der String wird an den Leerzeichen in ein Array aufgespalten und mit diesem kann man dann arbeiten:

/** 
*   getFirstWords()
*   gibt die ersten count worte von str zurück
*   @param  int count (default 10)
*   @param  str str
*   @return str
*/
function getFirstWords($str = '', $count = 10) {
 
    $str = trim($str);
 
    if(empty($str)) return;
 
    else {
 
        // Jedes Wort ein Arrayelement
        $array = explode(' ',$str);
 
        // Array in $count große Teile teilen
        $array = array_chunk($array, $count);
 
        /*Falls der String weniger Worte hatte als $count
        * geben wir den String unverändert zurück
        */
        if (empty($array[1])) {
             return $str;
        }
 
        /* andernfalls entfernen wir eventuelle Kommas am ende
        * und fügen ein Auslassungszeichen an
        */
        else {
             return rtrim(implode(' ',$array[0]),',;').'[…]';
        }
    }
}
 
/** 
*   Anwendung
*/
$str = "Lorem ipsum dolor sit amet, consetetur sadipscing elitr, sed diam.";
 
//Die ersten 5 Wörter bitte:
echo getFirstWords($str, 5) .' […]';
 
/**
* Ausgabe: Lorem ipsum dolor sit amet […]
*/

Die BITV fordert ganz allgemein die Verwendung von relativen statt absoluten Einheiten. Ein Blick in die Spezifikation verrät, dass in CSS die Einheit px als relative Einheit zu verstehen ist. Logisch, denn wenn ich auf einen 15″ Flachbildschirm 1024×768 Bildpunkte aber auch 1400×1050 Bildpunkte unterbekomme, dann muss der Platz pro Bildpunkt von Gerät zu Gerät unterschiedlich sein. Soweit die Theorie die sagt, px als Einheit ist okay für die Angabe der Schriftgröße. In der Praxis offenbaren sich dann doch einige Probleme, die ich hier demonstrieren will.

Als Testobjekt dient dieses HTML Dokument, dessen Quelltext im wesentlichen so aussieht:

<style type="text/css">
 
    body {
        font-size:100%;
        line-height:1.5;
    }
    h1 {
        font-size:2em;
    }
    h2 {
        font-size:32px;
    }
    h3 {
        font-size:1em;
    }
    h4 {
        font-size:16px;
    }
    h5 {    
        font-size:.8em;
    }
    h6 {
        font-size:13px;
    }
</style>
    <h1>Text mit 2em Schriftgröße</h1>
    <h2>Text mit 32px Schriftgröße</h2>
    <h3>Text mit 1em Schriftgröße</h3>
    <h4>Text mit 16px Schriftgröße</h4>
    <h5>Text mit .8em Schriftgröße</h5>
    <h6>Text mit 13px Schriftgröße</h6>

Anschauen werde ich die Seite unter WinXP, bei einer Bildschirmauflösung von 1400×1050 mit Firefox 2, Opera 9.6, InternetExplorer 6-8 und Safari 3, sowie unter Vista, 1280×800 mit Firefox 3.5 und IE8 jeweils bei einem im Browser eingestellten Schriftgrößengrad von ›16‹ (also die Standardeinstellung der meisten Browser).
Auf Grund der 100%-Schriftgröße für den Body, die sich auf die im Browser eingestellte Schriftgröße bezieht, sind die jeweiligen Wortgruppen annähernd gleich groß (1em entspricht hier 16px). Mit Ausnahme aller Versionen des InternetExplorers werden bei reiner Schriftvergrößerung alle Texte gleichermaßen vergrößert. Der IE8 und Opera, aber auch Firefox ab Version 3 bieten zusätzlich noch eine komplette Zoomfunktion, die die gesamte Seite proportional vergrößert/verkleinert.

Soweit so gut. Was passiert aber, wenn ich von der Möglichkeit gebrauch mache, mir die Schriftgröße auf ein für mich optimales Maß im Browser voreinzustellen, z.B. auf 20? Hier zeigt sich das Problem der einheit px: der Text ist festzementiert auf die Größe, die im Stylesheet der Seite steh. Der Schriftgrad in der Browsereinstellung wird schlicht ignoriert. Als Besucher muss ich also erstmal am Mausrad drehen, oder auf die Plus-Taste drücken, um die Schrift zu vergrößern.

Jeder bessere Browser bietet außerdem die Möglichkeit an, eine Mindestschriftgröße festzulegen, die dann nicht mehr ignoriert werden kann. Diese stellt, wenn sie denn überhaupt eingestellt ist, meist die unterste Schmerzgrenze dar, unter der absolut nichts mehr geht, und die für Fließtext eigentlich schon zu klein ist. Spätestens da ist dann Schluss mit den Pixelschriftgrößen. Im schlimmsten Fall verspielt man so die Möglichkeit mit Schriftgrößenunterschieden auf der Seite zu arbeiten, wenn man mit seinen Schriftgrößen unterhalb der Mindestgröße agiert.

Aus diesen Gründen kann ich nur dringend davon abraten, Schriftgrößen in px anzugeben. Ansonsten drängt man den Besucher, zu erst zu Zoomen, um den Text lesen zu können. Dabei ist es unerheblich ob nun reiner Textzoom oder der komplette Seitenzoom eingesetzt wird.

Meine Herangehensweise sieht so aus, dass ich für den Body einen Prozentwert um 100 angebe (von mir aus auch 100.01% für die älteren IEs). Überschriften und große Texte werden dann im Bereich 1.4 bis 2em bemaßt, Fließtest zwischen 1.1 und .85em und Fußnoten .9 bis .8em. Dabei kann man durchaus sehr Genau arbeiten, da die Einheit em bis auf die vierte Nachkommastelle genau angegeben werden kann. Ich richte meine Schriftgröße nur so lang am Design aus, wie es mir die Bemaßung in em erlaubt und bin damit bisher immer gut gefahren, auf Pixelgenauigkeit achte ich auch sonst eher selten. Viel wichtiger sind optimale Zeilenlängen und vor allem ein ausreichender Zeilenabstand. Der Besucher sollte, unabhängig von seinen gewählten Einstellungen, ein lesbares Schriftbild vorfinden. Ihm diese Freiheit zu lassen, muss nicht im Widerspruch zu gutem und detailiertem Design stehen, man muss es nur berücksichtigen.

Jetzt würd ich mir noch ein Release auf 12″ von Pitchers wünschen…