graphicx - Umlaut im dateinamen / Miktex - Versionsproblem?

Hallo.
Ich hab ein .tex dokument, dass sich mit meiner aktuellen miktexversion (2.9, gestern auf mitkex.org geladen und installiert) nur dann kompilieren lässt, wenn ich den dateinamen im includegraphics-befehl ohne Umlaute schreibe (siehe Minimalbeispiel: Krafte.png statt Kräfte.png).
Habe in der pdf, die hier im Forum angegeben wird (l2picfaq.pdf), schon gelesen, dass sonderzeichen im dateinamen/pfad ein problem darstellen, bei den kommilitonen funktioniert es jedoch.

Minimalbeispiel:

Code:

---

\documentclass[notitlepage,12pt,a4paper,bibtotocnumbered]{scrreprt}

  \usepackage[UTF8]{inputenc}

\usepackage[T1]{fontenc}
\usepackage[ngerman]{babel}
\usepackage{marvosym}

  \usepackage[pdftex]{graphicx}

\usepackage{amsmath}               
\DeclareUnicodeCharacter{20AC}{\EUR}
\usepackage[bottom]{footmisc}
\usepackage{upgreek}
%\usepackage{textgreek}
\usepackage[colorlinks, linkcolor = black, citecolor = black, filecolor = black, urlcolor = blue]{hyperref}
\AtBeginDocument{%
\nonfrenchspacing%
}

\begin{document}

\begin{figure}[pb]
\begin{center}
\includegraphics[width=0.65\textwidth]{Krafte.png} %oder eben Kräfte.png
\label{Kräfte}
\end{center}
\end{figure}

\end{document}

---

Verwende ich "Kräfte.png" statt "Krafte.png" (beide Dateien existieren) erhalte ich als Fehler:

Code:

---

pdflatex.EXE: Windows API error 1113: Für das Unicode-Zeichen ist kein zugeordnetes Zeichen in der Mehrbytecodepage vorhanden.

texify: pdflatex failed for some reason (see log file).

---

Alle anderen Umlaute machen keine Probleme, sowohl ä,"a etc. als auch in dem label im MB.

Ich verwende hier (auf meinem Laptop) Windows 7 Home Premium 64bit (hoffe dass es dennoch das richtige forum hier ist), Miktex 2.9 mit TeXworks gestern heruntergeladen und installiert.

Wenn ich das oben genannte Minimalbeispiel jedoch auf meinem DesktopPC kompiliere funktioniert es mit "Krafte.png" als auch mit "Kräfte.png".
Dort ist Windows XP installiert und die Miktexversion ist ebenfalls 2.9, jedoch schon im Frühjahr 2011 installiert.
(Ich erwähne den Installationszeitpunkt weil ich bemerkt habe, dass einige pakete am 07.10.2011 geupdatet wurden.)
Außerdem hat ein Kommilitone von mir zufälligerweise den gleichen Laptop (ebenfalls Win7 HP 64bit) und auch er kann "Kräfte.png" verwenden. Seine Miktex 2.9 Installation ist allerdings ebenfalls älter (2 - 3 monate her).

Da ich mit anderen Leuten zusammenarbeite, die ihre Dateien unabhängig von mir benennen und ich mobil arbeiten muss, wäre es wichtig, dass auch auf dem laptop die verwendung von Umlauten im Dateinamen möglich wäre.

Oder ist euch Miktex versionsproblem bekannt?

Danke im Vorraus für eure Mühe.
Dude

Die Option utf8 schreibt man klein, und Umlaute in Dateinamen sind eine ebenso schlechte Idee wie Leerzeichen, und die Option pdftex benötigt kein Paket, sondern stört im Zweifelsfall eher.

Es gab mal einen Bug mit Umlauten:

http://sourceforge.net/tracker/?func...83&atid=110783

Auf meinem System (miktex 2.9/win xp) gibt es in nicht mehr, aber bei dir scheint er noch da zu sein. Wenn dein System aktuell ist, könnte sich ein Bugreport wie oben lohnen.

Aber obwohl ich im Prinzip Dateien mit Umlauten einfügen kann, kann ich dennoch Bilder mit Umlaufen in includegraphics nicht direkt verwenden, wenn inputenc benutzt wird. Mit inputenc ist das "ä" ein (ziemlich komplizierter) Befehl und der kann in Argument schon mal stören. In diesen Fällen geht sowas:

Code:

---

\documentclass{article}
\usepackage[utf8]{inputenc}
\usepackage[T1]{fontenc}
\usepackage{graphicx}
\begin{document}
\includegraphics{\detokenize{kräfte.jpg}}
\end{document}

---

Grundsätzlich würde ich aber dringend empfehlen Umlaute in Dateinamen zu vermeiden. Du musst daran denken, dass "kräfte" in einem utf8-Dokument anders kodiert ist als in einem ansinew-Dokument und wieder anders in einem applemac-Dokument. Und wie dein Dateisystem den Namen kodiert, weißt du auch nicht. Als das obige miktex-Problem auftauchte, habe ich auf der TeXLive-Liste gefragt, wie und wann dort Dateinamen mit Umlauten funktionieren, und es kam eine erstaunliche Anzahl von Varianten raus, je nach Betriebssystem, TeX-Version, Dokumentkodierung, Engine (pdftex/luatex) und Schriftkodierung (ohne [T1]{fontenc} gibt es immer Fehler).

Es kostet einfach zuviel Zeit, diese Probleme zu lösen. Einigt euch auf eine vernünftige Dateibenennung (keine Leerzeichen, keine Umlaute, dafür evtl Datum, Version, genaue Bezeichnung).

Ich ärgere mich seit geschlagenen zwei Tagen mit dem gleichen Fehler herum. :mad:

Das Tolle daran: Ich arbeite an zwei Rechnern an meinen Dokumenten. Als ich letztens am Rechner A meine Arbeit auf einen USB Stick gesichert habe und dann auf Rechner B weiterarbeiten wollte, gings auf einmal nicht mehr. Dabei war das bisher nie ein Problem. Auf beiden Rechnern halte ich MiKTeX auf dem letzten Stand.

Ein Minimalbeispiel:

Code:

---


\documentclass[
        11pt,
        a4paper,
        titlepage,
        onecolumn,
        oneside
        ]{scrbook}

\usepackage{graphicx}

\begin{document}

\begin{figure}[htbp]
        \centering
        \includegraphics[width=1.0\textwidth]{Bilder/Bildäü.pdf}
        \caption{caption}
        \label{label}
\end{figure}

\end{document}

---

So ein RiesenÄRGER. :mad:
LaTeX hat ja echt eine Menge Vorzüge, aber es sind genau diese Situationen wo die WORD-Bastler wieder Zeit gewinnen und aufholen, während ich mich herumärgern muss. ;)

Und ja, natürlich ist es schlau wenn man keine Sonderzeichen in Dateinamen verwendet, ist schon klar. Aber wir haben auch nicht mehr 1990. Das muss doch bitte möglich sein. Wars ja auch schon. Nur jetzt auf einmal nicht mehr. Was hab ich dir getan, LaTeX?

Edit: Hier noch der Fehlercode: Für das Unicode-Zeichen ist kein zugeordnetes Zeichen in der Mehrbytecodepage vorhanden.
Und in diesem Satz packt er es im Ausgabefenster auch nicht, das "ü" in "Für" korrekt darzustellen. ;)

Zitat:

---

LaTeX hat ja echt eine Menge Vorzüge, aber es sind genau diese Situationen, wo die WORD-Bastler wieder Zeit gewinnen und aufholen.

---

Ein Datei umzubenennen dauert keine 10 Sekunden.

Die Datei umzubennen, obwohl man weiß dass es
a) schon funktioniert hat und
b) funktioniert MÜSSTE
ist aber eine ganz andere Geschichte.

Dazu kommt: es sind sicher an die 30 Dateien die in mehrere Dokumenten verstreut zu suchen und umzubenennen wären (und dann nochmal das Ganze in den .tex files). Mittlerweile wäre ich sicher schneller gewesen, aber hier gehts auch ein bisschen ums Prinzip. ;)

Code:

---

aber hier gehts auch ein bisschen ums Prinzip.

---

Zum Prinzip habe ich ja schon einige Anmerkungen gemacht. Die Behandlung von nicht-ascii-Zeichen kann abhängen:

- von der Kodierung des Dokument
- inputenc oder nicht
- Implementierung der verwendeten Befehle (\detokenize oder nicht?)
- verwendete TeX-engine (pdftex/xetex/luatex)
- Betriebssystem
- Dateisystem
- bei utf8-Kodierung: Welche der möglichen Kodierung für ein Zeichen wird verwendet: Ist "ä" = U+00E4 oder = a + combining diaeresis (U+0308) ?


Zu rufen es "MÜSSTE" funktionieren ist billig. Tatsächlich ist es ein Tanz auf Eierschalen.

Dass das Verwenden von "Sonderzeichen" (sofern man so davon sprechen sollte wenn man Umlaute in einem deutsches Dokument setzen will :rolleyes:) ein Tanz auf Eierschalen ist, spricht wohl nicht für das System LaTeX.

Aber ich will ja gar nicht nur blöd unken und schimpfen. Es verwundert mich nur dass die (Basis?-) Funktionalität, die ich ja schon hatte, jetzt auf einmal nicht mehr da sein soll. Ich denke dass man das schon ernster nehmen sollte als es mit einem "dann benenne eben die Dateien um" zu quittieren.

Ich verwende tatsächlich inputenc (mit der Option [latin1], [utf8] funktioniert leider auch nicht), pdftex, das alles mit Windows 7 64 Bit.

Ich möchte noch anmerken dass es hier wohl um ein typisches "First World Problem" geht, und das ist mir auch sehr bewusst. Ich freue mich trotzdem wenn es gelingt eine Lösung dafür zu finden.

Es geht um Sonderzeichen IN DATEINAMEN, und das ist durchaus nicht nur in LaTeX ein Eiertanz. Es kann funktioneren, kann aber auch daneben gehen, sobald man solche Dateien z.B. auf einen anderen Computer übertragen will oder per E-Mail versenden. Es haben ja nicht alle das gleiche und neueste Betriebssystem, und die, die z.B. noch XP haben, haben nicht alle Deutsch als Grundsprache eingestellt...
Ich habe dieses Problem häufig mit kyrillisch benannten Dateien. Nicht in LaTeX, wohlgemerkt, da habe ich es aber ehrlich gesagt auch noch nicht ausproblert...

Zitat:

---

Es verwundert mich nur dass die (Basis?-) Funktionalität, die ich ja schon hatte, jetzt auf einmal nicht mehr da sein soll.

---

Tja, du hast halt eine der Eierschalen zerbrochen. Vielleicht hast du z.B. beim Kopieren auf deinen usb-Stick die Kodierung des Dateinamens verändert.

Zitat:

---

Ich verwende tatsächlich inputenc

---

Dann geht es ohne \detokenize normalerweise gar nicht.

Zitat:

---

mit der Option [latin1]

---

Wenn der Dateiname im Dokument in 8-Bit-Kodierung angegeben ist und im Dateisystem als utf8 kodiert ist, wie bitte solle pdftex in der Lage sein, die richtige Datei zu finden? Woher soll es wissen, dass, wenn in deinem Dokument ein Dateiname mit "11100100" (ansinew-ä) steht, es nach einer Datei mit "1100001110100100" (utf8-ä) in deinem Dateisystem suchen soll? (Falls dein Dateisystem überhaupt utf8 benutzt). Tatsächlich gibt sich das pdftex von miktex eine Menge Mühe nicht-ascii-Zeichen "sinnvoll" zu übersetzen, aber seine Möglichkeiten sind begrenzt und du hast viele Chancen es aus dem Tritt zu bringen.

Investiere eine halbe Stunde in die Umbennenung deiner Dateien (keine Umlaute, keine zusätzlichen Punkte, keine Leerzeichen) oder kämpfe immer mal wieder tagelang mit Kodierungsproblemen. Rumjammern, "das sollte aber nicht so sein", wird nicht helfen.

Also erstmal wird hier wohl ein großes Dankeschön fällig, dafür dass hier so prompt reagiert und geantwortet wird. Vor allem an Ulrike Fischer (und hier auch für die vielen anderen Beiträge, die mir schon (als anonymer Leser) geholfen haben).

Was die Kodierungsproblematik betrifft: Da habe ich wohl ein Einsehen, dass die Sache tiefer geht als mir bewusst und lieb ist. Ich werde wohl also in den sauren Apfel beißen und in meinem deutschen Dokument alle Bezüge ohne gefährliche Sonderzeichen umbenennen. Das wird ein Spaß. :(
Falls jemand die Energie, den Willen und / oder die Kenntnisse hat, diesen Fehler zu melden oder gar auszubessern, wäre das sicher sinnvoll um zukünftigen Usern zu helfen. Wie gesagt: das ist ja kein Feature-Wunsch sondern hat bisher immer super funktioniert (auch mit oftmaligem hin-und-her-Transfer via USB-Stick). Auf dem zweiten Rechner mit dem ich die Dokumente bearbeite, funktioniert es sogar immer noch (mit Windows XP).

Moin moin,

Zitat:

---

Zitat von DirtyHarry

Wie gesagt: das ist ja kein Feature-Wunsch sondern hat bisher immer super funktioniert (auch mit oftmaligem hin-und-her-Transfer via USB-Stick). Auf dem zweiten Rechner mit dem ich die Dokumente bearbeite, funktioniert es sogar immer noch (mit Windows XP).

---

in dem Fall wäre es vllt empfehlenswert, wenn Du die Unterschiede zwischen Deinen Systemen erstmal herausarbeitest -- immerhin hast Du ein System, auf dem es funktioniert, und eines, auf dem es nicht (mehr) funktioniert: was hat sich auf diesem System geändert? (So es denn auf diesem System bereits mit Umlauten im Dateinamen funktioniert hat) bzw. was genau ist der Unterschied zwischen beiden Systemen?

Für eine Kompromisslösung siehe Ulrikes Vorschlag mit \detokenize -- das funktioniert auch bei mir unter UTF8, bei dem z. B. ein `ä' zu `\IeC{\"a}' quasi übersetzt wird und mein Dateisytem so ein `\IeC{\"a}' nicht zu `ä' konvertiert ( beachte hier auch Ulrikes Hinweis in bezug auf Kodierung des Dateisystems) ... warum sollte es auch?

MfG

Zitat:

---

Zitat von rais

Moin moin,

in dem Fall wäre es vllt empfehlenswert, wenn Du die Unterschiede zwischen Deinen Systemen erstmal herausarbeitest -- immerhin hast Du ein System, auf dem es funktioniert, und eines, auf dem es nicht (mehr) funktioniert: was hat sich auf diesem System geändert? (So es denn auf diesem System bereits mit Umlauten im Dateinamen funktioniert hat) bzw. was genau ist der Unterschied zwischen beiden Systemen?

---

Das genau ist es ja was mich so verärgert / stutzig macht: ich habe an meinen Systemen wissentlich gar nichts geändert! Ich habe - wie immer - meine Dateien vom USB-Stick synchronisiert, geschrieben und wollte mir das Resultat als pdf ansehen. Und dann war keines mehr. Also, pdf meine ich jetzt. ;)

Den Workaround von Ulrike finde ich ok, aber da ändere ich glaube ich lieber gleich alles auf "ohne Sonderzeichen".

Was, in Bezug auf den Thread-Ersteller, der ja auch gemeint hat dass es an der MiKTeX-Version liegen könnte, schon spannend ist: Bei mir ist die Version bei der es nicht funktioniert übrigens auch neuer als die auf dem Rechner A wo alles klappt. Dort habe ich keine Admin-Rechte und das Aktualisieren ist nicht über die integrierte Updateoption von MiKTeX möglich.
Ursprünglich dachte ich auch, dass es am Verwenden des {textcomp}-Paktes liegt (das war eine wesentliche Änderung auf diesem Rechner A, auf dem das aber noch funktioniert hat). Das wars aber nicht. Alleine das herauszufinden hat mich Ungeübten Stunden gekostet... :rolleyes:

Ich glaube ich werden mich morgen daran machen die Dateinamen entsprechend abzuändern. Darf ich den "labels" weiterhin Sonderzeichen verwenden? Das wäre zumindest schon mal eine große Erleichterung.

Zitat:

---

Falls jemand die Energie, den Willen und / oder die Kenntnisse hat, diesen Fehler zu melden oder gar auszubessern

---

Nun, ich habe schon einmal einen Bugreport zu dem Thema gemacht. Aber da ich 1. derzeit keinen API-Fehler bekomme und 2. mir das Problem an der Hutschnur vorbeigeht, da ich nie Umlaute in Dateinamen benutze, werde ich keine weiteren Anstrengungen in diese Richtung unternehmen. Das wirst du schon selbst machen müssen. Du kannst dich ja an meinem Bugreport orientieren. Und sei bei deiner Beschreibung genau. Beim letzten Mal gab es den Fehler nur beim "ü", "ä" war OK.

Zitat:

---

Zitat von DirtyHarry

Darf ich den "labels" weiterhin Sonderzeichen verwenden?

---

das kann ich nicht beurteilen, ich hab noch nie Sonderzeichen innerhalb einer Marke verwendet. Zumindest dürfte das unabhängig vom verwendeten Dateisystem sein.

Zum Thema Bugreport kann ich nur sagen, dass ich mir als TeXLive-Nutzer unter Linux mit einer gegen Null strebenden Wahrscheinlichkeit `Windows API'-Fehler einhandle;-)

MfG

Zitat:

---

Darf ich den "labels" weiterhin Sonderzeichen verwenden?

---

Nun, mit pdflatex + inputenc wird \label{äöü} als

Code:

---

\newlabel{\"a\"o\"u}{....}

---

in der aux-Datei abgelegt. Ob das problematisch ist, hängt von der Definition von \"a usw ab, und die wiederum hängt von der Schriftkodierung ab.

Konkret: das hier wird dir mit pdflatex um die Ohren fliegen:

Code:

---

\documentclass{article}
\usepackage[ansinew]{inputenc}
%\usepackage[T1]{fontenc}
\begin{document}
\section{ABC}\label{äöü}
\ref{äöü}
\end{document}

---

Wenn du T1-encoding einschaltest, geht es wieder.

Mit XeTeX/luatex sind Umlaute in \label unproblematisch.

Wenn es bei dir zur Zeit funktioniert, wird es auch weiterhin gehen, solange du die Schriftkodierung deines Dokument nicht änderst. Betriebssystem, TeX-Version etc spielen hier keine Rolle.

Umlaute sind Befehle. Befehle in \label - und damit auch in \ref, \pageref etc. - zu verwenden, kann sehr schnell zu einem Problem führen:

Code:

---

\documentclass{article}
\usepackage[latin1]{inputenc}
\begin{document}
Test\label{sec:ä}
\end{document}

---

Hier wird in die aux-Datei

Code:

---

\newlabel{sec:\"a}{{}{1}}

---

geschrieben und das geht bereits beim Einlesen der aux-Datei während \end{document} in die Hose:

[1] (./test.aux
! Missing \endcsname inserted.
<to be read again>
\unhbox
l.2 \newlabel{sec:\"a}{{}{1}}
? x</pre>

Ok, ihr habt mich überzeugt. Ich werde mich brav von den Umlauten fernhalten. :)

so, ist etwas länger her. irgendwie war zwischenzeitlich mrunix.de nicht mehr erreichbar, und dann hatte ichs vergessen.

danke für die schnellen antworten. auch wenn ich ihn nicht komplett durchsteige, war trotzdem der link von u-fischer am hilfreichsten.

darin wurde ja erklärt, dass in den versionen vor juli 2011 eine andere kodierung verwendet wurde, was erklären würde, dass es auf meinem alten rechner funktioniert und auf dem zu meinem identischen von meinem kommilitonen, auf denen jeweils miktex vor dieser zeit installiert wurde.

zumindest scheint meine miktexinstallation in ordnung zu sein und wenn ich mich daran halte keine umlaute in dateinamen zu verwenden, geht erstmal alles, deswegen danke für die beruhigung.

allerdings sollte es ja eigentlich beim nächstn miktexupdate gelöst werden. falls das schon kam, dann muss man sagen, dass das problem noch nicht gelöst wurde.

btw: wie halte ich miktex denn aktuell? wie kann ich also updaten? unter start -> miktex -> maintenance -> update werden scheinbar nur die packages geupdatet, ist zumindest nur davon die rede. wird die miktexversion auch nur über solche packages geupdatet oder muss ich das noch irgendwo separat machen?

nochmals danke für die hilfe.

Updates innerhalb einer MiKTeX-Version gehen genau so. Upgrades von einer MiKTeX-Version auf eine andere erfordern hingegen (zumindest bisher) immer eine Neuinstallation. Über den Status der Releases muss man sich selbst informieren. Wobei man beispielsweise hier im Forum normalerweise schon mit bekommt, wenn eine neue Release erscheint.

Hallo,

als zweifelnder Latex Nutzer (Pflicht zur Promotion...) habe ich mich nun ungefähr ein Jahr hiermit rumgeschlagen. Sicherlich ist das Layout toll, aber bei mir überwiegt irgendwie immer wieder der Ärger. Seien es Positionierungen oder einfach die rückständige Eingabe von Sonderzeichen o.ä. Vielleicht habe ich aber auch die Systematik noch nicht verstanden.
Gestern ist mein Rechner abgeschmiert, konnte gerade noch so die Daten sichern und das Teil im abgesicherten Modus starten. Glücklicher Weise hab ich noch nen 2. Rechner. Kurz und knapp Latex (Texmaker) installiert, wollte voller Motivation arbeiten und stelle dann ebenfalls diese Scheiße mit obiger Fehlermeldung fest. Maximaler Zorn macht sich breit.
Den kaputten Schleppi genommen, ebenfalls eine komplette Neuinstallation Latex durchgeführt - funktioniert. Selbe Version, selbe Datei. Woran liegts? Kann mir bitte jemand erklären wie ich das Problem auf die Rolle bekomme? Habe die Mitteilungen hier gelesen, werde aber daraus nicht schlau. Muss nun im 21. Jahrhundert tatsächlich wieder von Umlauten Abstand genommen werden, die offenbar anderswo noch funktionieren? Oder kann mir jemand eine alte Version schicken? Ich hab keine Zeit mehr für diese Spielereien. Am Sonntag muss meine Diss fertig sein...

Please help me...
:-)

Markus

Zitat:

---

Please help me...

---

Wie denn? Du schreibst lang und breit über deinen Ärger, aber sparst dafür bei den Informationen.

Zitat:

---

Muss nun im 21. Jahrhundert tatsächlich wieder von Umlauten Abstand genommen werden, die offenbar anderswo noch funktionieren?

---

Tja, wenn du dir den Thread hier durchgelesen hast, kennst du ja meine Meinung: Verwende keine Umlaute in Dateinamen - außer du hast Zeit (und Lust), die damit einhergehenden Probleme zu lösen.

Hallo,

ok, hast Recht. immer diese Nörgler.

Ich hatte und hab halt keine Ahnung von den Bedürfnissen mit und um Latex. Habe hier eine Vorlage der TU die ich reichlich befüllt habe. Mit vielen Problemen musste ich kämpfen, habs aber dann soweit auf die Rolle gebracht.

Das hier ist mir ne Nummer zu hoch.

Wie gesagt habe ich die neueste Fassung installiert. Zunächst Miktex 2.9, um dann den Texmaker 3.1 hinterher zu schieben. Die Daten sind zunächst Bestand und haben bis zuletzt eben funktioniert. Wenn ich nun, ich hatte zuletzt "gesäubert" kompilieren will über den Schnellübersetzer legt er los, dann kommt kurzzeitig irgendeine Textmeldung mit dem api error 1113, und weiter passiert nix. gleiche einstellungen am anderen defekten rechner funktionierte problemlos. beides identische versionen, gleiches datenmaterial... an sonderzeichen könnte es liegen, habe die einige male verwendet, aber wenns auf dem einen klappt dann sollte es doch auch auf dem anderen...

markus

das hier ist die original fehler meldung. ich hab die umlaute aus den dateinamen entfernt, hat aber nix gebracht!

pdflatex: Windows API error 1113: Für das Unicode-Zeichen ist kein zugeordnetes Zeichen in der Mehrbytecodepage vorhanden.

Zitat:

---

aber wenns auf dem einen klappt dann sollte es doch auch auf dem anderen...

---

... wenn beide Systeme identisch sind. Aber da es nicht klappt, schließen wir messerscharf, dass die Systeme nicht identisch sind.

Zitat:

---

ich hab die umlaute aus den dateinamen entfernt, hat aber nix gebracht!

---

Dann hast du wahrscheinlich einen Dateinamen übersehen. Oder in irgendeiner der externen Dateien wurde noch auf Dateien mit Umlauten verwiesen. Oder die Umlaute sind in einem Ordnernamen (z.B. in deinem Usernamen) oder ...

ok, und nu?
das ist ja nicht mal eben eine seite getippt... mit sicherheit sind da verweise mit leerzeichen, unterstrich o.ä. drinne. das kann doch nicht ernsthaft bedeuten dass ich jetzt hier forschungsarbeit leisten muss? oder doch?
verzeihe bitte meine Intoleranz, aber wo bitte liegt jetzt noch gleich der Vorteil des Systems? Ich habe eine Hauptdatei die auf ca. 15 verschiedene unterdateien (kapitel) verweist. da brauch ich ein wochenende bis ich das auf der reihe hab. und vermutlich klappts dann immer noch nit.

liegts denn eigentlich an dem texmaker oder am miktex?

Zitat:

---

das kann doch nicht ernsthaft bedeuten dass ich jetzt hier forschungsarbeit leisten muss?

---

Wer sonst?

Zitat:

---

verzeihe bitte meine Intoleranz, aber wo bitte liegt jetzt noch gleich der Vorteil des Systems?

---

Hast du wirklich die Zeit in philosophische Diskussionen einzutreten?

Zitat:

---

Ich habe eine Hauptdatei die auf ca. 15 verschiedene unterdateien (kapitel) verweist. da brauch ich ein wochenende bis ich das auf der reihe hab.

---

15 Dateien mit sagen wir mal 100 Bildern oder anderen Inputdateien macht 115 Dateien. Wenn du für jede Datei zwei Minuten brauchst (was schon viel wäre), bist du in vier Stunden fertig -- unter der Annahme, dass jeder Dateiname Umlaute enthält. Man kann natürlich durch Auskommentieren von Kapiteln die Fehlerquelle zuerst eingrenzen.

Hallöle,

Faxen dick gehabt. Micktex runter geworfen, alten (2.8) drauf gespielt, funktioniert.
Problem somit gelöst mit sämtlichen Umlauten.

Ist schon Klasse wenn Systeme weiterentwickelt werden und hinterher gar nit mehr funktionieren. Nicht nur Bill Gates schafft das.
... hast aber Recht, Zeit für Philosophisches hab ich nicht, aber ist der Ärger erst mal da ist der Weg zu Spot nicht weit...

;):D

Ich danke für die Unterstützung und wünsche allseits eine schöne Weihnachtszeit. Sollte mal jemand Probleme im Bereich der Erneuerbaren Energien haben, helfe ich auch mal gerne weiter...

Markus