• Willkommen im Linux Club - dem deutschsprachigen Supportforum für GNU/Linux. Registriere dich kostenlos, um alle Inhalte zu sehen und Fragen zu stellen.

pdf's drucken, wenn ein Drucker keinen randlosen Druck kann

Hallo,

jetzt versuche ich schon geraume Zeit ein pdf-Dokument auf meinem Drucker so auszudrucken, daß eben alles auch gedruckt wird. Leider kann man scheinbar auf meinem Billigdrucker (HP Deskjet 1660) nicht randlos drucken(obwohl man das bei CUPS und HPLIP so einstellen kann), aber auch wenn ich bei Okular die Ränder einstelle oder beim Acrobat Reader sage "Fit to Page" scheint das ignoriert zu werden. Die letzten Zeilen erscheinen dann auf dem Ausdruck nicht. Gibt es dafür eine bessere Lösung als einen Windows-Rechner dafür zu benutzen?

Falls es wichtig ist: installiert ist bei mir noch OpenSUSE 11.2.
 
Hi

Hast du mal versucht das ganze über einen anderen Reader als AR zu Probieren beziehungsweise über einen Editor?

cu
 

Rainer Juhser

Moderator
Teammitglied
Normalerweise hat das geschilderte Problem nichts mit Randlos-Druck zu tun. Zumindest der Acrobat Reader verkleinert bei den Einstellungen "Fit to Page" und "Shrink to Page" das Dokument so weit, dass es komplett auf die Seite (innerhalb der Default-Randeinstellungen) passt.

Aber vielleicht gibt es ein Problem mit dem Seitenformat (A4 vs. Letter), analog zu dem hier beschriebenen: http://www.linupedia.org/opensuse/Probleme_mit_OpenOffice_und_Brother_Druckern
 
Hallo,

das habe ich zunächst schon mit Okular versucht zu drucken und habe mir erst anschließend den Acrobat Reader installiert. Da es sich eben auch um ein Formular handelt, dachte ich, daß das am Besten geht. Als ich mir dann allerdings ein eigenes pdf erstellte, in dem ich den Rand oben und unten auf 0 stellte und das auch nicht sauber gedruckt bekam, habe ich mich entschlossen, andere hier zu quälen. Ich werde das heute auch mit einem Windows-Rechner versuchen zu drucken und dabei den Drucker verwenden, der an openSUSE hängt. Ich hatte diesen Drucker auch kurzzeitig unter Windows betrieben und konnte pdf's damit ordentlich drucken.

Nun habe ich es Versucht, von Windows aus (es ist ein eigenständiger Rechner der per Samba auf den Drucker zugreifen kann) ein pdf zu drucken. Unter Windows wird angezeigt, daß er die Druckgröße auf 95 % zoomed (openSUSE mit AR: 100 %) in beiden Fällen ist es egal, ob ich ein "Scaling" verwende oder nicht. Unter Windows ist es immer auf 95% und unter openSUSE auf 100 %. Nun sieht es aber so aus, als könne openSUSE mit diesen 95 % nichts anfangen, bewegt zwar den Druckkopf ein wenig und stoppt dann. Drucke ich dagegen von Windows aus ein Dokument, das beispielsweise mit Openoffice erstellt wurde, funktioniert das wie erwartet.

Das Fehlerprotokoll von CUPS gibt mir auch keinen Hinweis, was hier nicht stimmt:

Code:
I [20/Oct/2010:10:26:15 +0200] [Job 172] Adding start banner page "none".
I [20/Oct/2010:10:26:15 +0200] [Job 172] Adding end banner page "none".
I [20/Oct/2010:10:26:15 +0200] [Job 172] File of type application/vnd.cups-raw queued by "nobody".
I [20/Oct/2010:10:26:15 +0200] [Job 172] Queued on "Deskjet-D1600-series" by "nobody".
I [20/Oct/2010:10:26:15 +0200] [Job 172] Started backend /usr/lib/cups/backend/hp (PID 5733)
I [20/Oct/2010:10:26:15 +0200] [Job 172] Completed successfully.

@Rainer Juhser:
Ich kann bei mir A4 oder A4 Borderless wählen, das allerdings keine Auswirkung auf das Druckergebnis hat.

Versuche ich bei OpenOffice die Randeinstellungen alle auf 0 zu stellen, wird mir gemeldet, daß ich das nicht ausrucken könne. Verwende ich bei der Frage, ob ich diese Einstellungen dennoch verwenden will nein, setzt mir OpenOffice die Ränder auf den tatsächlich bedruckbaren Bereich.
 
In der Zwischenzeit habe ich hp-check aufgerufen, das mir drei fehlende Abhängigkeiten zeigte, die aber scheinbar nicht zwingend notwendig sind:

Code:
hp-check[7183]: info: :[01mChecking for dependency: PolicyKit - Administrative policy framework...[0m
warning: NOT FOUND! This is an OPTIONAL/RUNTIME ONLY dependency. Some HPLIP functionality may not function
 properly.

hp-check[7183]: info: :[01mChecking for dependency: Python libnotify - Python bindings for the libnotify Desktop notifications...[0m
warning: NOT FOUND! This is an OPTIONAL/RUNTIME ONLY dependency. Some HPLIP functionality may not function properly.

hp-check[7183]: info: :[01mChecking for dependency: Reportlab - PDF library for Python...[0m
warning: NOT FOUND! This is an OPTIONAL/RUNTIME ONLY dependency. Some HPLIP functionality may not function properly.

Wobei das letzte evtl. nötig sein könnte. Nur kann ich das über Yast nicht finden. python-ReportLab heißt es scheinbar nicht mehr, wie es noch unter 10.3 hieß (hier gefunden: http://www.linux-club.de/viewtopic.php?f=42&t=94436&start=0#p568500).
 
Hallo,

Was geschieht wenn Du beim Drucken (aus Okular) die Printer Seite auf "US Letter" einstellst? US Letter ist ca. 2cm kürzer als A4.

Gruss,
Roland
 
@RME: Wenn ich die Seite auf "Letter 8.5x11 in" stelle, gibt er mir eine halbe zeile mehr aus, so daß noch 3 Zeilen fehlen. Er dürfte dabei auch einfach den unteren Rand entsprechend höher beginnen. Nun bleibt unten ein Rand von etwa 2,5 cm, der nicht bedruckt wird und bei A4 ist das etwas mehr als 1 cm.
 
Vielleicht könntest Du mal mit "/etc/cups/ppd/<DeinPrinter>.ppd" inspizieren bzw. experimentieren (wie schon Rainer Juhser angeregt hat).

Hier sind z.B. die Grösse der div. Seitenformate definiert.

*DefaultPageSize: A4
*PageSize A4/A4: "%% FoomaticRIPOptionSetting: PageSize=A4"
*FoomaticRIPOptionSetting PageSize=A4: " -dDEVICEWIDTHPOINTS=595 -dDEV&&
ICEHEIGHTPOINTS=842"
*End

Was geschieht wenn Du hier "-dDEVICEWIDTHPOINTS=595 -dDEV&& ICEHEIGHTPOINTS=842" etwas veränderst?

Roland
 
RME schrieb:
Vielleicht könntest Du mal mit "/etc/cups/ppd/<DeinPrinter>.ppd" inspizieren bzw. experimentieren (wie schon Rainer Juhser angeregt hat).

Auf die Idee, daß es an dieser Datei liegen könnte, bin ich nun schon auch gekommen. Ich habe auch schon mal eine Seite entdeckt gehabt, die solche Dateien für unterschiedliche Drucker hatte, fand ich nun aber nicht mehr.

RME schrieb:
Hier sind z.B. die Grösse der div. Seitenformate definiert.

*DefaultPageSize: A4
*PageSize A4/A4: "%% FoomaticRIPOptionSetting: PageSize=A4"
*FoomaticRIPOptionSetting PageSize=A4: " -dDEVICEWIDTHPOINTS=595 -dDEV&&
ICEHEIGHTPOINTS=842"
*End

Was geschieht wenn Du hier "-dDEVICEWIDTHPOINTS=595 -dDEV&& ICEHEIGHTPOINTS=842" etwas veränderst?

Diese Seite ist bei mir etwas anders aufgebaut. Nur für A4 in etwa so:

*DefaultPageSize: A4
*PageSize A4/A4 210x297mm: "<</PageSize[595.44 801.68]/ImagingBBox null>>setpagedevice"
*PageRegion A4/A4 210x297mm: "<</cupsInteger0 26/PageSize[595.44 801.68]/ImagingBBox null>>setpagedevice"
*PaperDimension A4/A4 210x297mm: "595.44 801.68"

Und auch noch
*ImageableArea A4/A4 210x297mm: "18.00 36.00 577.44 832.68"

Ich habe zunächst den y-Wert um 20 reduziert und hatte unten etwas mehr noch mit auf dem Blatt. Als ich den y-Wert dann noch mal um 20 reduzierte, fehlte plötzlich oben etwas. Bei *ImageableArea habe ich bisher nichts geändert. Nun sollte man nur noch wissen, was die Schlüsselworte bedeuten und wie man die Werte verstehen darf.
 
Ändere mal:

---neu---

*DefaultPageSize: A4
*PageSize A4/A4 210x297mm: "<</PageSize[595 842]/ImagingBBox null>>setpagedevice"
*PageRegion A4/A4 210x297mm: "<</cupsInteger0 26/PageSize[595 842]/ImagingBBox null>>setpagedevice"
*PaperDimension A4/A4 210x297mm: "595 842"

---------

Die "ImageableArea" ist Printer-abhängig (kann hier nichts sagen) -- lass dies mal wie es ist.

Roland
 
RME schrieb:
*DefaultPageSize: A4
*PageSize A4/A4 210x297mm: "<</PageSize[595 842]/ImagingBBox null>>setpagedevice"
*PageRegion A4/A4 210x297mm: "<</cupsInteger0 26/PageSize[595 842]/ImagingBBox null>>setpagedevice"
*PaperDimension A4/A4 210x297mm: "595 842"

Das hat auch nichts gebracht.
Auch die Installation von hplip 3.10.9 hat nichts gebracht, nachdem ich gelesen habe, daß mein Drucker zumindest unter Ubuntu mit der Version, die bei openSUSE 11.2 installiert wird anscheinend nicht läuft. Einen Vorteil hat die Version 3.10.9, die bei mir nun installiert ist: Es gibt nur noch eine Warnung und diese kann ich ignorieren, da es sich dabei um "Reportlab - PDF library for Python" handelt, das bei mir nicht installiert ist und nur zum Faxen wichtig ist, das mein Drucker nicht kann.

Ach ja, da fällt mir noch ein: Dieses Problem beschränkt sich nicht nur auf PDF's sondern es schlägt auch zu, wenn ich etwas mit KWrite ausdrucken will.

Btw. wundert es mich sehr, daß die Druckerhersteller Linux oft nicht unterstützen, obwohl sicher nicht wenige als Druckerserver Linux verwenden dürften.
 
Hallo,

nun kann ich zwar in dem ppd-file den druckbaren Bereich ändern und das funktioniert auch, aber es führt nicht dazu, daß unter Okular oder AR (hier "Fit to Printable Area") das zu druckende Dokument entsprechend der Einstellungen in dem ppd-File entsprechend skaliert wird.

Auch mit
Code:
lpr -o portrait -o fit-to-page -o media=A4 test.pdf
in der bash wird "-o fit-to-page" ignoriert, das ja eigentlich dafür sorgen müßte, daß das Dokument entsprechend des druckbaren Bereichs skaliert wird.

Dieses test.pdf wurde mit OpenOffice erstellt und mittels CUPS-PDF erstellt, und wenn ich dieses PDF mit einem Texteditor öffne, finde ich darin eine Zeile mit dem Inhalt
Code:
<</Type/Page/MediaBox [0 0 595 842]
das doch darauf schließt, daß die Seitengröße angegeben ist. Die Seitengröße sei eben wichtig, wenn fit-to-page richtig arbeiten soll.

Das ließt man jedenfalls hier auf Seite 7:
http://www.cups.org/cgi-bin/htmldoc//documentation.php/doc-1.4/options.html
 
Ich habe mir nun die PPD-Datei so geändert, daß ein PDF auch ganz in ihm abgedruckt wird. Das hat nun natürlich den Nachteil, daß ich so nun keinen Brief mehr drucken kann, da das, was ins Sichtfenster soll, dadurch total verschoben ist. Oder ist es unter Linux üblich, daß man für jedes Programm, das druckt, am Besten eine eigene PPD-Datei zu haben und dadurch dann unter Umständen unter aus zig Druckertreibern auszuwählen? Das gibt doch sicher dann Probleme, wenn man den im Netz freigibt und dann auch unterschiedliche Druckerwarteschlangen hat ...
 
Oben