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? Viele Grüße, Hannes Vogelmann
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. Gruß, Johannes
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 Dienstag, 8. August 2006 18:23 schrieb Hannes Vogelmann:
(...). Aber: ich will ja auch kein jpg oder pdf einbinden sondern eps! (...).
http://www.trevorrow.com/oztex/ozfaq.html#pdfeps HTH Jan -- He who dies with the most toys, wins!
Am 08.08.06 schrieb Hannes Vogelmann <hannes.vogelmann@imk.fzk.de>:
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.
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. Fang mal an, Doku zu lesen: - texconfig faq - texdoc TETEXDOC - http://www.tex.ac.uk/cgi-bin/texfaq2html?introduction=yes - http://www.dante.de/faq/de-tex-faq/ Du könntest natürlich auch erstmal die aktuelle Version der "egu.cls" besorgen (http://www.copernicus.org/EGU/cp/LaTeX_submit.html) und Dich danach mit Deinen Problemen an den Autor wenden: "The LaTeX macro package was originally written for all EGU journals by Patrick W. Daly. The recent modifications were added by Dieter Schmitt and Rolf Sander. If you encounter a problem with the LaTeX macro package, please send an email to egu.production@copernicus.org. However, please be aware that we can only reply to specific problems of the EGU package and not to questions about LaTeX in general." Gruß Martin PS: Lies bitte http://www.chiark.greenend.org.uk/~sgtatham/bugs-de.html
Am Tag 06-08-08 zur Zeit 19:39:33 schrieb Martin Schröder:
Am 08.08.06 schrieb Hannes Vogelmann <hannes.vogelmann@imk.fzk.de>:
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.
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".
Fang mal an, Doku zu lesen: - texconfig faq - texdoc TETEXDOC - http://www.tex.ac.uk/cgi-bin/texfaq2html?introduction=yes - http://www.dante.de/faq/de-tex-faq/
Die faqs geben dazu irgendwie nichts braucbares her.
Du könntest natürlich auch erstmal die aktuelle Version der "egu.cls" besorgen (http://www.copernicus.org/EGU/cp/LaTeX_submit.html)
Die egu.cls habe ich mir gerade erst letzte Woche von dort geholt.
und Dich danach mit Deinen Problemen an den Autor wenden: "The LaTeX macro package was originally written for all EGU journals by Patrick W. Daly. The recent modifications were added by Dieter Schmitt and Rolf Sander. If you encounter a problem with the LaTeX macro package, please send an email to egu.production@copernicus.org. However, please be aware that we can only reply to specific problems of the EGU package and not to questions about LaTeX in general."
Das hätt ich jetzt auch als nächstes gemacht. Nur wollte ich vorher klären, ob es nicht an meiner Installation liegt bzw. dass ich nicht irgendwas übersehen habe.
PS: Lies bitte http://www.chiark.greenend.org.uk/~sgtatham/bugs-de.html
Passt etwas nicht? 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 <hannes.vogelmann@imk.fzk.de>: (...). 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 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? 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. Gruß Martin
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
Am 09.08.06 schrieb Hannes Vogelmann <hannes.vogelmann@imk.fzk.de>:
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
Fast. Lies bitte pdflatex(1). [...]
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.
Den gab es auch früher, wenn pdftex verwendet wurde. Da war er aber immer an, weil pdf erzeugt werden sollte.
Frage am Rande: Warum lässt pdflatex keine eps-Grafiken zu? Oder liege ich da ganz falsch?
Im DVI-Modus hat es damit keine Probleme. Im PDF-Modus erzeugt es direkt pdf, und einen Distiller haben und werden wir nicht einbauen. Gruß Martin
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
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. 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 Paket 'ifpdf.sty' zeigt wie man's richtig macht bzw. man sollte ifpdf verwenden. 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... 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. -dnh -- "All mushrooms are edible. However, some of them only once" -- Ino!~
2006/8/8, David Haller <lists@dhaller.de>:
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
Hallo, Am Die, 08 Aug 2006, Martin Schröder schrieb:
2006/8/8, David Haller <lists@dhaller.de>:
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.
Ich weiß, daß das theoretisch so geht, aber bei mir hat da irgendwas nicht geklappt (irgendne obskure Fehlermeldung beim erstellen der Formate, IIRC was mit den .pool-Dateien, auch als ich die dann neu installierte). Kann auch sein, daß ich beim kompilieren irgendwas flasch konfiguriert habe, ist jetzt auch schon wieder 2 Jahre her ;) Naja, ist sowieso tetex 2.0.x, das wird bei Gelegenheit aktualisiert und bis dahin kann ich sehr gut mit tex als engine leben, denn ich habe auch etex/elatex/pdfetex/pdfelatex. Halt als jew. eigene Binaries: $ ls -l $(dirname $(which tex))/{,e,pdf,pdfe}tex 258560 Jul 18 2004 /usr/share/texmf/teTeX/bin/etex* 797060 Jul 18 2004 /usr/share/texmf/teTeX/bin/pdfetex* 761508 Jul 18 2004 /usr/share/texmf/teTeX/bin/pdftex* 223520 Jul 18 2004 /usr/share/texmf/teTeX/bin/tex* -dnh -- Hey, what do you expect from a culture that *drives* on *parkways* and *parks* on *driveways*? --Gallagher
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
Am 09.08.06 schrieb Hannes Vogelmann
Das bedeutet aber doch eine echte Abwärts-Inkompatibilät zwischen TeX und pdfeTeX, denn TeX kennt ja gar kein \pdfoutput=was-auch-immer.
pdfTeX nennt sich ja auch nicht TeX, sondern pdfTeX. :-) Und sauber geschriebener Code kommt auch mit pdfTeX klar; egu.cls kommt halt noch aus der Zeit, als pdfTeX nur zur PDF-Erzeugung benutzt wurde. Dabei kann es schon sehr lange DVI erzeugen... Gruß Martin
Hallo, Am Mit, 09 Aug 2006, Hannes Vogelmann schrieb:
Am Tag 06-08-08 zur Zeit 22:21:17 schrieb David Haller:
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.
Nein. Das bedeutet, daß Leute etwas falsch gelesen haben und gedacht haben, sie könnten damit auf den PDF-Ausgabemodus schließen. Das war aber schon immer alschf. In der anderen Mail schreibe ich mehr dazu.
Das Paket 'ifpdf.sty' zeigt wie man's richtig macht bzw. man sollte ifpdf verwenden.
Das schau ich mir morgen mal an.
Auch hier: siehe meine andere Mail.
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!
==== UNGETESTETER Patch ==== --- egu.cls~ Sat Oct 8 23:48:34 2005 +++ egu.cls Wed Aug 9 04:36:36 2006 @@ -125,22 +125,36 @@ \if@aglet\paperheight=283mm\paperwidth=213mm\fi \ifacpd\paperheight=159mm\paperwidth=166mm\fi \newif\if@ps -\ifx\pdfoutput\undefined% - \IfFileExists{graphicx.sty}{\RequirePackage[dvips]{graphicx}% LaTeX - \DeclareGraphicsExtensions{.eps,.ps}}{% - \ClassWarningNoLine{egu}{Cannot find graphicx.sty; proceeding without it}} - \if@aglet\IfFileExists{color.sty}{\RequirePackage{color}}{% - \ClassWarningNoLine{egu}{Cannot find color.sty; proceeding without it}}\fi - \@pstrue -\else% - \IfFileExists{graphicx.sty}{\RequirePackage[pdftex]{graphicx}% pdfLaTeX - \DeclareGraphicsExtensions{.pdf,.png,.jpg}}{% - \ClassWarningNoLine{egu}{Cannot find graphicx.sty; proceeding without it}} - \if@aglet\IfFileExists{color.sty}{\RequirePackage[pdftex]{color}}{% - \ClassWarningNoLine{egu}{Cannot find color.sty; proceeding without it}}\fi +%%%% +\IfFileExists{ifpdf.sty}{% + \RequirePackage{ifpdf} +}{% + \ClassWarningNoLine{egu}% + {Package `ifpdf' not found, defining \string\ifpdf} + \newif\ifpdf + \ifx\pdfoutput\undefined + \else + \ifx\pdfoutput\relax + \else + \ifcase\pdfoutput + \else\pdftrue\fi + \fi + \fi +} +\IfFileExists{graphicx.sty}{\RequirePackage{graphicx}}{% + \ClassWarningNoLine{egu}{Cannot find graphicx.sty; proceeding without it} +} +\if@aglet\IfFileExists{color.sty}{\RequirePackage{color}}{% + \ClassWarningNoLine{egu}{Cannot find color.sty; proceeding without it}}% +\fi +% +\ifpdf \@psfalse \pdfinfo{/Creator (egu.cls version \clsversion)} +\else + \@pstrue \fi +%%%% \IfFileExists{url.sty}% {\RequirePackage{url}\urlstyle{same}}% {\ClassWarningNoLine{egu}{Cannot find url.sty; proceeding without it}% ==== Sollte sich per 'patch -p0 < DIFFDATEI' anwenden lassen. Den Test auf ifpdf.sty und die Ersatzdefinition von \ifpdf sollte man "upstream" evtl. noch an eine passendere Stelle verschieben... Falls es tut und du es weiterleitest...
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.
s.o. ;) -dnh -- Computers make very fast, very accurate mistakes.
Moin, Am Tag 06-08-09 zur Zeit 04:42:51 schrieb David Haller:
==== UNGETESTETER Patch ==== --- egu.cls~ Sat Oct 8 23:48:34 2005 +++ egu.cls Wed Aug 9 04:36:36 2006 @@ -125,22 +125,36 @@ [...]
Scheint zu klappen, sowohl mit TeX als auch mit pdfeTeX, und sowohl mit ifpdf.sty als auch ohne ifpdf.sty, ganz versteh' ich die logik nicht, dann könnt' ich doch ifpdf.sty von vornhererein weglassen oder so tun als wäre es nicht da und den ifpdf.sty-test sparen? Vielen Dank jedenfalls für diese Lösung! Hannes
Hallo, Am Mit, 09 Aug 2006, Hannes Vogelmann schrieb:
Am Tag 06-08-09 zur Zeit 04:42:51 schrieb David Haller:
==== UNGETESTETER Patch ==== +++ egu.cls Wed Aug 9 04:36:36 2006 @@ -125,22 +125,36 @@ [...]
Scheint zu klappen, sowohl mit TeX als auch mit pdfeTeX, und sowohl mit ifpdf.sty als auch ohne ifpdf.sty,
*g*
ganz versteh' ich die logik nicht, dann könnt' ich doch ifpdf.sty von vornhererein weglassen oder so tun als wäre es nicht da und den ifpdf.sty-test sparen?
ifpdf.sty wird wohl gewartet und ggfs. angepasst. Eigentlich sollte man nur ifpdf.sty verwenden aber es ist halt noch nicht überall vorhanden...
Vielen Dank jedenfalls für diese Lösung!
*bg* -dnh -- "Powered-up hardware and sweat do not mix." -- Simon Cozens
participants (5)
-
David Haller -
Hannes Vogelmann -
Jan Ritzerfeld -
Johannes Engel -
Martin Schröder