Diskussion zu: "Tip: Fehlersuche" [Archiv]

lockstep

25-12-2009, 11:43

Zwei Änderungs- bzw. Ergänzungsvorschläge:

Statt "Bilder können ersetzt werden[...]" würde ich "Bilder sollten ersetzt werden[...]" schreiben. Die tatsächliche Bilddatei ist meistens nicht Ursache des Problems, ein \includegraphics ohne entsprechendes Bild ergibt jedoch kein lauffähiges Beispiel.
Ein Hinweis auf die filecontents-Umgebung wäre praktisch. Vielleicht etwa so (einzufügen nach dem Absatz über Bilder):
Wenn du in deinem Beispiel auf weitere Dateien zugreifen musst (häufig ist das eine bib-Datei, die als Literaturverzeichnis dient), kannst du diese Dateien mittels einer filecontents-Umgebung zum Teil deines Beispiels machen und potentiellen Helfern so einige Arbeit ersparen. Der Code dafür sieht so aus (einzufügen vor \begin{document}):

\usepackage{filecontents}
\begin{filecontents}{dateiname.bib}
(Inhalt der Datei)
\end{filecontents}

lockstep

Hobbes

25-12-2009, 18:56

Es ist zwar nur eine Kleinigkeit, sollte aber nicht unerwähnt bleiben: da fehlt ein Leerzeichen :)

Keiner ausserdem Fragesteller kennt das Dokument.

Xenara

25-12-2009, 20:53

@lockstep:
vielen Dank für die Anmerkungen.
Zum filecontents: Das ist so jetzt fast wortgenau aus deinem Vorschlag mit drin.
Zu den Bildern: Den Passus habe ich auf deine Anregung hin ziemlich überarbeitet. So müsst es klarer sein.

@Hobbes: Danke :o Ich bin um solche Hinweise echt froh, irgendwann sieht man es selber einfach nicht mehr...

voss

30-12-2009, 13:53

Es ist zwar nur eine Kleinigkeit, sollte aber nicht unerwähnt bleiben: da fehlt ein Leerzeichen :)

außer wird immer noch mit ß geschrieben ...

Herbert

lockstep

30-12-2009, 14:46

außer wird immer noch mit ß geschrieben ...

Da wir gerade dabei sind: Auch Spaß macht sich mit Doppel-s nicht so gut - das meinen sowohl die amtliche Schreibung in Deutschland (http://de.wikipedia.org/wiki/Spa%C3%9F) als auch ich als Wiener. :D

Xenara

30-12-2009, 15:21

Sorry, aber ich tippe den Text von der Schweiz aus, und da gibts nunmal überhaupt kein "ß".

Maverick

10-01-2010, 00:30

Klein, aber fein: Es heißt nunmehr Tipp (= neue Rechtschreibung), nicht mehr Tip (= alte Rechtschreibung).

lockstep

16-01-2010, 16:15

@bischi: Ich nehme an, du möchtest den ursprünglichen Thread schließen.

lockstep

bischi

17-01-2010, 00:13

@bischi: Ich nehme an, du möchtest den ursprünglichen Thread schließen.

Nö - sonst hätte ich es gemacht :D Aber danke für den Hinweis ;)

(Ich will ihn vorderhand nicht sperren, damit Xenara den Beitrag bei Bedarf verändern kann... Keine Ahnung, ob das bei gesperrtem Beitrag auch noch einfach ginge... Und solange kein Missbrauch betrieben wird :))

MfG Bischi

Xenara

17-01-2010, 11:38

Wenns zum Inhalt nichts gibt, kann man den Ausgangsthread gerne schliessen, von mir aus passt das mal soweit.

Edit: Grad noch die verschiedenen Komplierungsmöglichkeiten eingefügt (dvips, pdflatex) und die Erwähnung von BibTeX hat auch gefehlt.

Xenara

06-03-2010, 16:09

Habe noch den Hinweis auf das Löschen der von LaTeX erstellten Dateien eingefügt, Absatz "Von LaTeX erzeugte Dateien gelöscht?".

lockstep

06-03-2010, 16:19

Schon witzig - ein klassischer Stolperstein für LaTeX-Anfänger, den wir bis jetzt alle zu erwähnen vergessen haben.

lockstep

lockstep

08-03-2010, 17:25

voss

08-03-2010, 18:59

The EYE

08-03-2010, 19:05

Hallo!
Könnte man nicht auf \input{*.tex} ausweichen? ggf in Kombination mit % davor?

Gruß Max

P.S.: Dazu möchte ich sagen, dass es irgendwann natürlich zu umständlich werden würde...

Xenara

10-03-2010, 13:00

Aufgrund dieses (http://www.mrunix.de/forums/showthread.php?t=67624) Threads (insbesondere ab Beitrag Nr. 13) rege ich an, eine Anmerkung zu den Tücken von \include einzufügen. Ich bin mir zwar nicht sicher, wie oft dieser Befehl problematische Nebenwirkungen hat, aber aufgrund des Hinweises von Ulrike Fischer kann man durchaus auf \include verzichten.

Die Formulierung könnte etwa so lauten (Verbesserungsvorschläge erwünscht!): "Falls du Dateien mittels \include einbindest: Tritt der Fehler auch auf, wenn du die entsprechenden Textteile direkt in dein Hauptdokument einbindest?"

lockstep

Danke für den Hinweis. Ich werde versuchen, es in den Teil "Vom Dokument zum Minimalbeispiel" einzubauen, es fehlt nämlich tatsächlich noch ein Hinweis darauf, wie mit solchen inputs/includes umgegangen werden soll (unabhängig davon, ob sie der Fehler sind). Ich denke, dort kann man deinen Vorschlag gut unterbringen.

Dass include Probleme machen kann, wusste ich bisher noch nicht.
Soweit ich verstanden habe, ist input nur eine "Umleitung" im Code, während include auf einer neuen Seite anfängt und .aux-Dateien erzeugt.
Weshalb und in welchen Fällen kann es da zu Problemen mit include kommen? Wo liegen genau die Unterschiede? Das wäre für mich interessant zu wissen, damit ich den Text entsprechend korrekt anpassen kann.

LuPi

10-03-2010, 14:43

Diese Diskussion wurde schon verschiedentlich geführt, beispielsweise hier:
http://www.wer-weiss-was.de/theme155/article3325219.html

Vielleicht kannst Du da wesentliche Argumente übernehmen?

Für mich als Nicht-Guru bestehen die Unterschiede im Wesentlichen darin,
dass ich (a) \input's schachteln kann (im Gegensatz zu \include), (b) \include's immer eine neue Seite beginnen und (c) mir \include die Möglichkeit eines selektiven Vorgehens mittels \includeonly erlaubt.

BeniBela

10-03-2010, 20:36

voss

10-03-2010, 20:41

Es gibt anscheinend auch Unterschiede, ob die Logdatei zuverlässig von einem Programm ausgewertet werden kann, so dass auch alle gemeldeten Fehler der richtigen Datei zugeordnet werden.
Zumindest steht im Kile-Quellcode, dass man nicht \input, sondern entweder \Input (wohl noch eine dritte Variante) oder \include verwenden sollte.

Es gibt in LaTeX \include{Datei} und \input{Datei} und es gibt in
TeX \input Datei

Und die Fehldermeldungen sind eindeutig! Wenn GUIs zu blöd sind,
diese richtig zu interpretieren, dann sollte man eine andere wähken.

Herbert

voss

10-03-2010, 20:41

Dass include Probleme machen kann, wusste ich bisher noch nicht.
Soweit ich verstanden habe, ist input nur eine "Umleitung" im Code, während include auf einer neuen Seite anfängt und .aux-Dateien erzeugt.
Weshalb und in welchen Fällen kann es da zu Problemen mit include kommen? Wo liegen genau die Unterschiede? Das wäre für mich interessant zu wissen, damit ich den Text entsprechend korrekt anpassen kann.

Wieso soll \include Probleme machen?

Herbert

BeniBela

11-03-2010, 11:07

Es gibt in LaTeX \include{Datei} und \input{Datei} und es gibt in
TeX \input Datei

Und \Input aus srcltx.sty

Und die Fehldermeldungen sind eindeutig! Wenn GUIs zu blöd sind,
diese richtig zu interpretieren, dann sollte man eine andere wähken.

Das Problem sind wohl die Dateinamen. Bei \input schreibt TeX bei einer neuen Datei im Log "(dateiname" und nachdem alle Fehler in dieser Datei ausgegeben wurden, fährt es nach der Ausgabe einer schließende Klammer mit den Fehlern in der Datei mit dem \input fort.
Wenn die fehlerhafte Dokumentstelle jetzt aber eine ) enthält, gibt es im Log zu viele schließende Klammern und es ist nicht eindeutig, welche Klammer zum Text und welche zum Log gehört.

voss

11-03-2010, 14:01

Und \Input aus srcltx.sty

für LaTeX uninteressant ...

Das Problem sind wohl die Dateinamen. Bei \input schreibt TeX bei einer neuen Datei im Log "(dateiname" und nachdem alle Fehler in dieser Datei ausgegeben wurden, fährt es nach der Ausgabe einer schließende Klammer mit den Fehlern in der Datei mit dem \input fort.
Wenn die fehlerhafte Dokumentstelle jetzt aber eine ) enthält, gibt es im Log zu viele schließende Klammern und es ist nicht eindeutig, welche Klammer zum Text und welche zum Log gehört.

es bleibt trotzdem ein Problem der GUIs und nicht LaTeX, dass sie
das nicht vernünftig scannen können.

Herbert

Xenara

14-03-2010, 12:23

Aufgrund dieses (http://www.mrunix.de/forums/showthread.php?t=67624) Threads (insbesondere ab Beitrag Nr. 13) rege ich an, eine Anmerkung zu den Tücken von \include einzufügen. Ich bin mir zwar nicht sicher, wie oft dieser Befehl problematische Nebenwirkungen hat, aber aufgrund des Hinweises von Ulrike Fischer kann man durchaus auf \include verzichten.

Die Formulierung könnte etwa so lauten (Verbesserungsvorschläge erwünscht!): "Falls du Dateien mittels \include einbindest: Tritt der Fehler auch auf, wenn du die entsprechenden Textteile direkt in dein Hauptdokument einbindest?"

Die Anregungen zu input/include sind jetzt in der Anleitung (http://www.mrunix.de/forums/showthread.php?t=66921) unter "Vom Dokument zum Minimalbeispiel - Variante 1" -> Absatz "6." eingefügt.
Auf Erklärungen zu input/include habe ich verzichtet, da der Beitrag ja "nur" eine Anleitung sein soll, die Probleme einzugrenzen und ein Minimalbeispiel zu erstellen.

tral

16-03-2010, 08:36

Hallo,

mir ist gerade aufgefallen, dass es durch das Auskommentieren zu Missverständnissen kommen kann:

Z.B. hat jemand ein langes Dokument und kommentiert darin aus, um ein Minimalbesipiel zu erstellen. Anschließend kopiert er das in eine CODE-Umgebung und löscht dabei alle Kommentare, da die ja niemanden etwas angehen.

Das Problem daran ist, dass jetzt die Zeilenzähler der beiden Dokumente (MB mit und ohne Kommentare) verschieden sind, also z.B. log-Ausgaben nicht mehr so richtig verglichen werden können.

Vielleicht sollte das in der Anleitung zum Minimalbeispiel klarer gemacht werden...

Christian.

PS. Ach ja, fast vergessen ;)

\documentclass{article}

%\usepackage{usefulstuff}
\begin{document}
TEST \wrongCommand
\end{document}

führt zu:

! Undefined control sequence.
l.5 TEST \wrongCommand

, wohingegen

\documentclass{article}

\begin{document}
TEST \wrongCommand
\end{document}

ergibt:

! Undefined control sequence.
l.4 TEST \wrongCommand

bischi

16-03-2010, 09:26

Du musst halt die zum Beispiel passende Log-Datei mitposten - dann gibts auch kein Problem ;)

MfG Bischi

tral

16-03-2010, 09:30

Du musst halt die zum Beispiel passende Log-Datei mitposten - dann gibts auch kein Problem ;)

MfG Bischi

Doch! Ich poste meine log-Datei (Fehler in Zeile 5) und gebe aber die verkürzte Version als MB an. Dann ist es schwer, beim Testen des MB (Fehler in Zeile 4), dies in Übereinstimmung mit dem log-File zu bekommen!

Christian.

Xenara

16-03-2010, 09:38

Aber du testest doch das verkürzte MB nochmal, bevor du es ins Forum stellst. Du willst ja sichergehen, dass nicht versehentlich zu viel oder das Falsche gelöscht wurde, und ob der Fehler in genau diesem Code noch reproduzierbar ist.
Und du postest die zum _MB_ gehörende log-Datei, die bei dir entsteht und per Definition das Problem noch immer aufweist. Dann passts doch wieder.

Zitat aus dem Fehlersuche-Beitrag (http://www.mrunix.de/forums/showthread.php?t=66921):

Das fertige MB kompilierst Du dann und überprüfst, ob das Ergebnis (z.B. die Fehlermeldung) tatsächlich noch das gleiche ist wie beim Ausgangsdokument.
Und dann stellst Du diesen Code als Minimalbeispiel mit einer kurzen, aussagekräftigen Erklärung hier ins Forum.

Wenn der Fehler im MB gefunden ist, musst du sowieso die entsprechende Stelle im Ursprungsdokument finden und korrigieren.

voss

16-03-2010, 09:46

Doch! Ich poste meine log-Datei (Fehler in Zeile 5) und gebe aber die verkürzte Version als MB an. Dann ist es schwer, beim Testen des MB (Fehler in Zeile 4), dies in Übereinstimmung mit dem log-File zu bekommen!

Du gibst das Logfile passend zum MB an, sonst kannst du
dir auch alles sparen und Kommentare in einem Minimalbeispiel
sind nur dann von Interesse, wenn sie den Tester etwas zu sagen
haben.

Herbert

tral

16-03-2010, 09:52

Du gibst das Logfile passend zum MB an, sonst kannst du
dir auch alles sparen und Kommentare in einem Minimalbeispiel
sind nur dann von Interesse, wenn sie den Tester etwas zu sagen
haben.

Herbert

Ja, mir ist das schon klar. Aber ich glaube, halt anderen nicht. Und dann kann es zu Missverständnissen kommen. Siehe z.B. hier: http://www.mrunix.de/forums/showpost.php?p=310358&postcount=3 und meine Antwort...

War ja nur eine Anregung, das klar zu stellen...

Christian.

Xenara

16-03-2010, 10:17

Ich hab den Abschnitt im Anleitungsbeitrag leicht umformuliert, es gibt jetzt für einen bestehenden Absatz eine neue Überschrift "Wichtig: Wie kommts ins Forum?" und da ist auch der Umgang mit dem .log-File beschrieben.
Ist das so eindeutig?

Btw: Es wäre echt klasse, wenn es Rückmeldung von jemandem gäbe, der versucht hat, anhand der Anleitung ein MB zu erstellen, um Feedback von einem "Anwender" zu bekommen.

tral

16-03-2010, 10:26

Danke erstmal, Xenara.

Ich hab den Abschnitt im Anleitungsbeitrag leicht umformuliert, es gibt jetzt für einen bestehenden Absatz eine neue Überschrift "Wichtig: Wie kommts ins Forum?" und da ist auch der Umgang mit dem .log-File beschrieben.
Ist das so eindeutig?

Kleine Korrektur:

"das fix und fertige Minimalbeispiels"

Vielleicht könnte man auch schreiben:
"wenn Du exakt das Minimalbeispiels kompilierst, welches du im Posting verwendest."

Christian.

Xenara

16-03-2010, 10:42

Ok, danke, habs mit deiner Anregung umformuliert, es sollte jetzt klarer und einfacher sein.

rais

29-03-2010, 23:25

Moin moin,

\usepackage{filecontents}
\begin{filecontents}{dateiname.bib}
(Inhalt der Datei)
\end{filecontents}

irgendwie stell ich mir gerade so einen armen Tropf vor, der alles so macht, wie in Xenaras Anleitung beschrieben -- bis auf `backup' (wer backups macht, ist feige, oder?;-) und `neuen Ordner' ... und schwupps wird seine `dateiname.bib' überschrieben.
Dabei wird bereits im LaTeX-Kern eine filecontents-Umgebung definiert -- und die überschreibt nicht eine evtl bereits bestehende Datei.

@Xenara: ich würde zumindest darauf hinweisen, daß die filecontents-Umgebung des filecontents-Pakets eine ggf bereits vorhandene Datei gleichen Namens standardmäßig überschreibt ... oder \usepackage{filecontents} weglassen.
Davon abgesehen: Super Anleitung! :cool:

MfG

Xenara

30-03-2010, 06:53

irgendwie stell ich mir gerade so einen armen Tropf vor, der alles so macht, wie in Xenaras Anleitung beschrieben -- bis auf `backup' (wer backups macht, ist feige, oder?;-) und `neuen Ordner' ... und schwupps wird seine `dateiname.bib' überschrieben.
Dabei wird bereits im LaTeX-Kern eine filecontents-Umgebung definiert -- und die überschreibt nicht eine evtl bereits bestehende Datei.

Hi rais,
berechtigter Hinweis, danke. Ich werd eine Anmerkung dazu machen.
Aber: Es war durchaus Absicht, \usepackage{filecontents} mir reinzunehmen, _damit_ es überschrieben wird. Denn imho ist es tierisch lästig, wenn man an einem Literatureintrag was ausprobieren will, jedesmal in Explorer&Co. die entsprechende .bib-Datei zu suchen, "Löschen", "Ja, wirklich löschen", und dann kann man erst kann man ein simples Leerzeichen oder wasauchimmer einfügen.
Ausserdem (aus eigener Erfahrung) ist es als Anfänger unlogisch: Man macht eine Änderung, sie wird aber nicht umgesetzt... grosses Fragezeichen... und irgendwann kommt man drauf, dass die Datei ja gar nicht aktualisiert wird.

Und den Teil mit dem Backup werd ich vielleicht mal noch in fett, riesig und rot hervorheben. Eine überschriebene Filecontents-Datei ist sonst wohl noch das kleinste Problem.

voss

30-03-2010, 07:18

irgendwie stell ich mir gerade so einen armen Tropf vor, der alles so macht, wie in Xenaras Anleitung beschrieben -- bis auf `backup' (wer backups macht, ist feige, oder?;-) und `neuen Ordner' ... und schwupps wird seine `dateiname.bib' überschrieben.
Dabei wird bereits im LaTeX-Kern eine filecontents-Umgebung definiert -- und die überschreibt nicht eine evtl bereits bestehende Datei.

@Xenara: ich würde zumindest darauf hinweisen, daß die filecontents-Umgebung des filecontents-Pakets eine ggf bereits vorhandene Datei gleichen Namens standardmäßig überschreibt ... oder \usepackage{filecontents} weglassen.

es ist aber für den Anfänger genauso nervig, wenn er Änderungen
in seiner filecontents-Umgebung vornimmt und sich wundert, warum
ständig die alte Variante genommen wird ...
Das mögliche Überschreiben von Dateien ist immer gegeben, daher stellt
das Einbinden des filecontents-Paket kein wirkliches PRoblem dar,
sondern ist eher hilfreich!

Herbert

Xenara

30-03-2010, 07:31

Gut, dass du das auch so siehst, Herbert.

Ich hab jetzt in die Anleitung (http://www.mrunix.de/forums/showthread.php?t=66921) eine kleine Erläuterung zu den beiden Varianten und ihren Tücken aufgenommen und nochmal explizit die Sache mit dem Backup hervorgehoben.

Würdet ihr es kurz mal durchschauen?

u_fischer

30-03-2010, 10:06

Nun, ich empfehle:

Führe Tests (wie z.B. das Erstellen eines Minimalbeispiel oder das Ausprobieren eines Codes) nie mit deinem Originaldokument durch.
Ganz besonders dann nicht, wenn du den Code nicht wirklich verstehst.

Erzeuge stattdessen irgendwo einen Ordner "Test", fülle ihn mit einigen Beispieldateien (test.tex, testbild.eps, testbild.png, testbib.bib). Kurze Dokumente können einfach an den Anfang von test.tex kopiert und dann kompiliert werden. Für größere Tests kann man das Originaldokument als Ganzes in den Testordner kopieren und dann rumspielen.

LaTeX kann existierende Dateien überschreiben - es muss das können, um z.B. die toc-Datei immer wieder neu zu erzeugen. Denke also nach, bevor du neuen Code in dein Originaldokument kopierst, und mache regelmäßig Backups.

lockstep

31-03-2010, 19:46

Solltest du ein Literaturverzeichnis mit BibTeX erstellen wollen, musst du auch mit bibtex komplieren, und zwar in der Reihenfolge latex -> bibtex -> latex (ggf. dann mehrmals LaTeX).

An dieser Stelle sollte wohl auch makeindex erwähnt werden. Formulierungsvorschlag: "Ähnliches gilt für die Erstellung von Stichwortverzeichnissen, Glossaren und Abkürzungsverzeichnissen: Hier muss auch mit makeindex kompiliert werden - wie oft und in welcher Reihenfolge, entnimmst du den Dokumentationen zu den jeweiligen Verzeichnissen."

Übrigens heißt es kompilieren. ;)

lockstep

Xenara

01-04-2010, 13:16

Hi lockstep,

danke für den Hinweis, habs genau so eingebaut. Und den Rechtschreibfehler bei der Gelegenheit natürlich auch korrigiert.

rais

04-04-2010, 18:28

Moin Xenara,

Es war durchaus Absicht, \usepackage{filecontents} mir reinzunehmen, _damit_ es überschrieben wird. [...]

ah, Ok.
Konsequent wäre dann, \usepackage{filecontents} einkommentiert zu lassen.;-)

An dieser Stelle sollte wohl auch makeindex erwähnt werden. Formulierungsvorschlag: "Ähnliches gilt für die Erstellung von Stichwortverzeichnissen, Glossaren und Abkürzungsverzeichnissen: Hier muss auch mit makeindex kompiliert werden - wie oft und in welcher Reihenfolge, entnimmst du den Dokumentationen zu den jeweiligen Verzeichnissen."

vllt
"Ähnliches gilt für die Erstellung von Stichwortverzeichnissen, Glossaren und Abkürzungsverzeichnissen: Hier muss meistens auch mit makeindex kompiliert werden -- wie oft, in welcher Reihenfolge und womit (wenn überaupt) genau, entnimmst du den Dokumentationen zum jeweiligen Paket, mit dem du das entsprechende Verzeichnis erstellen willst."

Bei Verwendung von acronym (http://dante.ctan.org/tex-archive/help/Catalogue/entries/acronym.html) käme man ohne makeindex aus (und muß dafür selbst für die Sortierung sorgen), bei glossaries (http://dante.ctan.org/tex-archive/help/Catalogue/entries/glossaries.html) wird eigentlich das paketeigene makeglossaries-Skript empfohlen (und auch xindy (http://dante.ctan.org/tex-archive/help/Catalogue/entries/xindy.html) oder makeindex (http://dante.ctan.org/tex-archive/help/Catalogue/entries/makeindex.html) erwähnt) und bei gloss (http://dante.ctan.org/tex-archive/help/Catalogue/entries/gloss.html) wird BibTeX (http://dante.ctan.org/tex-archive/help/Catalogue/entries/bibtex.html) für die Sortierung verwendet.

Frohe Ostern

lockstep

04-04-2010, 18:44

@rais: Danke für den Hinweis! Mir war zwar bewusst, dass Pakete wie glossaries oder splitidx mit eigenen Skripten arbeiten (die MakeIndex/xindy mehrfach und/oder mit speziellen Parametern aufrufen), ich hatte es jedoch für vorrangig gehalten, MakeIndex überhaupt zu erwähnen. Angesichts der Arbeitsweise der Pakete acronym und gloss ist deine Formulierung sicher besser als meine.

lockstep

Xenara

04-04-2010, 19:45

Habs entsprechend abgeändert.

(Mal sehen, ob das Ding jemals absolut perfekt wird :D )

rais

04-04-2010, 20:06

Naja, für mich ist `Perfektion' analog zu einer e-Funktion, bei der das `Ziel' nie erreicht wird.;-)

MfG

Xenara

22-06-2010, 09:57

Hab noch einen Absatz eingefügt "Reihenfolge der Pakete überprüft?", vor allem in Hinblick auf hyperref.

lockstep

22-06-2010, 10:43

Der Hinweis auf hyperref ist essenziell! Hinzufügen könnte man noch - falls du das für wichtig genug hältst - folgendes (nach "(direkt vor \begin{document})"):

"Wichtigste Ausnahme (nach hyperref laden!) ist das Paket glossaries."

lockstep

Xenara

22-06-2010, 10:59

Danke für den Hinweis, ich habe es etwas umformuliert eingebaut.

voss

22-06-2010, 13:36

Danke für den Hinweis, ich habe es etwas umformuliert eingebaut.

es wäre besser, hier auf die README des hyperref-Pakets hinzuweisen,
in der alle bekannten Pakete aufgelistet werden, die mit
hyperref zusammenarbeiten und deren Ladereihenfolge dort angegeben
ist.

Herbert

lockstep

22-06-2010, 14:19

Das Paket glossaries wird allerdings in der hyperref-README (http://www.ctan.org/tex-archive/macros/latex/contrib/hyperref/README) nicht erwähnt. (Diese stammt aus März 2010, die glossaries-Einführung (http://ftp.univie.ac.at/packages/tex/macros/latex/contrib/glossaries/glossariesbegin.html) mit dem hyperref-Ladehinweis aus Mai 2010.)

lockstep

voss

22-06-2010, 15:09

Xenara

23-06-2010, 07:21

es wäre besser, hier auf die README des hyperref-Pakets hinzuweisen, in der alle bekannten Pakete aufgelistet werden, die mit
hyperref zusammenarbeiten und deren Ladereihenfolge dort angegeben
ist.

Ok, ist entsprechend umformuliert und ich hab wieder was gelernt. Aber wieso steht das in der README und nicht in der eigentlichen Doku? Auf die Idee, in einer README zu suchen, wäre ich pesönlich nicht gekommen.

sommerfee

23-06-2010, 07:27

Ich mag dem Hinweis "So muss etwa das häufig verwendete Paket "hyperref" in 95% der Fälle als allerletztes Paket direkt vor "\begin{document}" geladen werden." nicht zustimmen.

Es ist zwar richtig, daß hyperref - von Ausnahmen abgesehen - als letztes Paket geladen werden sollte, allerdings nicht direkt vor \begin{document}. Ganz im Gegenteil, in der Regel müssen die Makros der anderen Pakete NACH dem Laden von hyperref angewandt werden.

Beispiel "float-hyperref": Die richtige Reihenfolge ist \usepackage{float} - \usepackage{hyperref} - \newfloat{...}

Beispiel "chngcntr-hyperref": Die richtige Reihenfolge ist \usepackage{chngcntr} - \usepackage{hyperref} - \counterwithin{figure}{...}"

usw.

Der Grund sollte einleuchtend sein: Mit \usepackage{xyz} stellt das Paket xyz seine Makros bereit. Mit \usepackage{hyperref} patcht hyperref einige dieser Makros, wie z.B. \newfloat, \counterwithin usw. Erst danach sollten die (von hyperref gepatchten) Befehle angewandt werden.

Liebe Grüße,
Axel

Xenara

23-06-2010, 07:38

Nächster Versuch der Formulierung ;)

Und weitergehende Frage: Könnte man dann eigentlich pauschal sagen, dass als erstes alle usepackages geladen werden müssen, und anschliessend erst die ganzen Makros wie (re)newcommands, counterwithins, newfloats?

In manchem Code stehen die Makros direkt nach dem Paket, was insofern sinnvoll ist, dass alles, was zum Paket gehört, beisammen ist. Sollte man das dann auf jeden Fall vermeiden?

sommerfee

24-06-2010, 06:46

Und weitergehende Frage: Könnte man dann eigentlich pauschal sagen, dass als erstes alle usepackages geladen werden müssen, und anschliessend erst die ganzen Makros wie (re)newcommands, counterwithins, newfloats?

Wenn man hyperref lädt oder vorhat, es später mal hinzuzufügen, wäre es IMHO eine gute Idee. Wenn man nicht durchschaut, welches Kommando von welchem Paket (oder gar dem Kernel) hyperref genau warum patcht (und wer tut das schon außer Heiko Oberdiek ;) ), wäre man IMHO so zumindest auf der sichereren Seite, als wenn man es nicht so macht. "Bullet Proof" ist aber aber (natürlich) nicht.

In manchem Code stehen die Makros direkt nach dem Paket, was insofern sinnvoll ist, dass alles, was zum Paket gehört, beisammen ist. Sollte man das dann auf jeden Fall vermeiden?

Ich zumindest mache das so. Für die Beantwortung "Sollte man das denn auf jeden Fall vermeiden?" fühle ich mich nicht kompetent genug, ich kenne auch nur diejenigen hyperref-Internata, die im Zusammenhang mit floats/captions stehen. Ich würde aber mit "ja" antworten, wenn da "in der Regel" statt "auf jeden Fall" stehen würde.

Liebe Grüße,
Axel

P.S.: Die englischsprachige TeX-FAQ empfiehlt auch diese Vorgehensweise:

http://www.tex.ac.uk/cgi-bin/texfaq2html?label=hyperdupdest

Loomis

12-07-2010, 13:54

Vielen Dank für deine umfassenden Tips und Mühen, damit kann man sicherlich eine ganze Menge anfangen.
Nur ein Kommentar: ich arbeite seit knapp 2 Jahren mit dem TeXnicCenter und hab auch alles mal besser, mal schlechter allein bearbeiten können.
Jetzt habe ich mir leider das BuKoMa-Programm "aufschwatzen" lassen. - und seit dies geladen ist, funktioniert nichts mehr richtig. Bereinige ich einen "Error", kommt der nächste oder das Programm bricht ein.
Da lohnen alle Tips nichts mehr oder irgendwelche Fragen ins Forum zu stellen-ich käme aus der Fragerei gar nicht mehr heraus.
Mein altes File kann nicht mal mehr meine Grafiken lesen und bei den Bibl-Eintragungen gibt es Fehlermeldungen, die gar keine sind. Daraufhin kann man dann bei BuKoMa keine Einträge mehr machen usw. - ein Disaster!
Ich kann also nur allen von BuKoMa abraten!!
Gruß!
Angela

Post hierher verschoben

sommerfee

10-09-2010, 07:31

Mir ist gerade aufgefallen:

Hinweise und Tipps

a) Bilder:
Anstatt \includegraphics{Dein-Bild} verwendest Du bitte \rule{x}{y}, welches einen schwarzen Kasten einfügt.
Einfacher wäre es vielleicht, dem graphicx-Paket die Option "demo" zu geben.
Mit

\PassOptionsToPackage{demo}{graphicx}

am Anfang des Dokumentes zeigt das auch in den Fällen Wirkung, wo graphicx nicht selber, sondern in der Dokumentenklasse (z.B. beamer) bzw. durch ein Paket geladen wird.

Liebe Grüße,
Axel

Xenara

10-09-2010, 07:46

Hallo Axel,

stimmt, die demo-Option gibts auch noch. Ich nehmen sie gerne in die Anleitung mit auf, aber was mir nach wie vor nicht klar ist: Wie werden die Maße des "Bildes" bestimmt, wenn es jemand kompiliert, der das Bild eben nicht hat? Denn wenn es mit "scale=.5" oder "width=.3\textwidth" sind das ja keine Absolutwerte.

Den Vorteil von \rule sehe ich darin, dass der Fragesteller Maße wählen kann, die dem eigentlichen Bild nahekommen. (Und es ist ein Paket weniger nötig.)

Viele Grüsse,
Xenara

voss

10-09-2010, 07:59

stimmt, die demo-Option gibts auch noch. Ich nehmen sie gerne in die Anleitung mit auf, aber was mir nach wie vor nicht klar ist: Wie werden die Maße des "Bildes" bestimmt, wenn es jemand kompiliert, der das Bild eben nicht hat? Denn wenn es mit "scale=.5" oder "width=.3\textwidth" sind das ja keine Absolutwerte.

Den Vorteil von \rule sehe ich darin, dass der Fragesteller Maße wählen kann, die dem eigentlichen Bild nahekommen. (Und es ist ein Paket weniger nötig.)

Die Option demo war von mir vorrangig für den Fall vorgesehen,
wo der Fragesteller vergessen hat, seine Abbildung zur Verfügung zu stellen. demo berücksichtigt alle Angaben, die sich auf eine physikalische Größen beziehen. Alle relativen Größen, wie scale, beziehen sich auf die interne Vorgabe von \rule{..}{...}

Herbert