Dateinamenproblem
Hilmar Preuße
Minimalbeispiel:
\documentclass{minimal}
\usepackage{graphicx}
\begin{document}
\includegraphics{a.z}
\end{document}
Das File a.z.pdf existiert. Beim pdfLaTeX run kommt die Meldung:
-------------------
! LaTeX Error: Unknown graphics extension: .z.
See the LaTeX manual or LaTeX Companion for explanation.
Type H <return> for immediate help.
-------------------
feature oder bug?
Fileliste:
minimal.cls 2001/05/25 Standard LaTeX minimal class
graphicx.sty 1999/02/16 v1.0f Enhanced LaTeX Graphics (DPC,SPQR)
keyval.sty 1999/03/16 v1.13 key=value parser (DPC)
graphics.sty 2001/07/07 v1.0n Standard LaTeX Graphics (DPC,SPQR)
trig.sty 1999/03/16 v1.09 sin cos tan (DPC)
graphics.cfg 2001/08/31 v1.1 graphics configuration of teTeX/TeXLive
pdftex.def 2002/06/19 v0.03k graphics/color for pdftex
supp-pdf.tex
LaTeX hat dieselbe Krankheit, kann aber im Gegensatz zu pdfLaTeX mit
dem Fall "File a.z existiert" umgehen.
*File List*
<wegen Doppelung gesnippt>
graphics.cfg 2001/08/31 v1.1 graphics configuration of teTeX/TeXLive
dvips.def 1999/02/16 v3.0i Driver-dependant file (DPC,SPQR)
Hints, suggestions (also außer das File umbenennen)?
Thanks,
Hilmar
--
RMS, Linus Torvalds und D. E. Knuth sitzen beim Bier in der Kneipe.
RMS: "Gott sagt, ich hätte den weltbesten Editor geschrieben."
Linus: "Gott sagt, ich hätte das weltbeste Betriebssystem geschrieben."
Knuth: "Was soll ich gesagt haben?" <v8qpub...@jobpilot.de>
Rolf Niepraschk
So geht's.
\documentclass{minimal}
\usepackage{graphicx}
\begin{document}
\newcommand\DOT{.}
\includegraphics{a\DOT z}
\end{document}
Ich gebe aber zu, dass auch das nicht befriedigend ist.
Noch eine Alternative:
\documentclass{minimal}
\usepackage{pgf}
\begin{document}
\pgfdeclareimage{HUGO}{a.z}
\pgfuseimage{HUGO}
\end{document}
...Rolf
--
|| Rolf Niepraschk c/o Physikalisch-Technische Bundesanstalt ||
|| Abbestr. 2-12; D-10587 Berlin, Germany ||
|| Tel/Fax: ++49-30-3481-316/490, email: Rolf.Ni...@ptb.de ||
Uwe Ziegenhagen
>
> So geht's.
>
> \documentclass{minimal}
> \usepackage{graphicx}
> \begin{document}
> \newcommand\DOT{.}
> \includegraphics{a\DOT z}
> \end{document}
>
> Ich gebe aber zu, dass auch das nicht befriedigend ist.
>
> Noch eine Alternative:
>
> \documentclass{minimal}
> \usepackage{pgf}
> \begin{document}
> \pgfdeclareimage{HUGO}{a.z}
> \pgfuseimage{HUGO}
> \end{document}
>
> ...Rolf
Na, ob ihm das hilft...
.z ist ja sicher kein Standardgrafikformat, oder irre ich mich?
Es gibt da einen Befehl "declaregraphicsrule" oder so ähnlich, der LaTeX
mitteilt was es denn mit dem unbekannten Format machen soll. Mehr weiß
ich auch nicht, googeln sollte helfen.
Uwe
--
mail to news...@ziegenhagen.info is read only from time to time. If
you need an urgent answer, google for me.
Herbert Voss
> \documentclass{minimal}
> \usepackage{graphicx}
> \begin{document}
> \includegraphics{a.z}
\includegraphics[type=pdf,ext=.pdf,read=.pdf]{a.z}
Herbert
--
http://TeXnik.de/
http://PSTricks.de/
ftp://ftp.dante.de/tex-archive/info/math/voss/Voss-Mathmode.pdf
http://www.dante.de/faq/de-tex-faq/
http://www.tex.ac.uk/cgi-bin/texfaq2html?introduction=yes
Oliver Jennrich
> Rolf Niepraschk wrote:
>> So geht's.
>> \documentclass{minimal}
>> \usepackage{graphicx}
>> \begin{document}
>> \newcommand\DOT{.}
>> \includegraphics{a\DOT z}
>> \end{document}
>> Ich gebe aber zu, dass auch das nicht befriedigend ist.
>> Noch eine Alternative:
>> \documentclass{minimal}
>> \usepackage{pgf}
>> \begin{document}
>> \pgfdeclareimage{HUGO}{a.z}
>> \pgfuseimage{HUGO}
>> \end{document}
>> ...Rolf
> Na, ob ihm das hilft...
> .z ist ja sicher kein Standardgrafikformat, oder irre ich mich?
Eben. Deswegen versucht der OP ja auch eine Datei namens a.z.pdf
einzubinden.
--
Fragen zu TeX oder LaTeX?
www.dante.de/faq/de-tex-faq --- www.tex.ac.uk/cgi-bin/texfaq2html
Minimalbeispiel?
www-users.rwth-aachen.de/Christian.Faulhammer/mini.html
Heiko Oberdiek
> \documentclass{minimal}
> \usepackage{graphicx}
> \begin{document}
> \includegraphics{a.z}
> \end{document}
>
> Das File a.z.pdf existiert. Beim pdfLaTeX run kommt die Meldung:
>
> -------------------
> ! LaTeX Error: Unknown graphics extension: .z.
>
> See the LaTeX manual or LaTeX Companion for explanation.
> Type H <return> for immediate help.
> -------------------
>
> feature oder bug?
Feature.
> LaTeX hat dieselbe Krankheit, kann aber im Gegensatz zu pdfLaTeX mit
> dem Fall "File a.z existiert" umgehen.
In dvips gibt es eine Default-Regel, alles was nicht erkannt wird,
wird als PostScript behandelt. Da ausser ein paar Bitmap-Formaten
dvips nicht viel anderes kann, macht das Sinn.
In pdfTeX gibt es so eine Default-Regel nicht. Der eine verwendet
primaer Screenshots mit .png-Dateien, der andere setzt ein
Fotoalbum mit .jpg-Dateien, wieder ein anderer importiert
haeufig .pdf-Dateien. Sinn machen koennte eine Default-Regel
hier nur fuer MetaPost-Ausgabedateien, da man diese dann
nicht in .mps umbenennen muss, damit sie erkannt werden.
Gibt es die Datei "a.z", so haelt der Parser "a" fuer den Namen
und ".z" fuer die Endung. ".z" ist weder bei pdftex.def, noch bei
dvips.def definiert, hier schlaegt dann die Default-Regel bei
dvips.def zu. Ohne Default-Regel gibt es eine Fehlermeldung.
Gibt es die Datei "a.z" nicht, so liefern beide eine Fehlermeldung.
Das Problem liegt daher nicht an der Existenz von "a.z", sondern
dass du dem Parser einen Dateinamen mit Punkt unterschiebt, der
Parser aber alles nach dem ersten Punkt als Endung ansieht.
Da komplexe Endungen mit mehreren Punkten durchaus ueblich sind:
foo.tar.bz2, foo.ps.gz, ...
Halte ich Punkte im Namensbestandteil fuer "boese".
Oder kannst du mir sicher sagen, was die Dateiendung von
a.b.c.d.e
ist?
Das einzige, was man vielleicht noch machen kann, ist, den Parser
umzuschreiben, dass er auf bekannte Endungen testet. Das ist
allerdings ein ziemlich hoher Aufwand in TeX. Es kommt hinzu,
dass es auf die Reihenfolge der Liste der bekannten Endungen
ankommt: .a, .b.a, .c.b.a
Was soll bei d.c.b.a zuerst gefunden werden? D.h. die Listenverwaltung
wird dann ziemlich kompliziert.
Einfachste Loesung ist daher das Maskieren des Nicht-Endungs-Punktes,
wie Rolf bereits gezeigt hat.
Viele Gruesse
Heiko <ober...@uni-freiburg.de>
Hilmar Preuße
> Hilmar Preuße wrote:
Hallo,
>> \documentclass{minimal}
>> \usepackage{graphicx}
>> \begin{document}
>> \includegraphics{a.z}
>
> \includegraphics[type=pdf,ext=.pdf,read=.pdf]{a.z}
>
Das tut. Danke!
Fragt sich nur, warum ich es nochmal explizit festnageln muß, wenn es
(soweit ich sehe) in graphics/pdftex.def schon steht. Ich vermute,
pdftex fängt links an nach extensions zu parsen und bricht am ersten
Punkt ab.
Außerdem versagt Dein Verfahren, wenn ich auch ein File a.z.eps im ./
habe und LaTeX aufrufen will.
Regards,
Hilmar
--
Ich will keinen erzieherischen Wert, ich will Tote.
-- Lars Marowsky-Bree in dasr
http://hilmarpreusse.forum-rheinland.de/
http://charon.wh10.tu-dresden.de/~lego/textreff.html
Herbert Voss
>>\includegraphics[type=pdf,ext=.pdf,read=.pdf]{a.z}
>>
>
> Das tut. Danke!
> Fragt sich nur, warum ich es nochmal explizit festnageln muß, wenn es
> (soweit ich sehe) in graphics/pdftex.def schon steht. Ich vermute,
> pdftex fängt links an nach extensions zu parsen und bricht am ersten
> Punkt ab.
> Außerdem versagt Dein Verfahren, wenn ich auch ein File a.z.eps im ./
> habe und LaTeX aufrufen will.
\usepackage{ifpdf}
\ifpdf .... \else ... \fi
ist dann der übliche Weg.
Hilmar Preuße
Moin,
> So geht's.
>
> \documentclass{minimal}
> \usepackage{graphicx}
> \begin{document}
> \newcommand\DOT{.}
> \includegraphics{a\DOT z}
> \end{document}
>
> Ich gebe aber zu, dass auch das nicht befriedigend ist.
>
Danke. Unbequem aber tut!
> Noch eine Alternative:
>
> \documentclass{minimal}
> \usepackage{pgf}
> \begin{document}
> \pgfdeclareimage{HUGO}{a.z}
> \pgfuseimage{HUGO}
> \end{document}
>
Das heißt man deklariert für jedes Bild einen Key unter dem man es
dann abrufen kann? Nun, da man sehr oft sowieso referenzieren will
sollte das nicht so schlimm sein.
Hintergrund der ganzen Aktion: http://bugs.debian.org/259390 . Ich
werde dem Herrn die Alternativen präsentieren, die Erklärung
unterschieben (danke an Heiko!) und den Bug als nicht fixbar taggen.
Vielen Dank an alle Beteiligten!
Hilmar
--
checking for the validity of the Maxwell laws on this machine... ok
checking if e=mc^2... ok
checking if we can safely swap on /dev/fd0... yes
(Ausgabe von "configure" bei kvirc 2.0)
Hilmar Preuße
> Das einzige, was man vielleicht noch machen kann, ist, den Parser
> umzuschreiben, dass er auf bekannte Endungen testet. Das ist
> allerdings ein ziemlich hoher Aufwand in TeX. Es kommt hinzu,
> dass es auf die Reihenfolge der Liste der bekannten Endungen
> ankommt: .a, .b.a, .c.b.a
> Was soll bei d.c.b.a zuerst gefunden werden? D.h. die Listenverwaltung
> wird dann ziemlich kompliziert.
>
> Einfachste Loesung ist daher das Maskieren des Nicht-Endungs-Punktes,
> wie Rolf bereits gezeigt hat.
>
Danke für die Erklärung! Ich werde dem Bugsubmitter das mitteilen.
Hilmar
--
"Ich dachte immer, UNIX ist was für Leute, denen es gefällt,
auf einen Bildschirm zu starren, auf dem es aussieht, als hätte
sich gerade ein Gürteltier auf der Tastatur gewälzt."
-- Stefan Schneider
Heiko Oberdiek
> Herbert Voss <Herber...@gmx.net> wrote:
> > Hilmar Preuße wrote:
>
> Hallo,
>
> >> \documentclass{minimal}
> >> \usepackage{graphicx}
> >> \begin{document}
> >> \includegraphics{a.z}
> >
> > \includegraphics[type=pdf,ext=.pdf,read=.pdf]{a.z}
> >
> Das tut. Danke!
> Fragt sich nur, warum ich es nochmal explizit festnageln muß, wenn es
> (soweit ich sehe) in graphics/pdftex.def schon steht. Ich vermute,
> pdftex fängt links an nach extensions zu parsen und bricht am ersten
> Punkt ab.
Nicht pdftex.def hat nichts mit Dateinamensparsing zu tun, das wird
durch graphics.sty gemacht, das wiederum verwendet
LaTeX-Kernel-Makros dazu (\filename@parse).
Viele Gruesse
Heiko <ober...@uni-freiburg.de>
Hilmar Preuße
> Hilmar Preuße <hil...@despammed.com> wrote:
Hallo,
>> Fragt sich nur, warum ich es nochmal explizit festnageln muß, wenn
>> es (soweit ich sehe) in graphics/pdftex.def schon steht. Ich
>> vermute, pdftex fängt links an nach extensions zu parsen und
>> bricht am ersten Punkt ab.
>
> Nicht pdftex.def hat nichts mit Dateinamensparsing zu tun, das wird
> durch graphics.sty gemacht, das wiederum verwendet
> LaTeX-Kernel-Makros dazu (\filename@parse).
>
Hmm. Warum kann LaTeX dann mit dem Fall "File a.z existiert und ist
eps" umgehen, aber pdfLaTeX nicht mit dem Fall "File a.z existiert
und ist pdf"? Ja, ich weiß das müßte eher ein Bug in LaTeX sein, ein
File einzubinden, dessen Extension es nicht kennt.
Grüße,
Hilmar
--
Dabei ist XP wirklich geeignet, beim Betrachter Augenkrebs zu verursachen.
Die Gestaltung müssen ein paar Teletubbies auf LSD geleitet haben, anders
ist das nicht zu erklären. -- Benedict Mangelsdorff, g.ct
Hilmar Preuße
> Hmm. Warum kann LaTeX dann mit dem Fall "File a.z existiert und ist
> eps" umgehen, aber pdfLaTeX nicht mit dem Fall "File a.z existiert
> und ist pdf"? Ja, ich weiß das müßte eher ein Bug in LaTeX sein,
> ein File einzubinden, dessen Extension es nicht kennt.
>
Shrug! Hast Du ja schon beantwortet! Gut, wenn dvips alles als eps
auffaßt ist es ja sicher sinnvoll, daß mit LaTeX genauso zu machen.
Sorry fürs Nichtaufpassen!
H.
--
Wenn eine Linuxdistribution so wenig brauchbare Software wie Windows
mitbrächte, wäre das bedauerlich. Was bei Windows der Umfang eines
"kompletten Betriebssystems" ist, nennt man bei Linux eine Rescuedisk.
<x57juov...@lola.goethe.zz>
Hilmar Preuße
Hallo,
> In pdfTeX gibt es so eine Default-Regel nicht. Der eine verwendet
> primaer Screenshots mit .png-Dateien, der andere setzt ein
> Fotoalbum mit .jpg-Dateien, wieder ein anderer importiert haeufig
> .pdf-Dateien. Sinn machen koennte eine Default-Regel hier nur fuer
> MetaPost-Ausgabedateien, da man diese dann nicht in .mps umbenennen
> muss, damit sie erkannt werden.
>
Hmm. Unter UNIX gibt es file(1). Das kann man nicht in TeX
implementieren, das seh ich ein. Es als externes Programm
vorauszusetzen wäre Gift für die Kompatibilität von TeX, zumal es bei
komprimierten Files nicht weiterhelfen würde.
> Das Problem liegt daher nicht an der Existenz von "a.z", sondern
> dass du dem Parser einen Dateinamen mit Punkt unterschiebt, der
> Parser aber alles nach dem ersten Punkt als Endung ansieht. Da
> komplexe Endungen mit mehreren Punkten durchaus ueblich sind:
> foo.tar.bz2, foo.ps.gz, ...
> Halte ich Punkte im Namensbestandteil fuer "boese".
>
Wäre es nicht andersrum möglich, den Dateinamen von rechts zu parsen?
Dann blieben nicht mehr so viele Fallunterscheidungen übrig:
1. Extension ist .mps, .pdf, .jpg, .png oder .eps
2. Extension ist .Z, .z, oder .gz (das wird ja IIRC in graphics.cfg
festgelegt). Dann diese Endung wegschneiden und weiter bei Punkt 1.
3. Gar nichts trifft zu -> Error.
> Oder kannst du mir sicher sagen, was die Dateiendung von
> a.b.c.d.e
> ist?
>
e: wenn ich rechts anfange zu suchen. Von Links geht das natürlich
nicht.
> Das einzige, was man vielleicht noch machen kann, ist, den Parser
> umzuschreiben, dass er auf bekannte Endungen testet. Das ist
> allerdings ein ziemlich hoher Aufwand in TeX.
>
glaube ich.
> Es kommt hinzu, dass es auf die Reihenfolge der Liste der bekannten
> Endungen ankommt: .a, .b.a, .c.b.a Was soll bei d.c.b.a zuerst
> gefunden werden?
>
Von links kann ich gar nichts entscheiden, weil ich erst bis ganz
rechts parsen müßte, um mir die letzte Endung anzuschauen und dann zu
entscheiden, ob man (a) ein komprimiertes File vor sich hat oder (b)
schon klar ist, was das ist (s.o.).
Nur so ein paar Gedanken. Ich weiß, daß das alles kaum realisiert
werden wird und sehe es persönlich auch nicht als Mangel an.
Viele Grüße,
Hilmar
--
Eben - wo ist das Problem?
Paketverwaltung ist nur was für blutige Anfänger. Für Leute, die an
der Hand geführt werden wollen. Die eigentlich Windows haben wollen.
Helmut Hullen <8pV4U...@helmut.hullen.de>
Heiko Oberdiek
> Heiko Oberdiek <ober...@uni-freiburg.de> wrote:
> > Hilmar Preuße <hil...@despammed.com> wrote:
>
> >> Fragt sich nur, warum ich es nochmal explizit festnageln muß, wenn
> >> es (soweit ich sehe) in graphics/pdftex.def schon steht. Ich
> >> vermute, pdftex fängt links an nach extensions zu parsen und
> >> bricht am ersten Punkt ab.
> >
> > Nicht pdftex.def hat nichts mit Dateinamensparsing zu tun, das wird
> > durch graphics.sty gemacht, das wiederum verwendet
> > LaTeX-Kernel-Makros dazu (\filename@parse).
> >
> Hmm. Warum kann LaTeX dann mit dem Fall "File a.z existiert und ist
s/LaTeX/graphics/dvips.def/
> eps" umgehen,
Das habe ich doch schon erklaert: Hier schlaegt die Default-Regel von
dvips zu, alles unbekannte als "eps" zu behandeln.
> aber pdfLaTeX nicht mit dem Fall "File a.z existiert
> und ist pdf"?
pdftex.def definiert keine Defaultregel.
Das kannst du ja nachholen (grfguide):
\DeclareGraphicsRule{*}{pdf}{*}{}
Dann findet auch graphics/pdftex.def "a.z" und bindet das als
PDF-Datei ein.
Aber mal ehrlich, verwendest du ernsthaft PDF-Dateien mit einer
anderen Endung als ".pdf"?
Viele Gruesse
Heiko <ober...@uni-freiburg.de>
Andreas Matthias
> Wäre es nicht andersrum möglich, den Dateinamen von rechts zu parsen?
Das wäre schön! Aber mehr als von vorne nach hinten hangeln ist
mit TeX leider nicht möglich. Und Durchhangeln ist aufwendig und
sehr Resourcen fressend.
Ciao
Andreas
Stefan Ulrich
Hmm, man könnte den Dateinamen umdrehen und dann von links nach rechts
parsen ;-)
Aber eigentlich muß man sich doch im Grunde nur die letzten beiden
Extensionen anschauen und dann überprüfen, ob die letzte eine bekannte
gz/bz2 usw. ist. Hier ist mal ein schneller Proof-of-Concept-Hack, wie
man an die letzten beiden Extensionen kommt; ich bin mir sicher, dass
echte TeXianer das auch ohne globale Register und effizienter können ;-)
\documentclass{minimal}
\usepackage{ifthen}
\newcommand\extensiona{}
\newcommand\extensionb{}
\newcommand\showextensions[3]{%
\ifcase#1
\typeout{No extension.}%
\or % = 1
\typeout{1 extension: `#3'}%
\else % > 2
\typeout{2 extensions: `#2', `#3'}%
\fi
}
\newcounter{extcount}
\newcommand\testext[1]{%
\typeout{INPUT: |#1|}%
\def\extensiona{}%
\def\extensionb{}%
\setcounter{extcount}{0}%
\testexta#1.\end
}
\newcommand\showext[1]{\showexta#1\end}
\def\showexta#1.\end{%
\stepcounter{extcount}%
\def\extensionb{#1}%
\testexta#1.\end
}
\def\testexta#1.#2\end{%
\ifthenelse{\equal{#2}{}}{%
\showextensions{\theextcount}{\extensiona}{\extensionb}%
}{%
\def\extensiona{#1}%
\showext{#2}%
}%
}
\begin{document}
\testext{test}
\testext{test.a}
\testext{test.a.b.c}
\testext{test.a.b.c.d}
\testext{test.a.b.c.d.ps.gz}
\end{document}
--
Stefan Ulrich
Hilmar Preuße
> Hilmar Preuße wrote:
Moin,
>> Außerdem versagt Dein Verfahren, wenn ich auch ein File a.z.eps im
>> ./ habe und LaTeX aufrufen will.
>
> \usepackage{ifpdf}
> \ifpdf .... \else ... \fi
>
> ist dann der übliche Weg.
>
Ich glaub ich war mal wieder zu faul zum Nachdenken...
H.
--
Und sogar Martin Luther hätte mehr vom Usenet verstanden als Du.
Der hat nämlich seine Thesen an die Kirchentüre genagelt und
nicht ans Stadttor. Er hatte nämlich begriffen, wo sie on topic
sind. (Hans-Georg Bickel in de.admin.net-abuse.news)
Hilmar Preuße
> Hilmar Preuße wrote:
Moin,
>> Wäre es nicht andersrum möglich, den Dateinamen von rechts zu
>> parsen?
>
> Das wäre schön! Aber mehr als von vorne nach hinten hangeln ist mit
> TeX leider nicht möglich. Und Durchhangeln ist aufwendig und sehr
> Resourcen fressend.
>
Tja. Schade. Viel mehr als eine fixe Idee war das eh nicht und von
plain TeX hab ich nicht soviel Ahnung. Da das ja nicht wirklich eine
Einschränkung ist, sage ich hier EOT und bedanke mich bei allen
Beteiligten!
Hilmar
--
Wer HTML postet oder gepostetes HTML quotet oder sich gepostetes oder
gequotetes HTML beschafft, um es in Verkehr zu bringen, wird geplonkt.
http://hilmarpreusse.forum-rheinland.de/
http://charon.wh10.tu-dresden.de/~lego/textreff.html
Hilmar Preuße
> Aber mal ehrlich, verwendest du ernsthaft PDF-Dateien mit einer
> anderen Endung als ".pdf"?
>
Nö, nicht so wirklich. Danke für Deine Bemühungen.
H.
--
!(man gcc | grep "time for that" | cut -d " " -f 9)
http://hilmarpreusse.forum-rheinland.de/
http://charon.wh10.tu-dresden.de/~lego/textreff.html
Andreas Matthias
> Andreas Matthias <andreas....@tuwien.ac.at> writes:
>
>> Hilmar Preuße wrote:
>>> Wäre es nicht andersrum möglich, den Dateinamen von rechts zu parsen?
>
>> Das wäre schön! Aber mehr als von vorne nach hinten hangeln ist
>> mit TeX leider nicht möglich. Und Durchhangeln ist aufwendig und
>> sehr Resourcen fressend.
>
> Hmm, man könnte den Dateinamen umdrehen und dann von links nach rechts
> parsen ;-)
1) Das ist ja noch viel aufwendiger, wenn man es wie hier bei Dateinamen
nur einmal braucht. Solche Rekursionen fressen enorme Resourcen.
2) Warum hast du dich in deinem Beispiel für Hangeln und nicht
für Umdrehen entschieden?
Ciao
Andreas
Heiko Oberdiek
> Heiko Oberdiek <ober...@uni-freiburg.de> wrote:
>
> > In pdfTeX gibt es so eine Default-Regel nicht. Der eine verwendet
> > primaer Screenshots mit .png-Dateien, der andere setzt ein
> > Fotoalbum mit .jpg-Dateien, wieder ein anderer importiert haeufig
> > .pdf-Dateien. Sinn machen koennte eine Default-Regel hier nur fuer
> > MetaPost-Ausgabedateien, da man diese dann nicht in .mps umbenennen
> > muss, damit sie erkannt werden.
> >
> Hmm. Unter UNIX gibt es file(1). Das kann man nicht in TeX
> implementieren, das seh ich ein.
pdfTeX macht das, es sieht sich die Magic Numbers an, um
zu entscheiden, was fuer ein Grafikdateiformat es bei
\pdfximage{} vorliegen hat.
> > Das Problem liegt daher nicht an der Existenz von "a.z", sondern
> > dass du dem Parser einen Dateinamen mit Punkt unterschiebt, der
> > Parser aber alles nach dem ersten Punkt als Endung ansieht. Da
> > komplexe Endungen mit mehreren Punkten durchaus ueblich sind:
> > foo.tar.bz2, foo.ps.gz, ...
> > Halte ich Punkte im Namensbestandteil fuer "boese".
> >
> Wäre es nicht andersrum möglich, den Dateinamen von rechts zu parsen?
> Dann blieben nicht mehr so viele Fallunterscheidungen übrig:
> 1. Extension ist .mps, .pdf, .jpg, .png oder .eps
> 2. Extension ist .Z, .z, oder .gz (das wird ja IIRC in graphics.cfg
> festgelegt). Dann diese Endung wegschneiden und weiter bei Punkt 1.
> 3. Gar nichts trifft zu -> Error.
Eine Loesung, die in vielen Faellen wohl sinnvoller ist, kann man sehr
wohl basteln:
1. Dateinamen expandieren und in catcode-12-Zeichen wandeln
(\edef, \@onelevel@sanitize). \pdfximage kann zwar auch
Grafikdateien mit Leerzeichen verarbeiten, aber es gibt in TeX
keine Moeglichkeit, zu testen, ob diese Datei existiert; graphics
moechte da eine Fehlermeldung ausgeben, bzw. muss es
bei weggelassener Endung ja nach den Dateien suchen.
2. Umdrehen
3. In einer Schleife die Endung abspalten und umdrehen und
mit bekannten Endungen vergleichen.
In der Theorie haengt dann das Ergebnis von der Reihenfolge
der Vergleiche ab:
a.b.c.d, [.d, .c.d, .b.c.d] ==> .d
a.b.c.d, [.c.d, .b.c.d, .d] ==> .c.d
a.b.c.d, [.b.c.d, .d, .c.d] ==> .b.c.d
> > Oder kannst du mir sicher sagen, was die Dateiendung von
> > a.b.c.d.e
> > ist?
> >
> e: wenn ich rechts anfange zu suchen. Von Links geht das natürlich
> nicht.
D.h. bei ".ps.gz" handelt es sich gar nicht mehr um eine Dateiendung?
;-)
> > Es kommt hinzu, dass es auf die Reihenfolge der Liste der bekannten
> > Endungen ankommt: .a, .b.a, .c.b.a Was soll bei d.c.b.a zuerst
> > gefunden werden?
> >
> Von links kann ich gar nichts entscheiden, weil ich erst bis ganz
> rechts parsen müßte, um mir die letzte Endung anzuschauen und dann zu
> entscheiden, ob man (a) ein komprimiertes File vor sich hat oder (b)
> schon klar ist, was das ist (s.o.).
Aus dem "Namen" der Endung kann man nicht sicher auf den Typ
schliessen. Hier im Thread hatten wir es ja mit einer PDF-Datei "a.z"
zu tun. Neben der "falschen" Endung kann es aber auch moeglich
sein, dass eine "komprimierte" Endung mit der Endung eines
Bildformates uebereinstimmt.
Viele Gruesse
Heiko <ober...@uni-freiburg.de>
Stefan Ulrich
>> Hmm, man könnte den Dateinamen umdrehen und dann von links nach rechts
>> parsen ;-)
> 1) Das ist ja noch viel aufwendiger, wenn man es wie hier bei Dateinamen
> nur einmal braucht. Solche Rekursionen fressen enorme Resourcen.
> 2) Warum hast du dich in deinem Beispiel für Hangeln und nicht
> für Umdrehen entschieden?
Hrmpf. Deswegen ja der Smiley und der darauf folgende Satz `Aber
eigentlich ...'
--
Stefan Ulrich
Hilmar Preuße
> Hilmar Preuße <hil...@despammed.com> wrote:
>> Heiko Oberdiek <ober...@uni-freiburg.de> wrote:
Hallo,
>> > In pdfTeX gibt es so eine Default-Regel nicht. Der eine verwendet
>> > primaer Screenshots mit .png-Dateien, der andere setzt ein
>> > Fotoalbum mit .jpg-Dateien, wieder ein anderer importiert haeufig
>> > .pdf-Dateien. Sinn machen koennte eine Default-Regel hier nur
>> > fuer MetaPost-Ausgabedateien, da man diese dann nicht in .mps
>> > umbenennen muss, damit sie erkannt werden.
>> >
>> Hmm. Unter UNIX gibt es file(1). Das kann man nicht in TeX
>> implementieren, das seh ich ein.
>
> pdfTeX macht das, es sieht sich die Magic Numbers an, um zu
> entscheiden, was fuer ein Grafikdateiformat es bei
> \pdfximage{} vorliegen hat.
>
Gut, ist ja schon mal ein Anfang.
Versteh ich nicht. Wenn ich nach dem Umdrehen von links anfange zu
parsen, beim ersten Punkt anhalte und alles, was ich bis dahin
gefunden habe zurückdrehe, ist das doch eindeutig.
>> > Oder kannst du mir sicher sagen, was die Dateiendung von
>> > a.b.c.d.e
>> > ist?
>> >
>> e: wenn ich rechts anfange zu suchen. Von Links geht das natürlich
>> nicht.
>
> D.h. bei ".ps.gz" handelt es sich gar nicht mehr um eine
> Dateiendung? ;-)
>
Eher ein Endung 2. Ordnung, bei der erkannt wird, daß die letzte
Extension wegzuschneiden ist, um das File an der Extension zu
erkennen.
>> > Es kommt hinzu, dass es auf die Reihenfolge der Liste der
>> > bekannten Endungen ankommt: .a, .b.a, .c.b.a Was soll bei
>> > d.c.b.a zuerst gefunden werden?
>> >
>> Von links kann ich gar nichts entscheiden, weil ich erst bis ganz
>> rechts parsen müßte, um mir die letzte Endung anzuschauen und dann
>> zu entscheiden, ob man (a) ein komprimiertes File vor sich hat
>> oder (b) schon klar ist, was das ist (s.o.).
>>
> Aus dem "Namen" der Endung kann man nicht sicher auf den Typ
> schliessen. Hier im Thread hatten wir es ja mit einer PDF-Datei
> "a.z" zu tun.
>
Nein. Das File hieß a.z.pdf und sollte mittels \includegraphics{a.z}
eingebunden werden. Oder hab ich das falsch verstanden und pdfTeX
sucht bei Angabe von $Dateiname nicht automagisch nach
$Dateiname.{pdf,mng,png,jpg} ? Test: Nein tuts nicht, wenn Punkte im
Dateinamen sind, womit wir wieder beim Ausgangspunkt wären. Da hilft
nicht einmal Angabe von a.z.pdf.
> Neben der "falschen" Endung kann es aber auch moeglich sein, dass
> eine "komprimierte" Endung mit der Endung eines Bildformates
> uebereinstimmt.
>
Gut, ich geh natürlich davon aus, daß alle Datei-Endungen eindeutig
sind. Bei 36+36^2+36^3=47988 Möglichkeiten sollte ja noch genug frei
sein...
Greets,
H.
P.S.: Falls ich zu inkompetent wirke, sag einfach EOT.
--
http://hilmarpreusse.forum-rheinland.de/
Heiko Oberdiek
> Heiko Oberdiek <ober...@uni-freiburg.de> wrote:
> [...]
> > In der Theorie haengt dann das Ergebnis von der Reihenfolge
> > der Vergleiche ab:
> >
> > a.b.c.d, [.d, .c.d, .b.c.d] ==> .d
> > a.b.c.d, [.c.d, .b.c.d, .d] ==> .c.d
> > a.b.c.d, [.b.c.d, .d, .c.d] ==> .b.c.d
> >
> Versteh ich nicht. Wenn ich nach dem Umdrehen von links anfange zu
> parsen, beim ersten Punkt anhalte und alles, was ich bis dahin
> gefunden habe zurückdrehe, ist das doch eindeutig.
Damit ist ".ps.gz" keine Endung und eine solche Erkennung durch
graphics/dvips.def ein Bug?
[...]
> P.S.: Falls ich zu inkompetent wirke, sag einfach EOT.
Ersteres nicht, aber zweiteres macht Sinn.
Versuchte Zusammenfassung:
Derzeit teilt graphics den Dateinamen in Grundname und
Endung und vergleicht dann die Endung mit bekannten.
Als Ergebnis des Threads sehe ich nun die Skizze einer
Methode, dass graphics die Kenntnis der unterstuetzten
Endungen bereits zum Dateinamen-Parsen nutzt.
Eine Endung darf dabei mehrere Punkte enthalten, um
".ps.gz" usw. zu finden. Ebenfalls darf der Grundname
Punkte enthalten.
Theoretische Grenzen und deren praktische
Relevanz sind diskutiert. (Bekannte Endungen .a und .b.a).
Sogar Implementationsmethoden
wurden bereits behandelt (rekursiv von vorne, bzw.
String-Revertierung).
Jetzt muss das nur jemand sauber spezifizieren und
implementieren ...
Viele Gruesse
Heiko <ober...@uni-freiburg.de>
Heiko Oberdiek
> Versuchte Zusammenfassung:
> [...]
> implementieren ...
%%% cut %%% grffile.sty %%% cut %%%
\NeedsTeXFormat{LaTeX2e}
\ProvidesPackage{grffile}%
[2004/07/18 v0.5 Extended file name support for graphics (HO)]
% The package defines three options that allows a larger range
% of file names that can be used with graphics or graphicx.
%
% "multidot"
%
% The file name parsing is changed, in order to detect
% known extensions. This allows both the use of dots inside the
% base name and extensions with several dots.
%
% Example:
% \usepackage[multidot]{grffile}
%
% % Files: Hello.World.eps, Hello.World.pdf
% \includegraphics{Hello.World}
% % will find "Hello.World.pdf" with driver "pdftex"
% % or "Hello.World.eps" with driver "dvips".
%
% "extendedchars"
%
% If the input encoding is the same encoding as the encoding that
% is used for file names and the driver allows non-asscii characters,
% then this option can be used to try file names with such characters.
%
% Example:
% \usepackage[latin1]{inputenc}
% \usepackage[extendedchars]{grffile}
% \includegraphics{Bäckerstraße}
%
% If "draft" is enabled, the file name is printed with the
% current font encoding for \ttfamily. Thus it is possible,
% that such characters are omitted or the wrong characters
% are displayed, if the font encoding is not the same as
% the file name encoding.
%
% "nofilecheck"
%
% \TeX\ considers the space character as termination in its
% syntax for commands that expect a file name.
% Therefore files with spaces cannot be used with TeX.
% However, pdfTeX's primitive \pdfximage that is used for
% including file names uses curly braces to delimit the
% file name, so spaces are possible.
% But the \TeX's limitation applies for some operations
% of the graphics package:
% * Print a warning message, if the file cannot be found.
% * If a file name is given without extension, then graphics
% looks for an existent file with a supported file extension.
% Both relies on existence checks that are done by TeX's
% limited primitives.
%
% Option "nofilecheck" disables both features to allow
% files with spaces. This works for pdf\TeX, if the
% file is given with extension. But beware, many of the other
% drivers does not expect spaces in file names and this can
% lead to errors in the process chain after the \LaTeX\ run.
%
% Example:
% \usepackage[pdftex]{graphics}
% \usepackage[multidot]{grffile}
%
% \includegraphics{Hello World.pdf}% the extension must be given
%
% Use
%
% The options can be given at many places:
%
% a) Package: \usepackage[<options>]{grffile}
%
% The following possibilities are supported, if package graphicx
% is used:
%
% b) Graphics configuration: \setkeys{Gin}{<options>}
%
% c) Applying of options for just one file:
% \includegraphics[<options>]{...}
%
\newif\ifGin@multidot
\newif\ifGin@extendedchars
\newif\ifGin@nofilecheck
\DeclareOption{multidot}{\Gin@multidottrue}
\DeclareOption{extendedchars}{\Gin@extendedcharstrue}
\DeclareOption{nofilecheck}{\Gin@nofilechecktrue}
\DeclareOption*{\PassOptionsToPackage\CurrentOption{graphics}}
\ProcessOptions\relax
\RequirePackage{graphics}
% Support for graphicx
% Test for \define@key without defining it
\begingroup\expandafter\expandafter\expandafter\endgroup
\expandafter\ifx\csname define@key\endcsname\relax
% package keyval is not loaded yet, thus its definitions
% are used here to define the new options.
% \@ifnextchar and \@namedef are provided by miniltx.tex.
\def\Gin@define@key#1#2{%
\@ifnextchar[{%
\Gin@KV@def{#1}{#2}%
}{%
\@namedef{KV@#1@#2}####1%
}%
}%
\def\Gin@KV@def#1#2[#3]{%
\@namedef{KV@#1@#2@default\expandafter}\expandafter
{\csname KV@#1@#2\endcsname{#3}}%
\@namedef{KV@#1@#2}##1%
}%
\else
\let\Gin@define@key\define@key
\fi
\Gin@define@key{Gin}{nofilecheck}[true]{%
\lowercase{\Gin@boolkey{#1}}{nofilecheck}%
}
\Gin@define@key{Gin}{multidot}[true]{%
\lowercase{\Gin@boolkey{#1}}{multidot}%
}
\Gin@define@key{Gin}{extendedchars}[true]{%
\lowercase{\Gin@boolkey{#1}}{extendedchars}%
}
% paranoid catcode settings
\edef\Gin@RestoreCatcodes{%
\catcode`\noexpand\=\the\catcode`\=\relax
\catcode`\noexpand\:\the\catcode`\:\relax
\catcode`\noexpand\.\the\catcode`\.\relax
\catcode`\noexpand\'\the\catcode`\'\relax
\catcode`\noexpand\<\the\catcode`\<\relax
\catcode`\noexpand\*\the\catcode`\*\relax
\catcode`\noexpand\^\the\catcode`\^\relax
\catcode`\noexpand\~\the\catcode`\~\relax
}
\@makeother\=
\@makeother\:
\@makeother\.
\@makeother\'
\@makeother\<
\catcode`\*=11 %
\catcode`\^=7 %
\catcode`\~=\active
\expandafter\renewcommand\string *{\Ginclude@graphics}[1]{%
\begingroup
\ifGin@extendedchars
% babel characters
\csname @safe@activestrue\endcsname
% active ~
\edef~{\string~}%
% inputenc characters
\Gin@inputenc@loop\^^A\^^H%
\Gin@inputenc@loop\^^K\^^K%
\Gin@inputenc@loop\^^N\^^_%
\Gin@inputenc@loop\^^?\^^ff%
\fi
\let\input@path\Ginput@path
\ifGin@multidot
\let\filename@simple\Gin@filename@simple
\let\filename@base\@empty
\fi
\filename@parse{#1}%
\ifx\filename@ext\relax
\ifGin@nofilecheck
\else
\@for\Gin@temp:=\Gin@extensions\do{%
\ifx\Gin@ext\relax
\Gin@getbase\Gin@temp
\fi
}%
\fi
\else
\ifGin@nofilecheck
\edef\Gin@base{\filename@area\filename@base}%
\edef\Gin@ext{\Gin@sepdefault\filename@ext}%
\else
\Gin@getbase{\Gin@sepdefault\filename@ext}%
\ifx\Gin@ext\relax
\@warning{File `#1' not found}%
\def\Gin@base{\filename@area\filename@base}%
\edef\Gin@ext{\Gin@sepdefault\filename@ext}%
\fi
\fi
\fi
\ifx\Gin@ext\relax
\@latex@error{File `#1' not found}%
{I could not locate the file with any of these %
extensions:^^J%
\Gin@extensions^^J\@ehc}%
\else
\@ifundefined{Gin@rule@\Gin@ext}{%
\ifx\Gin@rule@*\@undefined
\@latex@error{Unknown graphics extension: \Gin@ext}\@ehc
\else
\expandafter\Gin@setfile\Gin@rule@*{\Gin@base\Gin@ext}%
\fi
}{%
\expandafter\expandafter\expandafter\Gin@setfile
\csname Gin@rule@\Gin@ext\endcsname{\Gin@base\Gin@ext}%
}%
\fi
\endgroup
}
\def\Gin@inputenc@loop#1#2{%
\count@=`#1\relax
\loop
\begingroup
\uccode`\~=\count@
\uppercase{%
\endgroup
\edef~{\string~}%
}%
\ifnum\count@<`#2\relax
\advance\count@\@ne
\repeat
}
\def\Gin@filename@simple#1.#2\\{%
\ifx\\#2\\%
\let\filename@ext\relax
\else
\expandafter\ifx\csname
Gin@rule@.\filename@dot #2\\\endcsname\relax
\edef\filename@base{\filename@base #1.}%
\Gin@ReturnAfterFiFiBase{\Gin@filename@simple #2\\}%
\else
\edef\filename@ext{\filename@dot #2\\}%
\fi
\fi
\edef\filename@base{\filename@base #1}%
}
\def\Gin@ReturnAfterFiFiBase#1#2\filename@base#3{\fi\fi#1}
\Gin@RestoreCatcodes
\endinput
%%% cut %%% grffile.sty %%% cut %%%
Viele Gruesse
Heiko <ober...@uni-freiburg.de>
Hilmar Preuße
Hallo,
>> Versuchte Zusammenfassung:
>> [...]
>> implementieren ...
>
> %%% cut %%% grffile.sty %%% cut %%%
> \NeedsTeXFormat{LaTeX2e}
> \ProvidesPackage{grffile}%
> [2004/07/18 v0.5 Extended file name support for graphics (HO)]
>
Wahnsinn. Dankeschön!
Da ich die Codequalität nicht beurteilen kann (ich hab erst die
Standardfälle getestet und die tun): hat es Sinn im LaTeX BTS jetzt
einen wishlist bug einzukippen, auf daß im nächsten graphics-release
das Paket zumindest als add-on dabei ist?
Danke,
Hilmar
--
wir hatten schonmal irgendwo die windows-source her, aber die is jetz
irgendwie nich mehr da wo sie mal war.
gibt es sonst noch irgendwelche open-source-projekte wie windows???
("Rascal2k" in <970532c.02061...@posting.google.com>)
Hilmar Preuße
Moin,
[Dateinamen von rechts parsen?]
>
>> Das wäre schön! Aber mehr als von vorne nach hinten hangeln ist
>> mit TeX leider nicht möglich. Und Durchhangeln ist aufwendig und
>> sehr Resourcen fressend.
>
> Hmm, man könnte den Dateinamen umdrehen und dann von links nach
> rechts parsen ;-)
>
Oder so. Das hatte ich woanders ja angedeutet.
> Aber eigentlich muß man sich doch im Grunde nur die letzten beiden
> Extensionen anschauen und dann überprüfen, ob die letzte eine
> bekannte gz/bz2 usw. ist. Hier ist mal ein schneller
> Proof-of-Concept-Hack, wie man an die letzten beiden Extensionen
> kommt; ich bin mir sicher, dass echte TeXianer das auch ohne
> globale Register und effizienter können ;-)
>
Jo, auch an Dich erstmal ein dankeschön! Heiko hat ja inzwischen eine
generalisierte Lösung implementiert, die ich bisher nur kurz getestet
habe und die auch in der Kombination der drei Anwendungsfälle zu tun
scheint.
Grüße,
Hilmar
--
Gewöhne Dich bitte an den Gedanken, dass auf Deinem System ein Kernel
läuft, der sich um die Ressourcenverwaltung kümmert, und dass Du kein
Kernel bist.
<87r86jo...@winter.inter-i.wohnheim.uni-mainz.de>
Rolf Niepraschk
...
>
> Wahnsinn. Dankeschön!
> Da ich die Codequalität nicht beurteilen kann (ich hab erst die
> Standardfälle getestet und die tun): hat es Sinn im LaTeX BTS jetzt
> einen wishlist bug einzukippen, auf daß im nächsten graphics-release
> das Paket zumindest als add-on dabei ist?
>
Tue es. Viel Hoffnung hab ich aber nicht, wenn man die ausstehenden Bug
Reports in der Rubrik "graphics" betrachtet ;-(
...Rolf
--
|| Rolf Niepraschk c/o Physikalisch-Technische Bundesanstalt ||
|| Abbestr. 2-12; D-10587 Berlin, Germany ||
|| Tel/Fax: ++49-30-3481-316/490, email: Rolf.Ni...@ptb.de ||
Heiko Oberdiek
> Jo, auch an Dich erstmal ein dankeschön! Heiko hat ja inzwischen eine
> generalisierte Lösung implementiert, die ich bisher nur kurz getestet
> habe und die auch in der Kombination der drei Anwendungsfälle zu tun
> scheint.
Ja, die drei Optionen sollten sich gegenseitig nicht stoeren und sind
daher beliebig kombinierbar.
Viele Gruesse
Heiko <ober...@uni-freiburg.de>
Heiko Oberdiek
> Heiko Oberdiek <ober...@uni-freiburg.de> wrote:
> > Heiko Oberdiek <ober...@uni-freiburg.de> wrote:
>
> >> Versuchte Zusammenfassung:
> >> [...]
> >> implementieren ...
> >
> > %%% cut %%% grffile.sty %%% cut %%%
> > \NeedsTeXFormat{LaTeX2e}
> > \ProvidesPackage{grffile}%
> > [2004/07/18 v0.5 Extended file name support for graphics (HO)]
> >
> Wahnsinn. Dankeschön!
> Da ich die Codequalität nicht beurteilen kann (ich hab erst die
> Standardfälle getestet und die tun): hat es Sinn im LaTeX BTS jetzt
> einen wishlist bug einzukippen, auf daß im nächsten graphics-release
> das Paket zumindest als add-on dabei ist?
* multidot
Die generalisierte Verwendung halte ich fuer sinnvoll.
Probleme koennte es mit Systemen geben, die nicht mit einem Punkt
als Endungstrenner arbeiten, d.h. Systeme, die dann auch ein eigenes
texsys.cfg mit Definitionen fuer \filename@parse etc. brauchen.
Mangels Beispiel konnte ich das nicht testen.
* extendedchars
Da gibt es zuviele Einschraenkungen aufgrund der Encodingprobleme.
Wie muss ein Dateiname mit Umlauten angesprochen werden, in welchem
Encoding? Angenommen, der Dateiname sei in latin1 kodiert, das
TeX-Dokument soll aber in UTF-8-Encoding geschrieben werden?
Dann funktioniert die Option "extendedchar" auch, aber im
\includegraphics-Befehl muss dann der latin1-kodierte Dateiname
stehen.
* nofilecheck
Das ist im wesentlichen eine Notloesung fuer pdfTeX, um Leerzeichen im
Namen zu erlauben. Die Einschraenkung, die automatische
Dateiendungserkennung abzuschalten, halte ich fuer gross, da ja oft
empfohlen wird, die Endung wegzulassen.
Hier kann sich die Situation verbessern, wenn es Erweiterungen der
TeX-Primitive gibt, die in anderer Syntax Leerzeichen zulassen.
Wenn sich das sicher auf TeX-Makroebene abfragen laesst, wuerde
ich das Paket entsprechend erweitern.
Ich glaube mich zu erinnern, dass MikTeX evtl. Leerzeichen zulaesst,
weiss jemand etwas genaueres?
Am sinnvollsten wuerde ich erachten, in graphics die Parsemethode
mit "multidot" auszustatten. Aufgrund des eingefrorenen Zustands
von LaTeX2e spare ich mir aber die Zeit, einen LaTeX-Feature-Request
abzuschicken. Die Zeit ist wohl besser in die Umwandlung der
.sty-Datei ins DTX-Format plus Doku investiert.
Viele Gruesse
Heiko <ober...@uni-freiburg.de>
Hilmar Preuße
> Hilmar Preuße wrote:
>> Da ich die Codequalität nicht beurteilen kann (ich hab erst die
>> Standardfälle getestet und die tun): hat es Sinn im LaTeX BTS
>> jetzt einen wishlist bug einzukippen, auf daß im nächsten
>> graphics-release das Paket zumindest als add-on dabei ist?
>
> Tue es. Viel Hoffnung hab ich aber nicht, wenn man die ausstehenden
> Bug Reports in der Rubrik "graphics" betrachtet ;-(
>
Bug war schon drin (graphics/3576). Ich hoffe, mein Followup kommt
durch.
H.
--
cd mutt-1.2.5;
./configure --enable-full-quote --with-reverse-quote --set-user-iq=0 \
--set-client-id=outlook --enable-funny-cards --disable-signature-mark
http://hilmarpreusse.forum-rheinland.de/
Hilmar Preuße
> Am sinnvollsten wuerde ich erachten, in graphics die Parsemethode
> mit "multidot" auszustatten. Aufgrund des eingefrorenen Zustands
> von LaTeX2e spare ich mir aber die Zeit, einen
> LaTeX-Feature-Request abzuschicken. Die Zeit ist wohl besser in die
> Umwandlung der .sty-Datei ins DTX-Format plus Doku investiert.
>
Ich werde mich mal dahinterklemmen. Da ich das aber zum ersten Mal
mache wird es wohl etwas länger dauern.
H.
--
When cryptography is outlawed, bayl bhgynjf jvyy unir cevinpl!
(Bernd Eckenfels)
http://hilmarpreusse.forum-rheinland.de/
http://charon.wh10.tu-dresden.de/~lego/textreff.html
Frank Küster
> Heiko Oberdiek <ober...@uni-freiburg.de> wrote:
>
>> Am sinnvollsten wuerde ich erachten, in graphics die Parsemethode
>> mit "multidot" auszustatten. Aufgrund des eingefrorenen Zustands
>> von LaTeX2e spare ich mir aber die Zeit, einen
>> LaTeX-Feature-Request abzuschicken. Die Zeit ist wohl besser in die
>> Umwandlung der .sty-Datei ins DTX-Format plus Doku investiert.
>>
> Ich werde mich mal dahinterklemmen. Da ich das aber zum ersten Mal
> mache wird es wohl etwas länger dauern.
Falls du mit Emacs arbeitest: Unbedingt ein CVS-AUCTeX verwenden, das
hat einen funktionierenden DocTeX-Mode.
Gruß, Frank
--
> <fluester> psst.. David - dein irony-detect.el ist kaputt! </fluester>
Ich benutze GNU Emacs, nicht XEmacs. irony-detect.el ist letztlich
von RMS abgelehnt worden, weil es vornehmlich Nutzern proprietärer
Systeme zugute käme [S.G. u. D.K. in dce]
Hilmar Preuße
> Hilmar Preuße <hil...@despammed.com> schrieb:
[.sty -> .dtx]
>> Ich werde mich mal dahinterklemmen. Da ich das aber zum ersten Mal
>> mache wird es wohl etwas länger dauern.
>
> Falls du mit Emacs arbeitest: Unbedingt ein CVS-AUCTeX verwenden, das
> hat einen funktionierenden DocTeX-Mode.
>
Nein, tu ich nicht. Totzdem danke an Dich für den Hint und an David
für aucTeX.
H.
--
Q. How come so many women love horses, which are big and dirty and smelly and
stupid and go to the bathroom all over the place, and yet women are highly
critical when men exhibit exactly these qualities? A. That is a good question.
http://hilmarpreusse.forum-rheinland.de/