|
|
|
In einer Reihe von Artikeln in der If Fase werden nützliche Elemente von LaTeX vorgestellt, die erprobt sind und bei der Arbeit der [zukünftigen] Informatiklehrerin eingesetzt werden. In der vorliegenden Ausgabe wird ein Blick hinter die Kulissen der Erstellung der If Fase geworfen. Da an vielen Schulen Schülerzeitungen erstellt werden, sind Problemstellung und Lösungsansätze mit Hilfe von LaTeX durchaus schulrelevant.
In den bisher vorgelegten sechsundzwanzig Teilen der Artikelserie – Ausgaben 0 … 25: rhinodidactics.de/Archiv – finden Sie Hinweise und Anmerkungen zu den Themen: Installation, grundlegende Arbeitsweisen, Quellen zu Dokumentationen, Arbeit mit KOMAscript, PSTricks, PSfrag, TikZ, PGF, Erstellung von Arbeitsblättern, Struktogrammen, Automatengraphen, Elemente von UML, Barcodes, Formularerstellung, Zitieren (nach DIN 1505, mehrfach) Abbildungen, Tabellen (einfache und aus CSV-Daten generierte), ER Diagramme (mehrfach), Fragen der [Mikro-]Typografie, Setzen von Briefen, Graphiken mit LaTeX erstellen, sowie Einbinden von Lizenzbedingungen in LaTeX-Quelltexte und in die daraus erzeugten PDF-Dokumente. Mit dieser Ausgabe 26 der If Fase wird die Erstellung dieser Zeitung unter dem Blickwinkel der Datensicht thematisiert.
Die Strukturierung von Daten ist eines der wichtigen Anwendungsbereiche für informatische Methoden. Die Datenformate und ihre Kodierung ist – abgesehen von einigen proprietären Formaten – üblicherweise hinsichtlich ihrer Syntax und Semantik bekannt und wohldokumentiert, so dass es möglich ist, offene Formate mit eigenen Anwendungen zu nutzen.
In der PDF-Fassung dieser Ausgabe der If Fase rhinodidactics.de/Ausgaben/ausgabe-26.pdf ist eine Grafik eingebunden, die in dem Handbuch »TiKZ and PGF 2.0« auf Seite 107 angegeben wird. Das englische Handbuch findet sich im PDF-Format unter tinyurl.com/6j7h7o.
Die Nutzung kann darin bestehen, dass Daten, die in offenen Formaten übertragen werden sollen oder können, sowohl importiert als auch exportiert werden können. Im Laufe der Standardisierungsbemühungen – die häufig genug durch die Vertreter der proprietären Formate massiv behindert wurden und werden – entstanden Formate, die sich hinsichtlich der Orientierung an Inhalt, Struktur und Form stark voneinander unterscheiden.
Die Entwicklung verschiedener – zum Teil nur geringfügig voneinander abweichenden Formate – spiegelt nicht immer einen Fortschritt, sondern häufig genug die interessensgeleitete Durchsetzung durch schiere Quantität (== Marktmacht) wider. Hier wird nicht unter dem Gesichtspunkt dieser Dimension weiter differenziert. Die Kodierungsgrundlage vieler Formate ist »reiner« ASCII-Text – zunehmend auch die Codierung in utf-8. Mit Sprachen aus dem SGML-Umfeld wie HTML, XML, ODF, SVG, CSS werden explizite Auszeichnungen (engl. tags) der Form <bezeichnung> … </bezeichnung> in den Text eingefügt, um die Attributierung gemäß der jeweils gültigen Syntax zu erzielen. Die so entstehenden baumartigen Strukturen werden von XML-Parsern zur internen Repräsentation verwendet. Diese können mit Browsern dargestellt werden, aus ihnen lassen sich effizient Daten extrahieren, u.v.a.m.
Das Problem: aus einer Datenbasis – primär Beiträge der Autorinnen und Autoren – sollen sowohl die Webseiten als auch jeweils eine komplette Ausgabe der Zeitung als PDF-Dokument erzeugt werden. Dabei werden die Artikel von verschiedenen Menschen erstellt, die mit dem Layout der Zeitung nicht belastet werden.
Eine Lösungsidee: die Artikel sollten im Eingabeformat ein alleinstehendes, anzeigbares Dokumentenformat haben. Skripte sorgen für die Umwandlung der mit genau festgelegten Auszeichnungen versehenen Eingabedateien (== Artikel) sowohl für die Webdarstellung als auch für den Produktionsprozess, der für die Erstellung des PDF-Dokuments über LaTeX (mit Hilfe von pdflatex) durchgeführt werden muss. Darüber hinaus werden aus den Daten Nachrichtenkanäle beschickt.
Für die »Druckausgabe« der Zeitung werden die einzelnen Artikel nach den in einer die Struktur wiedergebenden Vorlage zu einem Dokument zusammengefügt. Die Aufteilung für die Seitengestaltung wird damit in eine eigene Datei ausgelagert, die nur diesem Zweck dient und durch Attributwerte z.B. Stauchung und Streckung einzelner Beiträge die Seitenfüllung beeinflussen kann.
Artikel (Eingabedaten) im Browser
An die »Webausgabe« werden andere Anforderungen gestellt: So müssen die Webseiten mit einer sinnvollen Verweisstruktur unterlegt werden, damit die Navigation innerhalb einer Ausgabe und im Archiv der Zeitung konsitent gestaltet wird. Jeder Artikel muss als eigene, vollständige Webseite dargestellt werden.
Ohne auf weitere – durchaus bedeutsame – diffizile Details einzugehen, können mit der von Torsten Bronger vorgestellten ZML (Zeitungs-Markup-Language) die o.g. Anforderungen erfüllt werden. Diese Lösung wird von uns – beginnend mit der 0-Nummer vom Mai 2005 – für die vorliegende Zeitung eingesetzt. Inzwischen wurde der Quellcode über Sourceforge sourceforge.net/projects/zeitung-ml öffentlich zur Verfügung gestellt. ZML-Handbuch
Prinzipieller Produktionsablauf -- die Autorin erstellt eine XHTML-Datei mit dem Inhalt ihres Artikels – alle anderen Schritte werden von der Redaktion und geeigneten Skripten erledigt.
Die Eingabedaten für einzelne Artikel werden als xhtml–Dateien angeliefert. Sie haben einen einheitlichen Kopf, der den Titel des Dokuments enthält. Die Metadaten werden in Form einer Tabelle dargestellt und umfassen Autor, Datum, Schlagworte sowie eine laufende Nummer. Details werden im Handbuch zu ZML dokumentiert: zeitung-ml.sourceforge.net/Artikel.html
Die Artikel werden mit Auszeichnungen zur Strukturierung versehen. Die Anforderungen an die Auszeichnungen sind gegenüber »normalem« .html allerdings eingeschränkt.
Die ZML-Steuerdatei zur Erzeugung des PDF-Dokuments wird für jede Ausgabe von der Redaktion erstellt. Sie beschreibt die Einbindung der Beiträge in die jeweilige Ausgabe. Python-Skripte realisieren die Umsetzung für die Produktionskette.
flowfram
–
Beispiel
PaperTeX – Beispiel
Allerdings werden bei diesen Lösungen keine Webseiten
erstellt.