Andreas Pakulat schrieb am 27.10.2005 00:30: > On 26.10.05 23:11:52, Christoph Bier wrote: > >>Andreas Pakulat schrieb am 26.10.2005 22:45: >> >>>On 26.10.05 20:21:52, Christoph Bier wrote:
[...] >>Ob das jetzt varioref ist oder nicht, sollte keine Rolle spielen. >>... Achso, du meinst wohl das mit den loops ... > > Jupp, waere mal interessant wenn du da ein Beispiel haettest, nur mal > zum Testen - mich interessiert sowas immer. Habe ich leider -- oder eher gottseidank -- nicht. Das ist ein recht lästiges Problem, das aber wiederum eher selten auftritt. Deshalb habe ich da jetzt kein Beispiel zur Hand. Es geht um den Fall, dass ein Verweis in der unmittelbaren Nähe eines Seitenumbruchs auftaucht. Dies kann dann dazu führen, dass durch die Verwendung von »auf der nächsten Seite« umbrochen wird und genau dieser Satz auf der besagten nächsten Seite landet, was natürlich falsch ist. Beim nächsten Übersetzen fällt der Hinweis »auf der nächsten Seite« folgerichtig weg, wodurch sich der Umbruch wieder ändert und der Hinweis richtig wäre ... Vielleicht kannst du dir ja selbst mal so ein Beispiel basteln. [...] >>Aber ist das wirklich so, dass teTeX ohne blindtext kommt? Zumindest >>für teTeX-3.0 kann ich mir das nicht vorstellen. Und dieses Upgrade >>empfehle ich dir. > > Ich fahre unstable, hab also seit dem Wochenende tetex-3.0 und da ist > kein blindtext.sty drin, jedenfalls hat latex das behauptet. Ok. Dann habe ich mich geirrt. [...] > Ach und noch was (was aber dein Emacs-Gespann sicher auch kann): Ich > kann auf die Fehler klicken und Kile schickt mich automatisch an die > richtige Stelle im Source ;-) Sehr handlich. Du klickst im Viewer auf einen Fehler und landest an der richtigen Stelle in Kile? Ja, das geht mit Emacs und DVI-Viewern auch. Aber da ich dieses Format schon lange nicht mehr nutze, spielt das für mich keine Rolle. Ich vermisse es auch nicht, da AUCTeX, wenn ein Fehler auftritt, sofort den Cursor an die entsprechende Stelle in der .tex-Datei setzt. Das funktioniert auch bei mehreren .tex-Dateien, die in das Master-File eingebunden per \input oder \include eingebunden werden. Und es werden sogar bei Bedarf .sty- oder .cls-Dateien geöffnet, wenn dort ein Fehler auftritt. [...] >>>BTW: blindtext mecker was von babel.sty an, aber ich nehme an das wuerde >>>er nur benutzten um fuer meine "locale" einen Text zu erzeugen? >> >>Was meinst du denn jetzt mit »locale«? > > Na die aktuelle Spracheinstellung, z.B. de_DE.UTF-8, damit koennte > \blindtext doch sicher einen dt. Text erzeugen. So nimmt er zufaellig > irgendeine Sprache... An dieser Info orientiert sich blindtext nicht. Wenn blindtext aufgrund fehlender Sprachinfos (babel) nicht weiß, welche Sprache verwendet werden soll, nimmt es einen Default, der wahrscheinlich deutsch ist, weil der Autor auch Deutscher ist. Obwohl ... in der Doku steht, es würde dann eine Zufallssprache ausgewählt ... bei mir ist diese aber immer deutsch. Merkwürdiger Zufall ;-). >>>mir kommts so vor als waere es deutlich langsamer als latex->dvi. >> >>Derartige Gerüchte kursieren immer mal wieder. Wenn du ernsthaft an >>einer Ursachensuche interessiert bist -- und die Zeitdifferenz das >>auch wirklich rechtfertigt --, sollten wir das in dctt weiter >>besprechen. > > Hmm, also ich bin momentan ein wenig im Stress, aber eigentlich > interessiert mich das schon. Schliesslich verlangsamt das meinen > Edit-View-Edit Zyklus doch ziemlich. Und DVI/PS Ausgabe ist nicht so > guenstig wenn man Bilder drin hat... Richtig. Mittlerweile hast du ja auch in dctt gefragt. Ich denke, wenn man Messungen mit einfachen, aber großen Dokumenten macht, dürfte der DVI-Output minimal schneller sein. Doch für mich ist das aus verschiedenen Gründen absolut vernachlässigbar. Ich schätze, dass bei vielen der Workflow, wie bei dir aussieht: DVI in der Entstehungsphase, PDF als Endformat. Aber mich nerven die DVI-Viewer. In einer bestimmten Entwicklungsphase verwende ich sogar den AR, weil ich dann im doppelseitigen Satz die gegenüberliegenden Seiten gleichzeitig betrachten kann. Außerdem verwende ich wie gesagt die mikrotypografischen Erweiterungen von pdf(e)TeX, deren Verwendung mit DVI zwar funktioniert, aber blödsinnig ist (die Festplatte wird mit bestimmten Font-Dateien vollgeschrieben). >>Es gibt aber natürlich Situationen, in denen tex -> pdf langsamer >>ist, was aber an erweiterten Fähigkeiten liegt (PNG-Einbindung, Font >>Expansion). Lässt man dies außen vor, sollte es mit aktuellen >>pdf(e)TeX-Versionen keine Unterschiede mehr geben. BTW: Die meisten >>TeX-Distributionen verwenden inzwischen pdfeTeX auch zur Erzeugung >>von DVI! > > Ja, so stehts im changelog von tetex-3.0 hier auch drin (hatte ich mich > erst noch gewundert drueber). Also ich mach mal fix mit ner Stoppuhr > nene Test fuer beides... > > pdflatex: 20 Sekunden, wobei die CPU-Belastung ziemlich hoch ist > latex->dvi: 3 Sekunden? Also wesentlich kuerzer Das ist schon erstaunlich und ausgesprochen deutlich! Solche Differenzen habe ich noch nicht beobachtet (aber auch nicht gezielt getestet). Ich habe auch keine Datei, mit der ich das testen kann, da überall Grafikformate eingebunden werden, die TeX nicht unterstützt. Kannst/willst du mir das Dokument mal per E-Mail schicken? Wenn nicht, dann vielleicht wenigstens die Präambel. Das interessiert mich jetzt auch. > Jeweils nur ein einfacher Durchlauf so dass keine Aenderungen dabei > waren. Ist vermutlich nicht so einfach zu vergleichen, weil ich vermute > dass der Aufwand fuer das DVI deutlich geringer ist als fuer das PDF. Wie auch immer: Meine Behauptung war, dass der Unterschied für einfache Dokumente (ohne Font Expansion, ohne optischen Randausgleich, ohne Grafiken) vernachlässigbar sei. 20 vs. 3 Sekunden sind nicht vernachlässigbar. [...] Grüße, Christoph -- +++ Typografie-Regeln: http://www.zvisionwelt.de/typokurz.pdf (1.4) -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject "unsubscribe". Probleme? Mail an [EMAIL PROTECTED] (engl)