Autorenhinweise

20.03.2013 16:05

Textformat

Die Artikel werden in einem Textformat verfasst, das Zeichen-Encoding ist ISO-8859-1/Latin-1. Um in diesem Text die einzelnen Abschnitte hervorzuheben (Überschriften, Listings, Bilder usw.) verwenden wir einfache Tags, die im Folgenden kurz beschrieben sind. Die Details stehen auf einer eigenen Seite.

 

Absätze

Einzelne Textelemente wie Überschriften, normaler Lauftext et cetera sind durch spezielle Tags voneinander getrennt. Diese haben immer den Aufbau "@XX:". Unsere Texte haben folgende Hauptkomponenten:

  • Eine Dachzeile, die das Thema beschreibt (@D:)
  • Eine Hauptüberschrift/Titel (@T:)
  • Den Vorspann (@V:)
  • Den eigentlichen Text (@L:)
  • Zwischenüberschriften (@ZT:)
  • Eine Autorenbox mit einer kurzen Vita

Eine Marke muss nur gesetzt werden, wenn sich das Format ändert. Bei mehreren Text-Absätzen, die direkt hintereinander folgen, genügt ein einzelnes @L: am Anfang. Die Absätze können durchaus auch über mehrere Rohtext-Zeilen laufen, ein wirklicher Absatzwechsel (Zeilenumbruch) kommt erst, wenn der Rohtext eine Leerzeile enthält (oder wenn die nächste Absatzformat-Marke folgt).

Ein Artikel besteht nie nur aus Text. Abbildungen und auch andere Gestaltungselemente (Kästen, Diagramme) lockern den Textfluss auf und verhindern die gefürchteten "Bleiwüsten". Wer liest schon gerne einen Artikel, der nur aus trockenem Text besteht und nicht durch anschauliche Grafiken, hübsche Screenshots oder informative Listings aufgelockert wird. Denken Sie dabei aber daran, dass Bilder, Tabellen und Kästen frei positionierte Elemente sind, auf die Sie sich im Text nicht mit "wie dieses Bild zeigt" oder "wie unten dargestellt ist" beziehen können, sie müssen stattdessen auf die Abbildung anhand ihrer Nummer verweisen. Dazu sind diese mit der Kennzeichnung "Abbildung X:" zu versehen.

 

Bilder

Der Mensch nimmt Informationen visuell leichter auf als verbal. Abbildungen vergeuden darum nicht etwa wertvollen Platz im Heft, sondern erleichtern das Verständnis der meist komplexen technischen Sachverhalte. Machen Sie sich darum beim Schreiben Gedanken, wie Sie Ihren Lesern durch Grafiken und Screenshots das Verstehen erleichtern können!

Eine manchmal etwas kniffelige Frage ist die nach dem passenden Dateiformat für Abbildungen. Handelt es sich um Grafiken (also Schaubilder, Ablaufdiagramme oder Übersichtsbilder), dann ist XFig eine gute Wahl. Es lässt sich sehr einfach weiterbearbeiten (die Redakteure nutzen natürlich auch Linux-Rechner) und in sehr gutes Postscript übersetzen. Wenn Sie ein anderes Format nutzen, senden Sie möglichst das Quellformat und eine PS-, EPS- oder PDF-Fassung. Oft ersetzen unsere Layouter nämlich Schriftarten oder Farben, um sie dem Erscheinungsbild des Linux-Magazins anzupassen. Bei Fotos eignen sich JPEG und TIFF. Bei Unklarheiten fragen Sie einfach die Redaktion.

Für Screenshots eignen sich PNG und GIF, auf gar keinen Fall aber JPEG. Achten Sie beim Erstellen des Screenshots darauf, dass er vor allem die wichtigen Teile zeigt und keine großen Leerflächen. Das Fenster dazu so klein wie sinnvoll ziehen. Bei Webbrowsern bitte unnötige Linkleisten etc. ausblenden. Ein Screenshot sollte immer nur ein Fenster (inklusive Rahmen) zeigen und nicht den ganzen Desktop. Einzige Ausnahme: Der Artikel behandelt den Desktop als solchen.

Schriften - insbesondere Menüs - müssen im gedruckten Magazin noch lesbar sein. Das gegrabbte Applikationsfenster sollte darum nicht größer als 800x600 Pixel sein. Auf keinen Fall aber den Screenshot nachträglich "kleinrechnen" - wir brauchen ihn immer in Originalgröße. Ein Farbschema nach europäischen Geschmack verhindert bonbonfarbene Farbtupfer im Linux-Magazin.

Bilder werden wie folgt ausgezeichnet:

@Bi:bild1.png
@B:Abbildung 1: Max kompiliert hier gerade seinen ersten Kernel.

Die Bildunterschrift sollte beschreiben, was auf dem Bild zu sehen ist, und damit verdeutlichen, welcher Teil wichtig ist. Im Text sollten Sie auf die Abbildung verweisen:

@L:In Abbildung 1 können Sie Max beim Kompilieren des Kernels bewundern.

Oder:

@L:.....Max beim Kompilieren des Kernels (Abbildung 1)

Kennzeichnungen im Fließtext

Fließtext beginnt immer mit dem Tag "@L:". Tags beziehen sich immer auf alle folgenden Absätze,
solange kein neues Tag den Geltungsbereich aufhebt. Zwei Sternchen statt eines Leerzeichens (wie in Red**Hat) stehen für ein geschütztes Leerzeichen, das nicht umbrochen wird. 

Textauszeichnungen wie fett, kursiv et cetera nehmen wir durch Tags mit spitzen Klammern (Größer/Kleiner-Zeichen) vor. Bitte beachten Sie, dass es keine Ende-Marken wie in HTML gibt, sondern öffnendes und schließendes Tag gleich aussehen. Kurze Kommandos wie "rm -rf *" oder Datei- und Verzeichnisnamen setzen Sie einfach als <C>Code<C> in den Fließtext. Das erscheint dann nachher so: >>rm -rf *<<. Andere Auszeichnungen sind <I>kursiv<I>, "in Anführungszeichen" oder in ganz seltenen Fällen auch mal <B>bold<B> (Fettdruck). URLs können Sie auch im Fließtext unterbringen, dazu einfach mit dem Tag <U> kennzeichnen, also:

<U>http://www.welt.weites.warten.net/index.html<U>

Ein oder zwei Zeilen Listing können Sie mit dem Tag @LI: beginnen und auf separaten Zeilen im Fließtext unterbringen. Diese erscheinen dann in einer Courier-Schrift. In eine Zeile passen etwa 40 Zeichen; wenn eine Zeile länger ist, bitte sinnvoll umbrechen. Als Umbruch-Zeichen verwenden Sie §§ (diese Zeichen kommen in einem normalen Listing nicht vor). Beispiel:

@LI:./configure --prefix=/usr/local --with-apxs2=/usr/sbin/apxs

ist etwas zu lang. Besser:

@LI:
./configure --prefix=/usr/local §§
--with-apxs2=/usr/sbin/apxs

Größere Listings stehen besser in einem eigenen Listing-Kasten. Listings können Sie auch als separate Dateien anliefern. Bitte immer auch vollständige (also ablauffähige) Skripte und Quelldateien mitliefern, die wir dann auf den FTP-Server stellen können.

Kästen und Tabellen

Zu viele einzelne Codezeilen im Fließtext erschweren den Lesefluss erheblich. Sie sollten sich deshalb überlegen Code möglichst in einem Kasten unterzubringen und im Text auf den Kasten zu verweisen. Natürlich ist das nicht immer möglich, aber versuchen Sie es zumindest.

Kästen haben immer einen Titel (@KT:). Normaler Text in Kästen ist Kastentext (@KL:). Listings werden auch im Kasten mit @LI: formatiert:

@KT:Listing 1: xy.c
@LI:
#include <stdio.h>

Kästen können außer Code auch zusätzliche Informationen enthalten, zum Beispiel Glossare, ein Interview oder einen anderen Aspekt des Hauptthemas, der im Fließtext nicht unterzubringen ist. Das alles ist zulässig und erwünscht. Aber bitte übertreiben Sie das "Kastenwesen" nicht, sonst sehen wir bald aus wie der Focus.

Tabellen sehen ähnlich aus wie Kästen, sie beginnen mit @TT:. Die einzelnen Tabellen-Zeilen müssen auch im Quelltext in einer Zeile stehen, die Spalten sind durch Tabulatoren voneinander getrennt:

@TT:Tabelle 1: Zeichen

Es erleichtert den Setzern und uns das Leben erheblich, wenn Sie Tabellen als Spreadsheets (Star Office, Applix ...) oder in einem Spreadsheet-fähigen Format (.csv oder so) anliefern. Andernfalls besteht gerade bei größeren Tabellen immer die Gefahr verrutschter Spaltenangaben.

Infos sind Referenzen auf URLs oder Literatur. Diese kommen ebenfalls in einen Kasten, der mit @IT:Infos beginnt und die Referenzen im @IL:-Bereich hat:

@IT:Infos
@IL:
[1] Online-Handbuch zur Pinguin-Zucht: <U>http://www.pinguin.de<U>
[2] Karl Korner: Der Kernel -- Compilieren leicht gemacht

Den Verweis im Text geben Sie bitte in eckigen Klammern an [1]. Die Autorenbox ist ein weiterer Info-Kasten. Er beginnt mit:

@IT:Die Autorin

Im Kastentext stehen dann einige Sätze Ihrer Wahl.

 

Hier ein kleines Beispiel eines vollständigen Artikels:

@R:Know-how
@D:Texte für ADMIN
@V:Einen Artikel für das ADMIN-Magazin zu schreiben ist gar nicht so schwer.
Hier lesen Sie, mit welchen einfachen Mitteln Absätze, Überschriften und Kästen
@A:Keiner Wars

@L:Ein Artikel besteht aus einer Mischung verschiedener Teile [1], vor allem
aber dem eigentlichen Text (auch "Lauftext" genannt). In diesem Lauftext kann
@LI:
./configure
make

@L:Wenn es aber ein längeres Listing sein soll, dann ist ein Kasten besser
geeignet (Listing 1). Hat es mehr als zehn Zeilen, dann bekommt es sogar noch
@KT:Listing 1: Hallo

@LI:
int main()
{
printf("Hallo, Leser!\n");
return 0;
 

@L:Der Kasten endet beim ersten <C>@KE:<C> oder <C>@L:<C>. Normaler Text im

Für einen einfachen Absatzwechsel genügt eine Leerzeile. 

@ZT:Bilder

@L:Bilder und Grafiken lockern Ihren Text auf. Es gibt im Wesentlichen folgende

* Text-Kasten

* Listing-Kasten

* Abbildung

Wer wäre nicht gerne an einem Sandstrand unter Palmen (Abbildung 1) -- und

@Bi:palme.jpeg
@B:Abbildung 1: Eine Palme im Sonnenuntergang -- der Inbegriff von Urlaub.

@L:Weiter im Text.

@IT:Der Autor
@IL:Keiner Wars will nicht, dass herauskommt, wer er ist. Er schreibt gerne für Computerzeitschriften.

@IT:Infos
@IL:
[1] Karl Korner, Der Kernel -- Compilieren leicht gemacht, Linux-Magazin 22/2007, S. 458

Artikel der Woche

Eigene Registry für Docker-Images

Wer selber Docker-Images herstellt, braucht auch eine eigene Registry. Diese gibt es ebenfalls als Docker-Image, aber nur mit eingeschränkter Funktionalität. Mit einem Auth-Server wird daraus ein brauchbares Repository für Images. (mehr)
Einmal pro Woche aktuelle News, kostenlose Artikel und nützliche ADMIN-Tipps.
Ich habe die Datenschutzerklärung gelesen und bin einverstanden.

Konfigurationsmanagement

Ich konfiguriere meine Server

  • von Hand
  • mit eigenen Skripts
  • mit Puppet
  • mit Ansible
  • mit Saltstack
  • mit Chef
  • mit CFengine
  • mit dem Nix-System
  • mit Containern
  • mit anderer Konfigurationsmanagement-Software

Google+

Ausgabe /2019