LaTeX Forum

Hallo,

ich habe eine Garamond, die mit der Option [osf] für’s ganze Dokument Minuskelziffern bietet.

Ausschließlich für die Seitenzahlen möchte ich jedoch Majuskelziffern nehmen. Ich weiß mir momentan nicht anders zu helfen als für die nicht benötigte Typewriter meine Garamond/Majuskelz. zuzuweisen, und diese dann für die Seitenzahlen zu gebrauchen:

\renewcommand{\ttdefault}{5gm}
\setkomafont{pagenumber}{\ttfamily}

Damit erhalte ich für die fortlaufenden Seitennr. das gewünschte Ergebnis, aber im Inhaltsverzeichnis bleiben die Ziffern hinter den Abschnittsüberschriften unverändert als OSF.

Anbei mal ein Beispiel für meine Präambel, auch wenn jemand den Font nicht bei sich drauf hat:

\documentclass[paper=a5]{scrartcl}
\usepackage[T1]{fontenc}
\usepackage[german]{babel}
\usepackage[osf]{garamond}
\usepackage{lipsum}

\renewcommand{\ttdefault}{5gm}
\setkomafont{pagenumber}{\ttfamily}

\makeatletter
\renewcommand*\l@section{\@dottedtocline{1}{0em}{2.2em}}
\makeatother

\begin{document}
\tableofcontents

\section{Abschnitt}\lipsum[2-3]0123456789
\section{Abschnitt}\lipsum[2-3]
\section{Abschnitt}\lipsum[2-3]
\section{Abschnitt}\lipsum[2-3]

\end{document}

Ich vermute, es hat etwas mit der Abschnittsformatierung für \section zu tun, die ich für meine Bedürfnisse angepaßt habe. Oder ich bin mit \ttfamily den falschen Weg gegangen. Kann mir bitte jemand weiterhelfen?

Vorab: Ich habe weder das gleiche Garamond-Paket noch die Schrift, so dass ich keine fertige, getestete Lösung bieten kann.

Wenn alle Seitenzahlen, auch die in den Referenzen, in Majuskel-Ziffern gesetzt werden sollen (was einigermaßen eigenartig aussehen dürfte), dann könnte man einfach \thepage umdefinieren (bitte kein Klammernpaar weglassen!):

\renewcommand*{\thepage}{{\fontfamily{5gr}\selectfont\arabic{page}}}

Dabei gehe ich davon aus, dass 5gr die Familie ist, bei der tatsächlich Majuskel-Ziffern verwendet werden.

Sollen nur die Seitenzahlen in der Paginierung in Majuskel-Ziffern gesetzt werden, würde ich mir eigentlich keinen Kopf über die Ziffern im Inhaltsverzeichnis machen. Das sind ja eigentlich auch nur Referenzen. Ansonsten kann man natürlich auch dort lokal die Familie umschalten, also etwas wie:

\begingroup% Umschaltung lokal halten
\fontfamily{5gr}\selectfont
\tableofcontents
\endgroup

Das funktioniert natürlich nur, wenn im Inhaltsverzeichnis nicht \normalfont verwendet wird. Sollte das der Fall sein, muss man zusätzlich lokal \familydefault (siehe dazu beispielsweise die De-TeX-FAQ) umdefinieren.

Etwas sauberer wäre die Lösung wohl mit tocbasic (Beta-Paket bei neueren KOMA-Script-Versionen) zu machen, weil man dort einstellen kann, mit welcher Schrift die Seitenzahl und nur diese gesetzt werden soll.

Näheres zu \fontfamily ist dem fntguide zu entnehmen, der verpflichtender Bestandteil jeder zulässigen LaTeX-Verteilung ist.

KOMA hat geschrieben:

\renewcommand*{\thepage}{{\fontfamily{5gr}\selectfont\arabic{page}}}

Danke für diese Zeile, damit bekomme ich es hin.

Ich stehe mit einem neuen Phänomen vor einem Rätsel, das allerdings nichts mit den Seitennummern zu tun hat: scrreprt mit DIV12 bringt mir pdflatex zum Absturz, allerdings nicht bei DIV11, 13 und calc (14).

Das ist für mich merkwürdig, ausgerechnet ein Wert mittendrinn; und ich kann mich nicht an das Update erinnern, seitdem das eingetreten ist, da ich das Dokument einige Zeit habe ruhen lassen ...

Jean-Marc hat geschrieben:Ich stehe mit einem neuen Phänomen vor einem Rätsel, das allerdings nichts mit den Seitennummern zu tun hat: scrreprt mit DIV12 bringt mir pdflatex zum Absturz, allerdings nicht bei DIV11, 13 und calc (14).

Es wäre schön, wenn Du nächstes Mal für ein neues Thema auch wirklich ein neues Thema eröffnen würdest, damit andere Anwender dieses Thema ggf. auch finden.

Dessen ungeachtet halte ich es für extrem unwahrscheinlich, dass die gleiche Berechnung mit minimal anderen Werten pdfLaTeX wirklich zum Absturz bringen kann. Überhaupt sollten Pakete nicht in der Lage sein, pdfTeX zum Absturz zu bringen. Das schlimmste, was auf Makroebene möglich ist, sind Endlosschleifen. Alles andere sollte pdfTeX immer in einen definierten Zustand - ggf. ein Fehlerzustand mit vorheriger Fehlermeldung - versetzen. Ist dem nicht so, ist pdfTeX selbst defekt.

Es wäre deshalb schön, wenn Du angeben würdest, was denn genau passiert. Sollte tatsächlich pdfTeX vom System mit einer System-Fehlermeldung (beispiesweise "Segmentation fault" oder "Speicherschutzverletzung" o. ä.) beendet werden, dann kann ich Dir jetzt schon sagen, dass typearea daran unschuldig ist. In dem Fall solltest Du Dich an den Distributor Deines TeX-Systems wenden. In allen anderen Fällen benötige ich ein vollständiges Minimalbeispiel und ggf. die Versionsinformation von typearea.sty aus der log-Datei. Bei mir funktionieren DIV12 und DIV=12 nämlich korrekt.

Ich muss allerdings auch sagen, dass bei mir vor kurzem pdflatex rekonstruierbar bei einem bestimmten code abgestürzt ist, sobald ich microtype die Option spacing=true übergeben habe. Allerdings nur bei der Serienbrieferstellung o_O
Kann den Code allerdings glaub ich nicht mehr rekonstruieren...

EDIT: Ha, doch kann ich... ich versuch mich mal an einem Minimalbeispiel

Das scheint bei mir an der Kombination der scrlttr2-Option fromrule=aftername, dem MinionPro-Paket, der Verwendung von
\addtokomafont{fromname}{\sffamily}
\addtokomafont{fromaddress}{\sffamily}
,der Serienbrieffunktion und der footseperated.lco (definiert firstfoot um) zu liegen...
Keine Ahnugn worans liegt, sobald ich eine der Ursachen entferne läuft es wunderbar wies soll

Genmutant hat geschrieben:Ich muss allerdings auch sagen, dass bei mir vor kurzem pdflatex rekonstruierbar bei einem bestimmten code abgestürzt ist

Ich weiß jetzt noch immer nicht, was unter "abgestützt" gemeint ist. Deshalb wiederhole ich:

KOMA hat geschrieben:Es wäre deshalb schön, wenn Du angeben würdest, was denn genau passiert.

Genmutant hat geschrieben:sobald ich microtype die Option spacing=true übergeben habe. Allerdings nur bei der Serienbrieferstellung o_O
...
EDIT: Ha, doch kann ich... ich versuch mich mal an einem Minimalbeispiel
Das scheint bei mir an der Kombination der scrlttr2-Option fromrule=aftername, dem MinionPro-Paket, der Verwendung von
\addtokomafont{fromname}{\sffamily}
\addtokomafont{fromaddress}{\sffamily}
,der Serienbrieffunktion und der footseperated.lco (definiert firstfoot um) zu liegen...
Keine Ahnugn worans liegt, sobald ich eine der Ursachen entferne läuft es wunderbar wies soll

Bei mir stürzt da gar nichts ab. Außerdem wiederhole ich auch für den Fall, dass tatsächlich pdfTeX abstürzen sollte:

KOMA hat geschrieben:Sollte tatsächlich pdfTeX vom System mit einer System-Fehlermeldung (beispiesweise "Segmentation fault" oder "Speicherschutzverletzung" o. ä.) beendet werden, dann kann ich Dir jetzt schon sagen, dass typearea daran unschuldig ist. In dem Fall solltest Du Dich an den Distributor Deines TeX-Systems wenden.

Und noch einmal: So wie der C-Source unschuldig ist, wenn der C-Compiler beim Compilieren abstürzt, so ist auch der LaTeX-Quelltext unschuldig, wenn pdfTeX abstürzt. TeX selbst ist auch so fehlerfrei, dass es nicht abstürzt. Wenn also pdfTeX abstürzt, dann liegt entweder ein Fehler in pdfTeX selbst vor oder der Distributor hat einen Fehler eingebaut. Da Anwender das nicht entscheiden können, sollte sich der Anwender in jedem Fall unbedingt an den Distributor seines TeX-Systems wenden. Der kann das dann prüfen und ggf. an die pdfTeX-Entwickler weiterleiten oder den Fehler selbst beseitigen. Die Paketautoren sind jedoch die falschen Ansprechpartner. Selbst wenn ein Paketautor etwas wie

\divide \hsize by 0

macht, dann führt das nicht zu einem Absturz von (pdf)TeX, sondern nur zu:

\divide\hsize by 0
! Arithmetic overflow.
<*> \divide\hsize by 0

? h
I can't carry out that multiplication or division,
since the result is out of range.

Und im batch- oder runstop-Modus macht TeX dann einfach weiter.

Unter abstürzen verstehe ich in diesem Fall:

pdflatex.exe hat ein Problem festgestellt und muss beendet werden.

Dass da der Code nix kaputt machen sollte ist mir klar.
Ich verwende übrigens: MiKTeX 2.7 mit aktuellen Paketen und TeXniCcenter (was egal sein sollte) unter Windows XP.

Meine .log Datei sagt auch nichts aus, die hört einfach auf:

...
Package microtype Info: Generating PDF output.
Package microtype Info: Character protrusion enabled (level 2).
Package microtype Info: Using default protrusion set `alltext'.
Package m

Naja, vielleicht kann ja jemand den Fehler mit MiKTeX 2.7 reproduzieren, ansonsten geh ich davon aus dass da bei mir der Wurm drinnen ist.

Genmutant hat geschrieben:Naja, vielleicht kann ja jemand den Fehler mit MiKTeX 2.7 reproduzieren, ansonsten geh ich davon aus dass da bei mir der Wurm drinnen ist.

Ich habe MikTeX nochmal neuinstalliert, alles bis auf die *.tex im Ordner gelöscht und dann hat es beim 2. Durchlauf wieder gekracht.

Darauf habe ich in der Klassenoption a5,11pt,final zu paper=a5,fontsize=11pt,draft=false geändert und plötzlich lief’s durch. Kann mir keinen Reim drauf machen, Hauptsache wir vertragen uns wieder miteinander.

Jean-Marc hat geschrieben:Hauptsache wir vertragen uns wieder miteinander.

Das ist eher eine Nebensache.

Versucht bitte das Problem möglichst eng einzugrenzen und wendet Euch dann an den MikTeX-Autor. Fehler gehören behoben. Es mag für Euch schön sein, wenn Ihr herausfindet, wie Ihr das Problem umgehen könnt. Eine Lösung ist das aber nicht. Natürlich kann ich, wenn es in meinem Keller von der Decke tropft, erst einmal einen Eimer drunterstellen. Zusätzlich sollte ich dann aber herausfinden, wo das Wasser herkommt und die Ursache beheben (lassen).

LaTeX Forum

Für alle Seitenzahlen Majuskelziffern verwenden

Für alle Seitenzahlen Majuskelziffern verwenden

Kann typearea pdfLaTeX zum Absturz bringen?