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