|
Transportanleitung |
|
|
Dieses Beispiel enthält den Auszug aus der Dokumentation für Rührwerke. Das Kapitel enthält die Einführung zur Transportanleitung sowie die Verfahren zum Heben von Wellen. Bei diesen Dokumentationen wird über ein Mutterdokument, das alle denkbaren Module enthält, über die Funktion »Bedingungen« selektiert und dadurch eine gerätespezifische Dokumentation zusammengestellt. |
|
|
Bemerkungen des Autors (Ekato): Industrierührwerke, wie sie vor allem in der Chemie und der Umwelttechnik in Gebrauch sind, werden nicht »von der Stange« geliefert, sondern stets den spezifischen Kundenanforderungen entsprechend ausgelegt und einzeln gefertigt, sind also der Gattung der »Sondermaschinen« zuzuordnen. Eine den Anforderungen der EG-Maschinenrichtlinie genügende Dokumentation kann daher kein aus dem Regal entnommenes Buch sein, welches mehr oder weniger oberflächlich sämtliche möglichen Konfigurationen beschreibt, sondern muss für jedes einzelne Rührwerk so zusammengestellt werden, dass sie nur die in diesem Rührwerk verwendeten Baugruppen und die zugehörigen Verfahren beschreibt. Die Beispieldokumente zeigen ein Kapitel aus der Service-Anleitung für EKATO-Rührwerke. Dieses Kapitel enthält die Einleitung zu dem Abschnitt, der sich mit dem Transport von Rührwerken und deren Bestandteilen befasst und beschreibt ggf. die Verfahren zum Heben von Wellen. DEMONULL.PDF zeigt das Mutterdokument. Alle Bedingungen sind eingeschaltet, Kommentare (der Klartext der den einzelnen Abschnitten zugewiesenen Bedingungen) und der Steuertext für die Fußzeile sind sichtbar. DEMOEINS.PDF zeigt dann die einfachste, mögliche Variante. Das Rührwerk hat keine abnehmbare Welle, es werden nur ein paar Sicherheitshinweise gegeben. DEMOZWEI.PDF ist für eine abnehmbare Rührwelle, die beschichtet und daher handhabungsempfindlich ist und nur ein Hebeverfahren erlaubt. DEMODREI.PDF zeigt schließlich die umfangreichste Variante für eine metallische Rührwelle, die zwei verschiedene Hebeverfahren erlaubt. Gut zu sehen ist, dass die Bilder stets bei dem zugehörigen Text bleiben und der Text sauber zentriert zu den Bildern steht, was über zweizellige Tabellen realisiert wird, in deren linken Zellen die Bilder verankert werden (Alle Versuche, die Bilder im Fließtext zu verankern, führten zu unbefriedigenden Ergebnissen; das war bei Framemaker aber genauso, bei dem im Rahmen der Evaluation der beiden Programme letztlich auch nur diese Layoutlösung gefunden wurde). In dem Mutterdokument kann man auf der zweiten Seite links oben gut erkennen, dass Ventura als Bedingungen auch komplexe Boolesche Ausdrücke akzeptiert (shaftseparate AND (epoxycoating OR plasticlining OR rubberlining)). Dies ist ein wesentlicher Vorzug vor Framemaker, der zumindest bis zur Version 5.1 (mit späteren Versionen hat der Autor (Ekato) keine Erfahrung) bei Mehrfachzuweisung von Bedingungen stets eine ODER-Verknüpfung durchführt. Bei Framemaker ist es dafür möglich, auch Textabschnitte innerhalb eines Absatzes mit Bedingung zu versehen, was Ventura nicht erlaubt. Nach dem Wegschalten von Bedingungen muß man per Skript nach leeren Seiten am Ende der Kapitel suchen und diese ggf. löschen. Ventura merkt sich offenbar je nach Ablauf des Wegschaltens der Bedingungen die ursprüngliche Position von verankerten Rahmen und erkennt die Seite nicht als leer an. Framemaker zeigt diese Macke nicht, sondern löscht frei werdende Seiten zuverlässig. Durch die Möglichkeit, per Bedingungen bisher unterschiedliche Kapitel zusammenzufassen, wird der Bestand an reinen Textkapiteln von ca. 400 (unter Ventura 4.2) auf ca. 40 zusammenschmelzen. Das wird eine große Erleichterung bei der Pflege der Dokumente bringen (Fehler müssen nicht mehr mehrfach korrigiert werden) und vor allem die Erzeugung und Wartung fremdsprachiger Dokumentation enorm rationalisieren. Ansonsten zeigte sich im Rahmen der seinerzeitigen Evaluierung von Ventura 7 und Framemaker 5.1, dass man mit Ventura 7 (das für den Autor (Ekato), der bis dahin Ventura von den Versionen 3 bis 5 angewendet hatte, genauso neu war wie der Framemaker) in wesentlich kürzerer Zeit zum Ziel kommt als mit Framemaker. Insbesondere die nicht-modalen Dialoge (Eigenschaftsfenster, die offen bleiben) sind ein großer Gewinn. Framemaker hingegen rief Kopfschütteln hervor, nicht nur durch seine verschachtelten, modalen Dialoge, sondern vor allem durch die vielen Dinge, die nicht möglich sind (die z. T. schon bei Ventura 4.2 selbstverständlich waren), z. B. die Festlegung von Trennlinien bei mehrspaltigen Layouts in der Seiten- bzw. Kapitelvorlage oder das automatische Einfügen von generierten Inhaltsverzeichnissen in bestehende Kapitel. Schließlich befremdete bei Framemaker auch das Fehlen einer integrierten Skriptsprache (Automatisierung läßt sich stattdessen nur über eine C/C++-Schnittstelle realisieren!). Mit freundlicher Genehmigung: |