Sie sind hier

Startseite › forum › KOMA-Script › Anwender braucht Hilfe

typearea: DIV noch feiner einstellen

Mi, 2015-03-25 20:53 — fgrammel

Bei einer Buchserie, die bisher erfreulicherweise mit einem großzügigen „classic“ Satzspiegel (entspricht für dieses Format DIV=8) gesetzt werden konnte, soll jetzt doch ein wenig Platz gespart werden; die Rede war von einer Zeile mehr pro Seite. Wenn ich nun DIV=9 setze, bekomme ich zwei extra Zeilen und eigentlich ist mir die Zeilenlänge (80 Zeichen) auch schon wieder zu lang.
Natürlich kann ich die berechneten Maße aus dem Log übernehmen, mit geometry einstellen und leicht variieren, bis es nach Augenmaß passt. Oder sogar nach \recalctypearea mit \addtolength{\textheight}{\baselineskip} das ausgezirkelte Gleichgewicht zerdeppern, aber schnell und einfach die Redaktion zufrieden stellen.

Viel lieber würde ich DIV auf 8.5 setzen, was aktuell nicht geht. Zwar lässt sich das nicht sonderlich gut mit den gedachten Streifen auf dem Papier visualisieren, aber rechnen lassen müsste sich das doch, oder?

Eine noch weitergehende Idee wäre, wenn typearea mit anderen Werten als DIV gefüttert werden könnte, also daß man z. B. die gewünschte Anzahl Zeilen (oder die gewünschte Zeilenlänge) angibt und dann der beste DIV-Wert errechnet und festgelegt wird.

forum: 
Anwender braucht Hilfe
Do, 2015-03-26 01:50 — esdd

Wenn ich nichts übersehen habe, dann lässt sich die gewünschte Anpassung mit \areaset vornehmen:

\documentclass[DIV=classic,BCOR=15mm]{scrbook}
\areaset[current]{%
  \dimexpr\textwidth*(\textheight+\baselineskip)/\textheight\relax%
  }{%
  \dimexpr\textheight+\baselineskip\relax%
}
 
\usepackage{blindtext}
\begin{document}
\blindtext[10]
\end{document}

Gruß
Elke

Do, 2015-03-26 09:06 — Markus Kohm
Bild von Markus Kohm

Ich würde empfehlen, zusätzlich die noch nicht offiziell dokumentierte Option areasetadvanced (siehe Releaseinfos zu Version 3.11) zu verwenden.

Do, 2015-03-26 15:02 — fgrammel

Vielen Dank für die Hilfestellungen!

Interessanterweise funktioniert Dein Vorschlag, wenn headinclude=false ist, aber er verkürzt und verbreitert(!) den Satzspiegel bei headinclude=true. Da sind offensichtlich deutlich mehr Rücksichten nötig, als bei einem recht umfangreichen existierenden Layout praktisch wären.

Ich werde also -- mit Markus' Segen -- die eine Zeile manuell hinzufügen.

—

Florian Grammel
Kopenhagen, Dänemark

Fr, 2015-03-27 10:28 — esdd

Stimmt, an die Möglichkeit, dass headinclude=true gelten könnte, habe ich nicht gedacht. In dem Fall gehört die Kopfzeile zum Satzspiegel und der ist damit vor der Änderung höher als \textheight. Das erklärt beide von Dir beschriebenen Auswirkungen.

Do, 2015-03-26 09:09 — Markus Kohm
Bild von Markus Kohm

Eine einzelne Zeile mehr, liegt mehr oder weniger im Toleranzbereich der Rundung auf ganze Zeilen. Man könnte daher einfach

\AfterCalculatingTypearea{\addtolength{\textheight}{\baselineskip}}
\recalctypearea

verwenden, um den Textbereich eine Zeile höher zu machen.

Do, 2015-03-26 09:11 — Markus Kohm
Bild von Markus Kohm

Ich habe schon früher mal über gebrochene Werte für DIV nachgedacht. Allerdings würde das sehr dem Prinzip der Rasterkonstruktion widersprechen, das dem ganzen zugrunde liegt. Daher habe ich die Idee nach längerer Überlegung verworfen.

Do, 2015-03-26 13:11 — fgrammel

Schade, aber Deine Begründung ist ja einleuchtend.

Obwohl ... wäre nicht beispielsweise DIV=8.5 entsprechend der Aufteilung auf 17 Rasterstreifen, bei der dann innen und oben je zwei, außen und unten je vier Streifen den Randbereich bestimmen? Also DIV=17 und Ränder * 2?
Wenn ich das richtig verstehe, dann könnte man ja zumindestens theoretisch alle nicht ganzen DIV-Werte in ein Raster umsetzen und (mit viel gutem Willen) dafür argumentieren, daß solche Werte trotzdem sinnvoll wären...

—

Florian Grammel
Kopenhagen, Dänemark

Do, 2015-03-26 14:11 — Markus Kohm
Bild von Markus Kohm

Die Rasterkonstruktion ist wesentlich weiter reichender. Im anspruchsvollen Buch- und Zeitschriftensatz wendet man das Raster nicht nur auf die Ränder an und schlägt dann den Rest dem Text zu. Auch Objekte wie Bilder oder Tabellen richten sich danach und sollen zumindest in der Breite immer ganze Teile des Rasters umfassen. Wie soll das nun gehen, wenn irgendwo ein 7/13tel Streifen herumgeistert? Und das ist nur eines der entstehenden Probleme.

Ich bin mit der Idee vom Beginn des großen Codeumbaus (AFAIR 2002) bis zur Release von KOMA-Script 3.0 Ende 2008 herumgelaufen und habe sie hin- und her gewälzt. Ich hatte sogar schon erste Code-Teile dafür implementiert. Ich habe das also nicht leichtfertig oder aus Faulheit verworfen.

Die Berechnung, die typearea verwendet, ist gut dokumentiert. Wenn jemand also einen Satzspiegel und Ränder für ein 17⅗-Raster berechnen will, dann kann er das tun und das Ergebnis per geometry oder sonst irgendwie realisieren.

Do, 2015-03-26 16:33 — fgrammel

Danke für die Erläuterung!

Daß diese Einteilung für einen richtigen Raster-Satz Bedeutung hat, hatte ich ausgeblendet, da ich den Eindruck habe, daß keine der verfügbaren Lösungen so richtig ready for showtime ist und deshalb kein grid verwende, auch wenn ich sehr gerne würde.
Aber daß Du nicht zukünftige Entwicklungen verbauen willst, verstehe ich natürlich.

—

Florian Grammel
Kopenhagen, Dänemark

Do, 2015-03-26 22:57 — dila

Auch Objekte wie Bilder oder Tabellen richten sich danach und sollen zumindest in der Breite immer ganze Teile des Rasters umfassen. Wie soll das nun gehen, wenn irgendwo ein 7/13tel Streifen herumgeistert?

Den Einwand verstehe ich grad nicht ganz. Das wären ja dann einfach 7 Streifen, oder nicht?

Fr, 2015-03-27 07:32 — Markus Kohm
Bild von Markus Kohm

Ich denke, es ist klar worum es geht: Ein Raster macht nur Sinn, wenn alle Streifen gleich breit sind.

Vielleicht können wir das Thema damit abschließen. Ich habe eigentlich wenig Lust, die Diskussion, die ich über Monate und Jahre mir mir selbst geführt habe, noch einmal als Schaukochen durchzuziehen.

Fr, 2015-03-27 14:26 — dila

Gleich breit wären die Streifen ja.

Aber ich wollte auch gar nicht sagen, daß man es so machen sollte. Ich verstehe nur nicht, warum das mit Bildern und Tabellen nicht hinhauen sollte.

Comments for "typearea: DIV noch feiner einstellen" abonnieren

Der Inhalt dieser Seiten ist urheberrechtlich geschützt. Warenzeichen und sonstige Schutzmarken werden ausschließlich zu Zwecken der Information über selbige, sowie deren Rechteinhaber und den damit verbundenen Produkten verwendet. Siehe auch das Impressum mit der Erklärung zum Datenschutz.

Powered by Drupal