In unserem Betrieb teXen wir nahezu alle Briefe mit scrlttr2, was mir heute einen heftigen Streit mit meinem Chef eingebracht hat.
Unter MiKTeX 2.4 führt das angehängte Beispiel dazu, dass der Textbereich _immer_ zentriert wiedergegeben wird, d.h. der Textblock ist nicht links in einer Flucht mit der Adresszeile angeschlagen. Bei 10pt als Extremfall wird das überdeutlich, bei 12pt ist es immer noch gut sichtbar.
Mein Chef erachtet das als 'falsch' und 'unansehnlich'.
Meine Fragen hierzu ist, ob die aktuellen DIN-Normen ein solches Verhalten vorschreiben?
Der Workaround über KOMAOld oder eine eigene .lco-Datei ist mir bekannt, aber es geht um das typographische Prinzip.
Anhang | Größe |
---|---|
Minimalbeispiel.txt | 825 Bytes |
Was hat DIN mit Typografie zu tun?
Die DIN schreibt vor, dass die Adresse an einer ganz bestimmten Stelle steht (damit man Fensterbriefumschläge verwenden kann). Die Adresse ist darüber hinaus ein Konsultationstext. Er hat mit dem Brieftext nichts zu tun und muss sich als Konsultationstext auch nicht an den Satzspiegel halten.
Die Typografie schreibt vor, dass Zeilen im Satzspiegel nur eine ganz bestimmte maximale Länge haben, weil man sie sonst schlecht lesen kann. Darüber hinaus ist es üblich, dass der linke und der rechte Rand bei einseitigen Dokumenten gleich groß sind.
Würde man nun die Adresse nach DIN positionieren und gleichzeitig den linken Rand neben der Adresse als Rand für den Satzspiegel verwenden, so müsste man entweder den Satzspiegel so breit machen, dass die Lesbarkeit deutlich leidet, oder eine sehr breit laufende Schrift verwenden, bei der das nicht geschieht (die dann aber eventuell auch wieder schlecht zu lesen ist) oder aber die Ränder unsymmetrisch wählen. Warum also nicht, Konsultationstexte wirklich aus dem Satzspiegel lösen? Ich nehme stark an, dass Dein Chef soetwas bei einer Tabelle oder Abbildung irgendwann schonmal selbst gemacht hat. Für die Adresse ist das typografisch min. so richtig. Genaugenommen ist die Adresse ein Formularfeld des Briefbogens. Vielleicht habt Ihr auch noch ein Logo fest in der rechten oder linken oberen Ecke des Briefbogens, das bis zum Rand geht (findet man häufiger bei Firmenbriefbögen). Frag mal deinen Chef, ob der Text etwas auch bis an den äußeren Rand dieses anderen (vorgedruckten) Formularfeldes des Briefbogens gehen soll (also bis an den Papierrand). [OK, so eine Äußerung ist extrem provokativ, aber sie zeigt die Richtung, in die die Äußerung deines Chefs im Extremfall geht.]
In Anhang C der gedruckten KOMA-Script-Anleitung oder in DTK 2/2003 findet sich eine Alternative mit unsymmetrischen Rändern, die aber dank Nutzung des dadurch entstehenden breiten rechten Randes für andere Informationen trotzdem nicht hässlich verschoben wirkt.
Ich gehe davon aus, dass sich dein Chef schnell an das Aussehen von scrlttr2 gewöhnen würde, wenn er es täglich erleben dürfte. Vielleicht würden ihm nach ein paar Wochen sogar die hässlichen Briefe vieler anderer auffallen. Obwohl Briefe ein Aushängeschild sind, werden täglich Massen lieblos zusammengeschusterter Exemplare produziert. Sogesehen ist es erfreulich, wenn sich da jemand wirklich Gedanken darüber macht, was gut ist und was nicht.
Herzlichen Dank!
Danke für die sehr ausführliche Antwort!
Nachdem wir bereits reichlich Erfahrung mit dem unzureichenden Support vieler kommerzieller Softwareanbieter sammeln durften, war mein Chef überrascht, bei einem freien Softwareprojekt eine so umfassende und tiefgehende Antwort zu erhalten.
Er ist Ihrer Argumentation gefolgt und hat einige seiner Vorbehalte gegen nichtkommerzielle Projekte relativiert!
Scrlttr2 hat bei uns seit über einem Jahr dinbrief erfolgreich beerbt und kommt bei den wirklich wichtigen Briefen (also fast allen ;) zum Einsatz.
Bezüglich der Frage "Was hat DIN mit Typografie zu tun?": Da mir die entsprechenden DIN-Normen nicht vorliegen, habe ich angenommen, dass die Norm Angaben zum Satzspiegel des Brieftextes enthält. Aber dieses Thema ist ja zum Glück ausgestanden.
Und da ich schon mal beim Schreiben bin, möchte ich mich noch herzlich für die Klasse scrreprt bedanken, mit der ich meine Diplomarbeit sehr schmerzfrei erstellen konnte!
Fehler in DIN.lco
Hallo Herr Kohm,
es scheint in den Voreinstellungen DIN.lco für scrlttr2 einen Fehler zu geben, dessen Korrektur das oben beschriebene Problem immerhin ein gutes Stück verringern dürfte:
Die anzuwendende Norm ist DIN 5008 "Schreib- und Gestaltungsregeln für die Textverarbeitung", welche 2011 die alte DIN 676 von 1995 vollständig ersetzt hat. Laut DIN 5008 hat das Anschriftenfeld einen Abstand von 20mm zum linken Seitenrand, der Text darin hat jedoch einen Abstand von 25mm zum linken Seitenrand. Nachzulesen in DIN 5008 Bild 3, Bild 4, Bild 5 und Tabelle B.1.
Die DIN-konformen Einstellungen DIN.lco für scrlttr2 liefern jedoch ein Ergebnis, bei dem der Text des Adressfeldes einen Abstand von 20mm zum Seitenrand aufweist - und damit 5mm zu wenig.
Ich habe mir damit beholfen, in der Präambel meines Briefdokuments die Längenvariable toaddrhpos von 20 auf 25mm zu setzen:
Damit lässt sich zumindest bei Schriftgröße 12 mittels typearea ein recht guter Satzspiegel erzeugen, bei dem der linke Textrand nahezu bündig mit dem des Adressfeldes abschließt.
Im übrigen denke ich, dass die Typografie in einer Norm für Textverarbeitung eine dem Thema angemessene Rolle spielen sollte. Anwender gehen davon aus, dass in einer Norm alle fachlichen Aspekte, die das Thema der Norm berühren, berücksichtigt wurden. Man kann daher nicht vom Anwender verlangen, sich gegen die Norm zu stellen und in die Tiefen der Typografie einzusteigen. Wenn Typografen bemängeln, dass in einer solchen Norm die Typografie zu kurz gekommen ist, dann heißt das letztlich, dass die Typografie sich im Normgebungsprozess - der sogar relativ offen ist - nicht ausreichend eingebracht hat. Da die Normen aber ständig überarbeitet werden, bleibt zum Glück noch Hoffnung :-)
An dieser Stelle nutze ich die Gelegenheit, mich einmal direkt bei ihnen für das ansonsten wirklich tolle Paket KOMA-Script zu bedanken!
Wie oft eigentlich noch?
Wie oft muss ich eigentlich noch darauf hinweisen, dass es neben
toaddrhpos
auch nochtoaddrindent
gibt?Wie oft muss ich eigentlich noch darauf hinweise, auf welche DIN sich DIN.lco und DINmtext.lco beziehen?
Wie oft muss ich eigentlich noch darauf hinweisen, dass es in den Quellen ein experimentelles DIN5008.lco gibt?
Was die Kritik an den Typografen betrifft, die sich zu wenig in den DIN-Prozess einbringen? Ich habe bei mehreren Normen außerhalb des Dokument-Bereichs hautnah miterlebt, wie Normungsprozesse ablaufen. Wenn man nicht mehrere Gremiumsmitglieder einzeln überzeugt bekommt, dass ein Punkt wichtig ist, hat man ganz schlechte Karten. Keinesfalls darf man sich dabei auf ein anderes Gremiumsmitglied berufen. Stattdessen muss man im Hintergrund agitieren [ja, das Wort ist bewusst, an Stelle von agieren gesetzt]. Und dann muss man immer berücksichtigen, welches Ziel verfolgt wird.
Als ich vor einigen Jahren damit konfrontiert wurde, wie Anpassungen beispielsweise für den japanischen Markt vorzunehmen sind, war ich zunächst überrascht, wie deren Vielfalt an Papiergrößen und Umschlägen überhaupt zu bewältigen ist. Erst langsam wurde mir klar, dass Briefe in Japan als Ausdruck der Individualität gesehen werden und das die Kunst im Alltag dort eine größere Bedeutung hat. Gleichzeitig greifen Firmen dort wohl nicht beliebig zu irgendwelchem Papier und irgendwelchen Umschlägen. Wer Jahre lang dasselbe Format verwendet, für den spielt es keine Rolle, ob das genormt ist oder nicht. Ein gewisser Wunsch nach einem Mindestmaß an Individualität verbunden mit einem Wunsch nach einem Wiedererkennungswert ist auch hierzulande zu beobachten. Das habe ich auch schon mehrfach erwähnt. Und mal ehrlich: Die Post kommt bei uns sehr gut mit Briefen aus aller Herren Länder zurecht. Brauchen wir also tatsächlich eine Norm, die auf den mm genau festlegt, welches Element in welcher Größe wo zu stehen hat? Muss sich der Mensch in diesem Punkt wirklich bis ins letzte Detail der Maschine unterordnen?
BTW: Ich habe dieser Tage selbst seit langem mal wieder einen "Geschäftsbrief" verfasst. Standardkopf von KOMA-Script mit gesetztem
fromalign=left,fromemail
und DIN.lco. Hat alles perfekt in den Umschlag gepasst. Im Anschriftfenster war links mehr als genug Platz. Dagegen hat meine Adresse wie immer ganz schlecht in die Zeile für die Rücksendeadresse gepasst, weil nämlich kein Schwein bei der Namensgebung von Straßen und Orten darauf achtet, dass diese korrekt ausgeschrieben, korrekt nach DIN platziert werden können. Das führt hier übrigens auch immer wieder dazu, dass bei Sendungen, die ich erhalte, der Straßenname abgeschnitten und die Hausnummer nicht lesbar ist. Das ist ein Problem, das bisher keine DIN löst – bei Sendungen aus dem Ausland schon gar nicht aber auch nicht bei Sendungen aus dem Inland.Wenn bei der Angabe der Adresse bei einem Versender die Möglichkeit besteht, einen "Adresszusatz" anzugeben, schreibe ich da schon regelmäßig "Hausnummer 66" rein. Den Tipp habe ich mal vom Hermesboten bekommen. Früher habe ich da "Abgabe auch beim Nachbarn" eingetragen. Das machen aber hier die Paketboten normalerweise ohnehin. Gekürzter Straßenname ist hingegen oftmals nicht möglich, weil die Shop-Systeme die Straßennamen mit Datenbanken abgleichen und dann entweder automatisch ersetzen oder eine manuelle Korrektur fordern.
Ein gewisses Maß an Normung ist sicher sinnvoll, ein gewisses Maß an gesundem Menschenverstand, an Individualität und an Freiheit aber ebenfalls.
So schnell kann es passieren:
So schnell kann es passieren: Man denkt, endlich mal einen nützlichen Beitrag leisten zu können, und kurz darauf stellt sich heraus, dass man aus Unwissenheit lediglich altbekanntes wieder aufgewärmt hat.
Tut mir leid, dass ich vor dem Posten nicht die komplette Website studiert habe. Aber sie haben Recht, vieles von Ihren Hinweise findet sich auch in der KOMA-Script-Anleitung.
Da ich für das Ausprobieren der experimentellen DIN5008A.lco mit ihren Besonderheiten bezüglich der KOMA-Script-Version derzeit nicht die Zeit habe, habe ich meine Anpassung in der Präambel nach vorheriger Einbindung von DIN.lco entsprechend Ihrer Hinweise korrigiert:
Vielleicht hilft die Lösung ja trotzdem dem einen oder anderen pragmatischen Anwender, der sich via Suchmaschine hierher verirrt, so wie ich schon häufiger.
Kein Test → keine Release
Wenn es keiner testet, darf sich auch keiner beschweren, dass das nicht Bestandteil von KOMA-Script wird und die vorhandene DIN.lco angeblich Fehler hat.
Und wenn Du wirklich noch ein KOMA-Script < 3.17 verwendest, ist bei Dir ohnehin ein Update fällig.