Text wird vor Float über Seitenende geschoben

[Liberty]

Moin,

ich hab' jetzt schon ein paar Mal ein Problem gehabt, dass ich einfach nicht verstehe.

Wie im angehängten PDF zu erkennen, schiebt LaTeX ganz normalen Text vor einem float (ganz normale figure) über das Seitenende hinaus.

Den Eintrag im Log-File, den ich diesem Problem zuordnen kann ist:


Overfull \vbox (298.90425pt too high) has occurred while \output is active []

Kann mir jemand sagen, woran solche Probleme liegen können und wie ich sie beheben kann?

Vielen Dank schonmal im voraus!

Liberty

[u_fischer]

Du wirst schon den Code zeigen müssen.

[Liberty]

Moin,

der Code ist insgesamt 60KB, ich versuch mal, die relevanten Teile zu filtern:

Packages


\usepackage{amsfonts}
\usepackage{amsmath}
\usepackage{amssymb}
\usepackage{caption}
\usepackage{color}
\usepackage{fancyhdr}
\usepackage{fragmentation}
\usepackage{listings}
\usepackage[pdftex]{graphicx}
\usepackage{program}
\usepackage{hyperref}
\usepackage{longtable}
\usepackage{xcolor}


Figure


One concept that we introduced in some detail in Section \fragref{Bounds.Kolmogorov} of this thesis, but so far completely ignored in the discussion of the given example is Kolmogorov Complexity. It would be easy for us to simply refer to Theorem \fragref[theorem]{Bounds.Kolmogorov.NonComputability} and dismiss Kolmogorov Complexity as non-computable and thus completely irrelevant for the rather practical problem of compressing the given source string $s$. Furthermore, it would be valid to claim that Kolmogorov Complexity is of no significance in the scenario put forth in this section because the point of this example is to determine an optimal choice of parameters for a given algorithm, an optimisation problem that does not depend on the (universal) computer used to perform the actual compression.

\begin{figure}
\begin{lstlisting}[caption=ANSI C]
#include <stdio.h>
int main(int c,char* p[]) {
char* a = "abababababababababababcd";
char* b = "abcdcdcdcdcdcdcdcdcdcdcd";
printf("%s%s%s%s%s%s%s%s",a,b,b,a,a,b,b,a);
}
\end{lstlisting}
\hrule
\begin{lstlisting}[caption=Java]
public class C {
public static void main(String[] p) {
String a,b,c,d,e;
a = "ab";
b = "";
c = "cd";
d = "";
for (int i=0;i<11;i++) {
b += a;
d += c;
}
e = b+c+a+d+a+d+b+c;
System.out.print(e+e);
}
}
\end{lstlisting}
\hrule
\begin{lstlisting}[caption=Scala]
val a = "ab"*11+"cd";
val b = "ab"+"cd"*11;
print((a+b*2+a)*2);
\end{lstlisting}
\hrule
\begin{lstlisting}[caption=Python]
a = 'ab'*11+'cd';
b = 'ab'+'cd'*11;
print(a+b*2+a)*2
\end{lstlisting}
\hrule
\vspace*{10pt}
\centering
\begin{footnotesize}
\begin{longtable}{|l|r|rr|r|}
\hline
~&\multicolumn{4}{|c|}{\textbf{Program Size}}\\
\textbf{Language}&\textbf{Source}&\multicolumn{2}{|c|}{\textbf{Intermediate}}&\textbf{Machine Code}\\
\hline
ANSI C&160&Assembler:&971&8,498\\
Java&168&Byte Code:&782&n.a\\
Scala&57&Byte Code:&1,679&n.a\\
Python&46&~&n.a.&n.a\\
\hline
\end{longtable}
\end{footnotesize}
\caption{Examples of short programs that generate $s$. The listings in this figure are arranged for readability. The length (in bytes) of the source code, however, refers to the source code without any unnecessary line-breaks and spaces.}\fraglabel[figure]{Bounds.Example.Programs}
\end{figure}

Although Kolmogorov Complexity is a theoretical concept that does not provide any guidance for the optimal choice of $k$ in the given scenario, we could not resist the temptation to collect a few examples of short programs that produce $s$. In order to enable a fair comparison of the lengths of the different programs, we require that all of them produce $s$ to the standard output stream of the operating system. The programs we devised in the four different programming languages ANSI C, Java, Scala and Python\footnote{The Python program was kindly provided by Teemu Roos, PhD, University of Helsinki, Finland.} are given in Figure \fragref[figure]{Bounds.Example.Programs} along with their respective sizes both as source code as well as -- where applicable -- intermediate code and compiled machine code.


Mein Gefühl sagt mir, dass es eigentlich nur an der Figure liegen kann, denn das Problem trat erst auf, als ich diese Figure nachträglich eingefügt habe.

Liberty

P.S.: Zur Sicherheit habe ich nochmal den gesamten Code des Dokuments angehängt.

[u_fischer]

Dein Text benutzt ein Paket (fragmentation), das ich nicht kenne und nicht habe. Wenn ich das rauschmeiße und alle Fehlermeldungen ignoriere, gibt es keine Probleme.

[Liberty]

Moin,

fragmentation ist Eigenbau um Dokumentteile mit angepasten Gliederungsebenen einbinden zu können, das Paket brauch ich. Da ich das Paket selbst geschrieben habe, muss ich gleich selbst mal schauen, was das Problem sein könnte.

Liberty

[Liberty]

Moin,

@u_fischer: Wie darf ich das verstehen, dass Du das fragmentation-Paket herausgenommen hast? Meinst Du, dass Du den kompletten Fragmentinhalt ins Hauptdokument kopiert hast? Das habe ich jetzt auch mal getan und das Problem ist dadurch nicht gelöst.

Da ich zugegebermaßen nicht daran gedacht habe, dass ich ein eigenes Paket verwende und auch noch zwei Diagramme zum Kompilieren benötigt werden, die ich ebenfalls nicht mitgeliefert habe, habe ich jetzt das Problem nochmal so aufbereitet, dass es bei jedem kompiliert werden sollte.

Ich habe darüber hinaus festgestellt, dass das Problem verschwindet, wenn ich die figure in den Zeilen 440-454 auskommentiere, ich kann jetzt aber auch bei der figure keinen Fehler entdecken.

Für weitere Lösungsansätze wäre ich sehr dankbar!

Liberty

[nixversteh]

Hallo Liberty,

warum stellst dein fragmentation-Paket nicht hier ein?

Lieben Gruß

Martin

[Liberty]

Moin,

ich habe jeden Einfluss des fragmentation-Pakets in meinem letzten Post entfernt, so dass ich ausschließen kann, dass das Problem dadurch entstanden ist (das Problem ist ja schließlich noch da :) )

Ich hab' trotzdem mal das Paket hier angehängt, ist aber ausdrücklich nur für meinen Hausgebrauch gedacht.

Liberty

[u_fischer]

Wie darf ich das verstehen, dass Du das fragmentation-Paket herausgenommen hast? Meinst Du, dass Du den kompletten Fragmentinhalt ins Hauptdokument kopiert hast?

Nein, ich hatte einfach das Paket auskommentiert und dann kompiliert (und alle Fehler einfach ignoriert).


habe ich jetzt das Problem nochmal so aufbereitet, dass es bei jedem kompiliert werden sollte.

Du solltest keine longtable-Umgebung in einer figure-Umgebung benutzen. Die ist dort sinnlos und führt nur zu Ärger. Ersetze sie durch tabular.

[Liberty]

Moin,


Du solltest keine longtable-Umgebung in einer figure-Umgebung benutzen. Die ist dort sinnlos und führt nur zu Ärger. Ersetze sie durch tabular.

Danke! Das Problem ist in der Tat verschwunden, wenn ich eine normale tabular-Tabelle statt der longtable (die Tabelle war ursprünglich außerhalb der figure) verwende.

Liberty