Am Tag 06-08-08 zur Zeit 17:18:08 schrieb Johannes Engel:

Hannes Vogelmann schrieb:

...

Moin,

ich habe mal wieder eine LaTeX-Frage: Bisher ist es mir noch nie aufgefallen, aber da ich für eine Fachzeitschrift die egu.cls - Klasse verwenden muss, fällt es mir jetzt auf, dass seit der SuSE 9.3 ein anderes LaTeX geliefert wird. Die egu-Klasse verlangt ein LaTeX 2e als Umgebung.

Meldet sich LaTeX hier (SuSE 9.2) mit

This is TeX, Version 3.14159 (Web2C 7.4.5)

kommt bei SuSE9.3 die Meldung

This is pdfeTeX, Version 3.141592-1.21a-2.2 (Web2C 7.5.4)

bei SuSE 10.0 verhält es sich ähnlich.

Leider funktioniert die egu.cls mit pdfeTex nicht, wenn es um die Grafikeinbindung geht. Eps-Dateien werden plötzlich abgelehnt. Außerdem wird kein dvi-file erzeugt sondern ein pdf. Allerdings passiert das nur bei Verwendung der egu-Klasse. Bei anderen Klassen scheint alles wie gewohnt zu laufen, weshalb mir das auch nie aufgefallen ist.

Kann mir jemand sagen, was zu tun ist, damit pdfeTeX wieder kompatibel zu LaTeX 2e wird? Oder hat jemand eine andere hilfreiche Idee, z.B. welche Anpassungen möglicher Weise an der Klasse selbst vorzunehmen wären?

Das Verhalten ist ganz normal, egu scheint da ein wenig veraltet zu sein. Du kannst mir dem pdfeTeX aber genauso dvi-Dateien erzeugen wie zuvor. Schau einmal in die Doku zu teTeX.

OK, aber das Problem sind weniger die nicht vorhandenen dvi-Dateien als viel mehr die Tatsache, dass die Grafikeinbindung an sich nicht mit egu und pdfeTeX klappt. Dvi-Ausgaben wird man vermutlich via Befehl erzwingen können aber bei der Grafikeinbindung kommt es ja regelrecht zur Fehlermeldung (sinngemäß): Datei nicht vorhanden! oder Datei liegt nicht im jpg oder pdf Format vor! Aber: ich will ja auch kein jpg oder pdf einbinden sondern eps! Erstere Meldung tritt auf, wenn ich beim Einbinden die Dateinamenerweiterung ".eps" weglasse, was allerdings die Anleitung der egu-Klasse verlangt. Und auf diesem Rechner hier läufts ja, nur daheim kann ich nicht weiterarbeiten! Irgendwie blöd... Gruß, Hannes

Am Mittwoch, 9. August 2006 00:05 schrieb Hannes Vogelmann:

Am Tag 06-08-08 zur Zeit 19:39:33 schrieb Martin Schröder:

...

Am 08.08.06 schrieb Hannes Vogelmann : (...). Das ist eine andere TeX-Engine, nicht ein anderes LaTeX.

...

Leider funktioniert die egu.cls mit pdfeTex nicht, wenn es um die Grafikeinbindung geht. Eps-Dateien werden plötzlich abgelehnt.

Das ist bei pdfTeX im PDF-Modus so. Es kann aber auch DVI erzeugen und tut das normalerweise auch.

Mir war gar nicht klar, dass ich pdfTeX gestartet habe. Aufgerufen habe ich nämlich "latex".

Kann ich verstehen, denn jan@linux:~> rpm -qf $(which latex) te_latex-3.0-37 klingt auch extrem nach LaTeX (SL 10.1).

...

(...). - http://www.tex.ac.uk/cgi-bin/texfaq2html?introduction=yes (...).

Die faqs geben dazu irgendwie nichts braucbares her.

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

(...).

...

PS: Lies bitte http://www.chiark.greenend.org.uk/~sgtatham/bugs-de.html

Passt etwas nicht?

Du hast noch nie de.comp.text.tex gelesen oder dort gar etwas geschrieben? Die Regulars sind äußert penibel. Im direkten Vergleich ist Martins Antwort ist geradezu höflich, hilfreich und nett. Gruß Jan -- We have met the enemy and he is us.

Am Tag 06-08-08 zur Zeit 23:57:07 schrieb Martin Schröder:

Am 09.08.06 schrieb Hannes Vogelmann

...

Mir war gar nicht klar, dass ich pdfTeX gestartet habe. Aufgerufen habe ich nämlich "latex".

Ja und? Dann sollte es dvi erzeugen. Aber egu.cls stellt dann wohl stumpf pdf an.

Das ist ja gerade das, was ich nicht verstehe, denn mit der gleichen egu.cls passiert das mit dem latex von der SuSE 9.2 ja gerade nicht und alles läuft wie gewünscht und ein dvi-file kommt hinten raus und die eps-Dateien werden ordentlich importiert. Aber wie es aussieht, hat David ja schon den bug in der egu.cls ausgemacht. Viele Grüße, Hannes

Am Tag 06-08-09 zur Zeit 00:33:54 schrieb Martin Schröder:

Am 09.08.06 schrieb Hannes Vogelmann

...

Das ist ja gerade das, was ich nicht verstehe, denn mit der gleichen egu.cls passiert das mit dem latex von der SuSE 9.2 ja gerade nicht und alles läuft wie gewünscht und ein dvi-file kommt hinten raus und die eps-Dateien werden ordentlich importiert. Aber wie es aussieht, hat David ja schon den bug in der egu.cls ausgemacht.

Kennst Du den Unterschied zwischen LaTeX, TeX und pdfTeX?

Naja, nur soweit, das LaTeX eben dvi-files erzeugt und mit graphicx eps-Dateien verarbeitet und pdflatex eben pdf-Dateien erzeugt und warum auch immer keine eps-Dateien schluckt wobei beide sonst ähnliche (gleiche?) macrosprachen für TeX sind. Da ich pdflatex bisher nicht verwendet habe (außer jetzt eben unwillentlich) kenne ich mich aber auch nur mit LaTeX aus.

9.2 hat wahrscheinlich noch ein teTeX 2, d.h. latex benutzt tex(1). Bei 9.3 haben sie endlich auf teTeX 3 umgestellt, und latex benutzt pdftex(1). egu.cls erkennt pdftex, weiß aber nicht, daß pdftex auch dvi erzeugen kann, und schaltet pdf an, und fällt dann auf die Nase.

So in etwa! egu.cls erkennt nicht, dass der Schalter \pdfoutput=0 gesetzt ist, weil es den bei früheren teTeX-Versionen noch nicht gab und entscheidet dann falscherweise sich so zu verhalten als wäre er auf 1 gesetzt, mit den bekannten Folgen. Frage am Rande: Warum lässt pdflatex keine eps-Grafiken zu? Oder liege ich da ganz falsch? Gruß, Hannes

Hallo, Am Mit, 09 Aug 2006, Hannes Vogelmann schrieb:

Am Tag 06-08-09 zur Zeit 00:33:54 schrieb Martin Schröder:

...

Kennst Du den Unterschied zwischen LaTeX, TeX und pdfTeX?

Naja, nur soweit, das LaTeX eben dvi-files erzeugt und mit graphicx eps-Dateien verarbeitet und pdflatex eben pdf-Dateien erzeugt und warum auch immer keine eps-Dateien schluckt wobei beide sonst ähnliche (gleiche?) macrosprachen für TeX sind. Da ich pdflatex bisher nicht verwendet habe (außer jetzt eben unwillentlich) kenne ich mich aber auch nur mit LaTeX aus.

Da gibt es keinen Unterschied. Nur das Ausgabeformat ist ein anderes und welche Grafikformate eingebunden werden können. Ok, es gibt noch ein paar Details, z.B. PDF-Specials usw. die hyperref setzt um die Hyperlinks usw. zu erzeugen. Aber solche Specials gibt's ja auch bei der DVI-Ausgabe, dann werden die aber i.d.R. für PS via dvips generiert. Aber um diese ganzen Details kümmern sich eben graphicx und hyperref selbst (bis auf ein paar Sonderfälle, die aber in der Praxis sehr selten sind). Etwas anders sieht die Sache mit eTeX vs. TeX aus, da gibt es tatsächlich ein paar Primitive mehr. Aber auch das muß den Anwender nicht interessieren, denn eTeX ist komplett abwärtskompatibel zu TeX. Es gibt praktisch 4 Backends: - TeX (ohne alles) - eTeX (mit ein paar Erweiterungen) - PDFTeX (TeX mit DVI- und PDF-Ausgabe und weiteren Verbesserungen, wobei die PDF-Ausgabe der default ist). - PDFeTeX (eTeX + PDFTeX vereint) Inzwischen verwenden eigentlich alle Distributionen PDFeTeX als Backend. LaTeX wiederum ist "nur" ein Makropaket, das mit allen(!) 4 Backends verwendet werden kann. ConTeXt hingegen kann IIRC nicht mit TeX als Backend, es verwendet Features aus eTeX und/oder PDFTeX ;) Daß du 'latex' aufrufen kannst ist nur ein Entgegenkommen, insofern, als daß das Backend gleich ein passendes Format (das "gedumpte" Makropaket, hier LaTeX) lädt. Ebenso wird das Ausgabeformat entsprechend dem Namen unter dem man das Backend aufruft angepasst. Es gibt noch weitere Makropakete, z.B. jadetex, xmltex usw. die auch über entsprechende Namen aufgerufen werden können. Du kannst statt latex auch: tex -fmt latex verwenden oder das Format per '%&latex' in der ersten Zeile dazuladen. Oder auch mit den anderen Backends (wobei die bei dir alle gleich sind): etex -efmt elatex => eLaTeX, das Format ist ein mit eTeX gedumptes LaTeX-Makropaket pdftex -fmt pdflatex => PDFLaTeX (analog) pdfetex -efmt pdfelatex => PDFeLaTeX (analog) Ggfs. wird sogar noch das Format erst generiert. So, jetzt kannst du aber eben statt 4 Backends auch weniger nehmen, und diese dann eben in den passenden "Modus" schalten. Denn, wie gesagt gilt: eTeX \supset TeX PDFTeX \supset TeX PDFeTeX = eTeX \cup PDFTeX PDFeTeX kann sich also wie alle anderen Backends verhalten. Und genau deswegen verwenden die Distributionen inzwischen PDFeTeX als Backend, das eben über die passende Konfiguration bzw. die passenden Aufrufnamen (symlinks) automatisch in die jeweiligen Modi geschaltet wird. Rufst du also 'latex' auf verwendest du das PDFeTeX Backend im DVI-Mode mit LaTeX-Format... (und s.u.)

...

9.2 hat wahrscheinlich noch ein teTeX 2, d.h. latex benutzt tex(1). Bei 9.3 haben sie endlich auf teTeX 3 umgestellt, und latex benutzt pdftex(1). egu.cls erkennt pdftex, weiß aber nicht, daß pdftex auch dvi erzeugen kann, und schaltet pdf an, und fällt dann auf die Nase.

So in etwa! egu.cls erkennt nicht, dass der Schalter \pdfoutput=0 gesetzt ist, weil es den bei früheren teTeX-Versionen noch nicht gab und entscheidet dann falscherweise sich so zu verhalten als wäre er auf 1 gesetzt, mit den bekannten Folgen.

Doch, \pdfoutput gibt es seit es pdftex gibt, allerdings wurde der von tex (und damit latex, etex, elatex) nicht definiert(!). Mit PDF(e)TeX als Backend wird aber \pdfoutput immer definiert (aber nicht immer auf etwas zu "true" expandierendes) gesetzt. Und nun fliegen eben alle die Pakete und Klassen auf die Nase, die den schon immer(!) falschen Test verwendet haben. Und ifpdf.sty ist so neu nicht und macht alles richtig, falls man denn man wirklich selber den Modus unterscheiden muß. Der entscheidende Code (der Rest ist eigentlich nur Beiwerk wg. Versionierung, Ausgabe im Log etc.) ist recht kurz und einfach: ==== % File: ifpdf.sty % Version: 2001/07/14 v1.1 % Author: Heiko Oberdiek [..] % Implementing the switch: \newif\ifpdf \ifx\pdfoutput\undefined \else \ifx\pdfoutput\relax \else \ifcase\pdfoutput \else \pdftrue \fi \fi \fi ==== In der Klasse für die FAQ verwende ich: ==== %% ein 'if' fuer den Test, ob gerade pdf ausgegeben werden soll. Wenn %% vorhanden per ifpdf.sty \IfFileExists{ifpdf.sty}{% \RequirePackage{ifpdf} }{% \ClassWarning{sl-faq}{Package `ifpdf' not found, defining \string\ifpdf} \newif\ifpdf \ifx\pdfoutput\undefined \else \ifx\pdfoutput\relax \else \ifcase\pdfoutput \else \pdftrue \fi \fi \fi } ==== Ich verwende also, sofern vorhanden ifpdf.sty, ansonsten verwende ich den aus ifpdf kopierten Code. Wie gesagt: ein Test ob \pdfoutput undefiniert ist war schon immer fslach, funktioniert aber eben solange man nicht pdf(e)tex als Backend verwendet. Oder anders gesagt: \ifx\pdfoutput\undefined ist und war ein Test ob PDF(e)TeX das Backend ist. Aber _kein_ Test, welches Ausgabeformat gewünscht ist.

Frage am Rande: Warum lässt pdflatex keine eps-Grafiken zu? Oder liege ich da ganz falsch?

pdflatex läßt natürlich eps-Grafiken zu. Aber eben nicht wenn es PDF ausgeben soll. Das liegt schlicht daran, daß man eps nicht direkt in PDF einbetten kann. Ebenso kann man ja auch kein jpeg direkt in PS einbetten. Wenn man das eps für's PDF passend umpackt (epstopdf) oder um das jpeg einen EPS-Header schreibt (jpeg2ps), dann kann man es einbetten. In egu.cls wird aber graphicx der faslche Modus vorgegeben. Versuch doch mal folgendes: ==== \documentclass{minimal} \usepackage{graphicx} \begin{document} \includegraphics{foo} \end{document} ==== und lege ein passendes 'foo.eps' dazu. Und dann lass dein latex (das dann ein PDFeTeX im latex-Modus ist) drüberlaufen. Es sollte alles klappen. Und dann sabotiere graphicx wie es egu.cls macht: \usepackage[pdftex]{graphicx} und rufe wieder 'latex' auf. Und du solltest die bekannte Fehlermeldung bekommen. HTH, -dnh -- Get back there in front of the computer NOW. Christmas can wait. -- Linus "the Grinch" Torvalds, 24 Dec 2000 on linux-kernel

2006/8/8, David Haller :

sicher Deutsch, also frag mal nach... Ich kann egu.cls nicht direkt ausprobieren, denn ich verwende noch TeX als Engine für LaTeX und zum umbooten in die 10.1 habe ich grad keinen Bock. Melde dich

Dazu mußt Du nicht umbooten; mit "texconfig formats" kannst Du die Engine einstellen. Gruß Martin

Moin David, Am Tag 06-08-08 zur Zeit 22:21:17 schrieb David Haller:

Hallo,

Am Die, 08 Aug 2006, Hannes Vogelmann schrieb:

...

Leider funktioniert die egu.cls mit pdfeTex nicht, wenn es um die Grafikeinbindung geht. Eps-Dateien werden plötzlich abgelehnt.

Das ist ein Bug in egu.cls.

hmmm...

Das verwendet

\ifx\pdfoutput\undefined%

und das ist untauglich um zu unterscheiden, denn pdfeTeX setzt im DVI-Modus \pdfoutput=0, d.h. es ist definiert.

Das bedeutet aber doch eine echte Abwärts-Inkompatibilät zwischen TeX und pdfeTeX, denn TeX kennt ja gar kein \pdfoutput=was-auch-immer.

Das Paket 'ifpdf.sty' zeigt wie man's richtig macht bzw. man sollte ifpdf verwenden.

Das schau ich mir morgen mal an.

egu.cls "erkennt" also den DVI-Mode fälschlich als PDF-Mode und durch das folgende:

\else% \IfFileExists{graphicx.sty}{\RequirePackage[pdftex]{graphicx}% pdfLaTeX \DeclareGraphicsExtensions{.pdf,.png,.jpg}}{%

macht egu.cls graphicx.sty dann die Arbeit unmöglich, wenn wenn man graphicx nicht dazu zwingt macht das selber das richtige... Probiere doch einfach mal:

\RequirePackage{graphicx} \documentclass...

...hilft dem leider nicht ab. Aber wenn man in der egu.cls \ifx\pdfoutput\undefined% und \else% \IfFileExists{graphicx.sty}{\RequirePackage[pdftex]{graphicx}% pdfLaTeX \DeclareGraphicsExtensions{.pdf,.png,.jpg}}{% ... auskommentiert, dann geht's wieder. Vielen Dank für den Hinweis!

Dafür, daß egu.cls im Oktober 2005 aktualisiert wurde ist das ziemlich eigenartig. Allerdings verstehen die Autoren von egu.cls ziemlich sicher Deutsch, also frag mal nach... Ich kann egu.cls nicht direkt ausprobieren, denn ich verwende noch TeX als Engine für LaTeX und zum umbooten in die 10.1 habe ich grad keinen Bock. Melde dich aber ggfs., gerne auch per PM.

Werde denen morgen mal einen bugreport schicken. Aber jetzt habe ich ja wenigstens mal ein Provisorium. Gracias und gute Nacht. Hannes