[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: LaTeX-IDE (war: Re: Paketkonfiguration)



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)



Reply to: