guy.brush™
Hallo,
nachdem ich heute schon fast verrückt geworden bin, weil auf einmal Amarok noch Sound hatte, KDE Bimmelsounds auch, aber VLC, Audacious und Kaffeine streikten und ich das Problem endlich lösen konnte ... hier das nächste, das ich gerade nicht lösen kann.
Ich habe ja jetzt einen Brother DCP-9045CDN. Installiert via .ppd Datei und Anleitung von brother.de.
Ich wollte gerade ein Übungsblatt ausdrucken und siehe da, er er ersetzt teilweise Zeichen und Symbole durch andere, wie z.B. eine in der größe anpassende rechte Klammer in ein Summenzeichen (bis auf 1x, da klappt es irgenwdie). Beim nächsten Versuch (ich hatte zuvor noch einmal testweise komipiliert), druckt er ein anderes Symbol für die rechte Klammer. Auch andere Symbole ersetzt er teilweise.
Woran kann das liegen? Ich weiß leider nicht, was ich für Informationen euch noch geben kann. Wenn noch relevante Informationen noch fehlen, einfach bitte sagen, welche ich noch nachliefern soll 🙂.
Bei zwei anderen .pdf, die ich nicht erstellt habe, habe ich auf Anhieb nichts gefunden an fehlerhaften Darstellungen. Allerdings sind diese auch einseitig.
Lustig ist auch, dass die ForwardPDF Funktion oft nicht mehr funktioniert ... früher ist ja andauernd Okular dann abgestürzt.
Viele Grüße,
\ guy.brush
maltem
Als ich mal Probleme mit bestimmten PDF-Dokumenten auf Brother-Druckern hatte, half verrückterweise ein Downgrade von "file" (ich bleibe zurzeit bei file-5.04-3). Wenn ich mich richtig erinnere, bestand das Problem hier aber darin, daß bestimmte PDF-Dokumente gar nicht gedruckt wurden.
guy.brush™
Hmm ... ich hatte nochmal danach meine .pdf testweise gedruckt, dann hat es wieder funktioniert. Ich raffe überhaupt nicht, wo da der Fehler gelegen hat und wie der entstanden ist. Es wäre aber sicherlich sehr sinnvoll zu wissen, warum das so war und wie es eintreten konnte und wie es behoben worden ist (fall es jetzt konstant behoben worden ist und nicht nur zufällig richtig gedruckt worden ist). Bei einem Skript von 100-140 Seiten möchte ich nicht jede Seite einzeln erst einmal auf falsch gedruckte Symbole überprüfen 🙁.
guy.brush™
Ich muss leider den Thread bumpen. Das Problem tritt aktuell verhäuft auf und es ist etwas ärgerlich, weil ich noch keinen 100%-igen Workaround gefunden habe und bald 2 Skripte ausdrucken möchte.
Es scheint hauptsächlich eigene .pdf's zu betreffen, die ich selbst in LaTeX gesetzt habe. Ggf. macht er dann Mucken, wenn ich neu kompiliere und dann drucke.
Bei in LaTeX gesetzten .pdf's, die ich von anderen bekommen habe und die auch in LaTeX gesetzt worden sind, hatte ich das Problem bisher noch nicht. Auf jedenfall möchte ich nachher kein 100+ Seiten Skript wegwerfen müssen, nur weil es mir zu spät aufgefallen ist.
Woran könnte das liegen und wie kann man das ggf. beheben?
Da ich absolut keinen Plan hab, was die Ursache ist, kann ich auch leider keine weiteren Informationen liefert als die Beschreibung des Problems. Falls ihr aber noch Informationen braucht, sagt nur welche und ich reiche sie nach.
GerBra
Kabelproblem/bruch bzw Hardware ?
guy.brush™
Hm ... das Kabel liegt eigentlich eher weniger beansprucht herum. Es betrifft bisher irgendwie auch nur geteXte .pdf-Dokumente. (Okay, ich nutze anderes auch fast nicht mehr, aber es ist eben bisher nur bei eigens geteXten Sachen aufgetreten.)
Der Drucker ist eigentlich noch ziemlich neu, würde mich auch wundern, wenn daran was wäre. Ich wüsste jetzt aber auch nicht, wie ich das überprüfen könnte.
stefanhusmann
guy.brush™ schrieb
Bei in LaTeX gesetzten .pdf's, die ich von anderen bekommen habe und die auch in LaTeX gesetzt worden sind, hatte ich das Problem bisher noch nicht. Auf jedenfall möchte ich nachher kein 100+ Seiten Skript wegwerfen müssen, nur weil es mir zu spät aufgefallen ist.
Woran könnte das liegen und wie kann man das ggf. beheben?
Da ich absolut keinen Plan hab, was die Ursache ist, kann ich auch leider keine weiteren Informationen liefert als die Beschreibung des Problems. Falls ihr aber noch Informationen braucht, sagt nur welche und ich reiche sie nach.
Das Logfile eines von dir kompilierten Dokumentes könnte helfen. Erste Vermutung ist, dass bei dir irgendwelche nicht-Type1-Schriften eingebettet werden. Das Logfile könnte hier mehr sagen.
Hast du schon einmal eines der Dokumente, die bei dir problematisch sind, einem Kumpel gegeben, der sie für dich kompiliert und ausdruckt? Vorzugsweise ein Kumpel, der dir ein sauberes pdf gegeben hat?
Falls es bei dir ein Verzeichnis ~/.texlive gibt, könntest du das umbenennen.
guy.brush™
Hm ... ich könnte die .log File mal posten, aber ich glaube, das bringt im aktuellen Fall nichts. Bzw. ich habe gerade ein anderes Problem.
Und zwar habe ich (von Wikipedia) ein .png Bild eingefügt. Er druckt die Seite, auf der das Bild ist, mega schlecht, man kann es zwar noch lesen, aber es sieht ... hm sehr kaputt aus das Schriftbild. Die Folgeseiten sind wieder in Ordnung. Es sind diesmal keine Zeichen falsch, deshalb kann ich zu dem Zeichen-Problem nichts weiter sagen.
Ich habe schon probiert, ob es an dem Befehl \includegraphics liegt, aber das tut es auch nicht (bisher hatte ich Bilder immer als .pdf_tex gespeichert via Inkscape, da habe ich dann \input verwendet). Ich versuche hier schon eine 3/4 h lang herum und es tut einfach nicht. Ich habe auch eine altes Dokument testweise gedruckt und auch nochmal neu kompiliert (auf dem ein Bild ist), aber das Ergebnis ist weiterhin prima. Es ist ein von Inkscape erstelltes Bild und wie gerade beschrieben abgespeichert worden.
Ich habe über Konquerer anstatt Okular drucken lassen, selbes Ergebnis.
Also habe ich unter Windows und Foxit Reader gedruckt ... dieselbe Datei (nicht neukompiliert), die unter Linux Probleme macht ... und siehe da, es funktioniert!
Zumindest dieses neue Problem scheint ein Linux-basiertes Problem zu sein :/. Weiß einer Rat? Könnte es mit dem anderen Problem zusammenhängen? (Wobei ich beim Ausgangsproblem manchmal bisschen das Gefühl schon hatte, dass er die Daten falsch zum Drucker leitet und durch ein Löschen bzw. Resetten des Speichers im Drucker das ganze wieder funktioniert, was bei dem neuen Problem nicht der Fall ist ... allerdings konnte ich nicht herausfinden, wie ich den Speicher resette ohne dabei den Drucker aus- und anzumachen, was bei einem Laserdrucker ja nicht besonders gut sein soll, wegen abkühlen und neu aufwärmen etc. ... auf jedenfall konnte ich nicht ausfindig machen, wie das über eine Tastenkombination funktioniert ... weiß zufällig hier jemand Rat?)
stefanhusmann
guy.brush™ schriebHm ... ich könnte die .log File mal posten, aber ich glaube, das bringt im aktuellen Fall nichts. Bzw. ich habe gerade ein anderes Problem.
Und zwar habe ich (von Wikipedia) ein .png Bild eingefügt. Er druckt die Seite, auf der das Bild ist, mega schlecht, man kann es zwar noch lesen, aber es sieht ... hm sehr kaputt aus das Schriftbild. Die Folgeseiten sind wieder in Ordnung. Es sind diesmal keine Zeichen falsch, deshalb kann ich zu dem Zeichen-Problem nichts weiter sagen.
Ohne das Logfile tappen wir im Dunkeln
guy.brush™ schriebIch habe schon probiert, ob es an dem Befehl \includegraphics liegt, aber das tut es auch nicht (bisher hatte ich Bilder immer als .pdf_tex gespeichert via Inkscape, da habe ich dann \input verwendet). Ich versuche hier schon eine 3/4 h lang herum und es tut einfach nicht. Ich habe auch eine altes Dokument testweise gedruckt und auch nochmal neu kompiliert (auf dem ein Bild ist), aber das Ergebnis ist weiterhin prima. Es ist ein von Inkscape erstelltes Bild und wie gerade beschrieben abgespeichert worden.
Oben sprichst du von einem .png, jetzt von einenm .pdf? Was denn nun?
guy.brush™ schriebIch habe über Konquerer anstatt Okular drucken lassen, selbes Ergebnis.
Das muss auch egal sein.
guy.brush™ schrieb
Also habe ich unter Windows und Foxit Reader gedruckt ... dieselbe Datei (nicht neukompiliert), die unter Linux Probleme macht ... und siehe da, es funktioniert!
Dann mach das doch so! oder poste die Logdatei.
guy.brush™
stefanhusmann schriebOhne das Logfile tappen wir im Dunkeln
Hier. Ich wusste leider nicht, was ich da alles rauslöschen hätte können.
Oben sprichst du von einem .png, jetzt von einenm .pdf? Was denn nun?
Ich erwähnte in meinem vorherigen Post, dass ich ein weiteres Problem habe.
Das muss auch egal sein.
Wieso denn? Wenn Okular etwas falsch interpretieren würde, wieso muss das zwangsläufig dann auch Konqueror?
Dann mach das doch so! oder poste die Logdatei.
Öh ... ich hatte jetzt nicht vor, fortan immer unter Windows zu drucken o.O.
Das zweite Problem erschien mir eben LaTeX-unabhängig, da es unter Windows funktioniert, unter Linux aber nicht. Trotzdem hast du oben die .log-Datei. Das Ausgangsproblem konnte noch nicht reproduziert werden, weshalb es dazu noch keine .log-Datei gibt.
stefanhusmann
Okay, die Logdatei sieht soweit auch okay aus. Meine erste Vermutung hat sich nicht bestätigt. Ich würde allerdings Umlaute im Dateinamen vermeiden, und mit \usepackage{lmodern} die Latin Modern Fonts einbinden. Die sind in jeder Hinsicht besser als die cmsuper-Fonts, die bei dir eingebunden werden.
Das muss auch egal sein.
Wieso denn? Wenn Okular etwas falsch interpretieren würde, wieso muss das zwangsläufig dann auch Konqueror?
Beide Programme dürften beim Drucken nichts interpretieren, sondern dies CUPS oder letztlich ghostscript überlassen.
guy.brush™
Hm, Latin Modern mochte ich noch nicht so sehr irgendwie 🙂. Das hat bisher ja auch noch keinen anderen Mathe-Zeichen und ich wollte erst einmal abwarten, was sich da so ergibt ... bin kein Freund von Änderungen 🙂. Oder was hat lmodern sonst noch für Vorteile in Bezug auf mögliche Fehler?
Wo könnten denn Umlaute in Dateinamen Probleme machen?
Ich habe gerade das nächste Übungsblatt ausdrucken wollen und siehe da ... genau das Ausgangsproblem mit den zerhackten Zeichen. Hier deshalb die
.log-Datei. Ein Ein- und Ausschalten (das tut mir immer weh, ich denke immer, dass der Drucker sich irgendwann rächt :/) des Druckers und erneutes Drucken
ohne die Datei neu zu kompilieren, ergab jedoch einen Ausdruck, der keine zerhackten Symbole mehr hatte 🙁.
Machmal bekomme ich das Gefühl, er druckt mir dann zerhackte Zeichen aus, wenn ich etwas frisch kompiliertes ausdrucken möchte.
bernarcher
Ohne Idee für eine konkrete Lösung zu haben - aber das sieht nach einer fehlerhaften Initialisierungssequenz für den Drucker aus.
Die Logdatei gibt beim Überfliegen allerdings nicht viel dazu her.
Um den Fehler einzugrenzen, könntest du mal versuchen ein Beispiel mit Standard-LaTeX zu kompilieren und dann die dvi-Datei explizit mit dvipdf umsetzen zu lassen. Funktioniert das dvi, aber nicht das resultierende pdf, dürfte der Fehler irgendwo in deiner Ghostscript-Installation liegen.
stefanhusmann
cmsuper ist ne Krücke, die verwendet wurde, als noch nichts Besseres in T1-Kodierung und Type1-Format da war. Die Latin Modern Fonts haben wie gesagt nur Vorteile. Aber mit deinem Problem hat dies direkt nichts zu tun.
guy.brush™
Oh, ich vergaß zu schreiben:
Wenn ich die .pdf mit Standard-LaTeX kompilieren lasse, erscheint folgende Meldung:
Cannot determine size of graphic in gitter.png (no BoundingBox). \includegraphics[width=7.42cm]{gitter.png}
Die betroffene Code-Stelle sieht wie folgt aus:
\begin{figure}[!ht]
\centering
\includegraphics[width=7.42cm]{gitter.png}
\caption{Gitter (freies Bild von Wikipedia)}
\label{fig:gitter}
\end{figure}
Ohne Verkleinerung ist dieses Bild leider viel zu groß, aber mich wundert, warum er meckert.
Viele Grüße,
\ guy.brush
stefanhusmann
Standard-LaTeX (du sprichst vermutlich vom Aufruf latex <dateiname>) kennt kein .png-Format. Daher versucht er an dieser Stelle, die Datei als .eps einzubinden, und beschwert sich über die fehlende Bounding Box. Mit convert aus dem imagemagick-Paket kannst du aus gitter.png gitter.eps machen.
Beim \includegraphics-Befehl solltest du die Dateieindung nicht mit angeben. Er sucht sich dann schon das raus, mit dem er am besten arbeiten kann.
guy.brush™
Also Druck via Standard-LaTeX --> dvipdfmx --> Drucken ergab wieder ein normales Schriftbild (lediglich am Bild hat er bisschen was anders gedruckt, das kann aber an noch nicht optimal eingestellter Kalibration liegen. Es handelts ich dabei um
dieses Bild von Wikipedia. Er hat die schwarzen Kreise nicht ganz optimal am unteren linken Rand gedruckt wie sonst zuvor immer.
Diesem Umweg für das Ausgangsproblem zu machen, erachte ich aber als weniger sinnvoll. Das Ausgangsproblem kann man ja scheinbar mit Drucker ausschalten (*aua*) und direkt wieder anschalten lösen ... das ist aber keine gute Lösung :/.
Zum \includegraphics Befehl: Ich sollte, aber es sollte auch nichts passieren, wenn ich es mache ... habe ich das so richtig verstanden? Bei meinem jetztigen Testdurchlauf habe ich es am Ende noch einmal explizit mit .eps gemacht und pdflatex. Das Ergebnis war/ist lustigerweise gleich zum Umweg über .dvi. ... evtl. ein Problem mit .png Dateien? Wenn ich keine .eps Endung angebe, druckt er allerdings genau so wie bei .png (beim pdflatex-Weg).
guy.brush™
Heidewitzka ... jetzt habe ich das erste Mal eine .pdf von jemand anderem zugeschickt bekommen und dort dasselbe: Die erste Seite ist mies von der Qualität her, die zweite normal. Auf der ersten Seite ist aber auch ein Bild.
Ich weiß, dass das Dokument in Word erstellt worden ist und mir extra als .pdf zugeschickt worden ist, weil ich nicht alle Schriften habe. Als ich dann das .doc Dokument gedruckt habe, passt alles (gedruckt via LibreOffice), bis auf die Tatsache, dass er das eingefügte Bild statt weiß eben schwarz hinterlegt hat (es handelt sich aber nicht um ein negativ, lediglich der Hintergrund wurde schwarz gedruckt).
Langsam geht das ganze Testen wirklich ins Geld und ich bin mega angepisst davon :/. Ich habe bestimmt wegen Problemen schon 50+ Blätter bedruckt, teilweise mehrfach (nicht nur wegen diesem Problem).
Was kann ich noch tun, um den Fehler zu beheben?
Lustig ist auch, dass mein altes Standard-Druckerprofil Duplex-Druck nicht mehr macht aus Okular heraus. Aus LibreOffice aber schon noch. Es nervt, andauernd ein neues Druckerprofil anlegen zu müssen, nur weil das alte wieder herumspackt. Was kann ich dagegen tun?
Ich dachte nicht, dass Drucker unter Linux dermaßen schlecht unterstützt werden :/.
guy.brush™
Das Thema ist immer noch aktuell.