graphicx - Umlaut im dateinamen / Miktex - Versionsproblem?

[Dude85]

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:

\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:

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

[Schweinebacke]

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.

[u_fischer]

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:

\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).

[DirtyHarry]

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

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:

\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.
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.

[u_fischer]

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.

[DirtyHarry]

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.

[rstuby]

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...

[u_fischer]

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.

Ich verwende tatsächlich inputenc

Dann geht es ohne \detokenize normalerweise gar nicht.

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.

[DirtyHarry]

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).

[rais]

Moin moin,

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

[DirtyHarry]

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...

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.

[DirtyHarry]

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

[Dude85]

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.

[Schweinebacke]

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.

[Neise]

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?