Sie sind hier

Option fontsize und externe .clo Dateien

Hallo Markus,

ich habe gerade etwas mit der Option fontsize probiert und dabei festgestellt, dass das Paket extsizes existiert, welches leider die Dateien

  • size8.clo
  • size9.clo
  • size14.clo
  • size17.clo
  • size20.clo

enthält, die bei der entsprechenden Einstellung für fontsize=*pt geladen werden. Das finde ich nicht so gut, lieber wäre es mir, wenn für diese Einstellungen KOMA-Script die Schriftgröße automatisch berechnen würde. Ich weiß nicht so recht, wie das ganze Problem gelöst werden könnte. Im einfachsten Fall müsste man wohl die Autoren anschreiben und darum bitten, dass sie ihre Dateien umbenennen. Aber sobald jemand anderes auf die Idee kommt, diese Dateien im Suchpfad anzulegen, taucht das Problem wieder auf. Bestünde die Möglichkeit, eine Option einzuführen, die das Laden von anderen Dateien außer scrsize*.pt unterbindet?

\documentclass[fontsize=14pt]{scrreprt}
\begin{document}
Text
\end{document}
Class scrreprt Info: File `size14.clo' used to setup font sizes on input line 2421.
(c:/texlive/2019/texmf-dist/tex/latex/extsizes/size14.clo
    File: size14.clo 1999/11/11 v1.4a NON-Standard LaTeX file (size option)
)

Grüße Falk

forum: 
Bild von Markus Kohm

Es ist auch dokumentiert. Du kannst allenfalls darauf ausweichen, Option fontsize=14pt erst (oder auch zusätzlich) nach dem Laden von scrreprt mit \KOMAoptions zu setzen. Bei \KOMAoptions wird nämlich niemals ein size*.clo-Datei geladen:

\documentclass[fontsize=14pt]{scrreprt}% Damit die Grundeinstellungen, die später nicht mehr geändert werden, trotzdem weitgehend passen.
\KOMAoptions{fontsize=14pt,DIV=last}% DIV=last, damit der Satzspiegel neu berechnet wird.
\begin{document}
Text
\end{document}

Oder du kannst mit scrfontsizes.sty eine scrsize14pt.clo generieren. Die enthält dann ebenfalls berechnete Werte und bekommt vor size14.clo den Vorzug.

Ich wollte nur sicher gehen, dass du einen potenziellen Konflikt mit extsizes kennst. Ich bin eigentlich auch bloß darüber gestolpert, weil extsizes die Längen \floatsep, \intextsep und \textfloatsep merklich kleiner definiert, als die von KOMA-Script berechnet werden. In der Schriftgröße fontsize=17pt beispielsweise:

Länge KOMA-Script extsizes
\floatsep 20.39995pt plus 3.40071pt minus 3.40071pt 15.0pt plus 4.0pt minus 4.0pt
\intextsep 20.39995pt plus 3.40071pt minus 3.40071pt 16.0pt plus 5.0pt minus 5.0pt
\textfloatsep 34.00063pt plus 3.40071pt minus 6.79926pt 25.0pt plus 5.0pt minus 5.0pt

Nur deswegen ist mir das überhaupt aufgefallen. Dennoch vielen Dank für deinen Vorschlag. Alternativ könnte ich ja auch so einen Quark wie fontsize=16.99999pt oder fontsize=17.00001pt machen ;)

Bild von Markus Kohm

Das ist so gewollt und in Kapitel 21.5 sogar explizit erwähnt.

Die dump von 10pt abgeleiteten Werte für fehlende Schriftgrößendateien können auch niemals mit handoptimierten Einstellungen mithalten. Wäre dem so, würde Word gute Arbeit leisten und Schriftgrößendateien wären insgesamt überflüssig. Theoretisch könnte man die Fallback-Lösung von KOMA-Script natürlich ebenfalls verbessern, indem man für alle Einstellungen eine Funktion einschl. Rundung definiert, statt einfach mit einem festen Faktor zu rechnen.

Ich hatte das Buch gerade nicht zur Hand, entschuldige den Lärm...

Dann hätte ich nur noch eine Frage, die Antwort darf gerne kurz ausfallen, ich will dich ja nicht um deine kostbare Zeit bringen. Gibt es einen Grund, warum \smallskipamount, \medskipamount, \bigskipamount und \abovecaptionskip bei der Fallback-Lösung nicht berechnet werden? Außerdem gibt es da noch \columnsep, was gegebenenfalls von typearea in Abhängigkeit von der Schriftgröße gesetzt werden könnte...

Bild von Markus Kohm

Als ich die scrsize*.clo-Dateien gebastelt habe, habe ich das auf Basis von size1[012].clo getan. In denen werden \(small|med|big)skipamount auf denselben Wert gesetzt (bei den extsizes-Dateien übrigens auch). Das ist außerdem derselbe Wert wie im LaTeX-Kern. Deshalb wurde das in scrsize*.clo wegoptimiert. \abovecaptionskip und \columnsep sind auch bei den Standardklassen unabhängig von der Schriftgröße. Als ich die Fallback-Lösung gebaut habe, habe ich mich an scrsize10pt.clo orientiert. Also enthält die Fallback-Lösung keine Einstellungen dafür.

Heute würde ich das eventuell anders machen. Ob ich aber \columnsep in typearea abhängig von der Schriftgröße ändern würde, bin ich mir nicht sicher. Denn eigentlich wird die optische Trennung der Spalten erst bei Schriftgrößen jenseits von Gut und Böse wirklich davon insoweit abhängig, dass man sie dann irgendwann tatsächlich vergrößern sollte, um das Ende der ersten Spalte beim Lesen deutlich zu erkennen. Beim Betrachten der Seite wäre hingegen schon ein erstaunlich kleiner Abstand hinreichend. Ich habe das einmal ausprobiert und kam sogar mit einem Abstand aus, der kleiner der normale Wortabstand ist. Eine durchgehende weiße Linie im Grauwert ist tatsächliche auch dann noch auffällig. Wenn man sich dem minimalen Wortabstand nähert wird es allerdings für mich langsam undeutlich. Allerdings habe ich das nicht durch Wahl eine großen Schrift, sondern durch Wahl eines kleinen Spaltenabstands getestet. Bei einer Schriftgröße, bei der der normale Spaltenabstand von 10pt problematisch werden könnte, dürfte der Umbruch der Spalten problematisch werden. Wenn da also tatsächlich für irgend eine Schriftgröße ein größerer Abstand erforderlich ist, dann sollte der Anwender sowohl diese Schwelle als auch den Wert selbst bestimmen.

Ich bin über die Problematik gestolpert, weil ich in meinem Bundle auch eine Klasse für Poster anbiete. Wenn diese zweispaltig im Papierformat A1 oder A0 erstellt werden, hantiert man mit Schriftgrößen von fontsize=16...32pt herum, wodurch besagte Längen dann schon angepasst werden sollten. Am besten macht man das natürlich manuell, aber ich wollte hierfür zumindest eine bessere Lösung anbieten, als bei den Standardeinstellungen zu bleiben. Das ist auch implementiert. Meine Frage war also eher aus eigenem Interesse motiviert.

Comments for "Option fontsize und externe .clo Dateien" abonnieren