Druckvorschau fuer alle Druckausgaben
Hallo Liste ich bin auf der Suche nach einer Lösung um für alle Druckausgaben zuerst vor den Drucken eine Vorschau zu ermöglich. Es gibt ja einige Anwendungen zB. OpenOffice die so eine Funktion anbieten. Ich möchte aber alle Druckausgaben von anderen Anwendungen zuerst in eine Vorschau umleiten. Optimal wäre es dann, wenn der Benutzer nach erfolgter Vorschau den weiteren Verlauf wählen könnte: 0) Abbrechen 1) Drucken (Cups) 2) Faxen 3) PDF erstellen. 4)... Der Druckjob wird aus der Applikation als Kommandozeile gestartet zB: Pipe nach lpr -P drucker pipe an Vorschau pipe an weitere Ausgabe Hat jemand eine Idee, Tipps oder Sowas schon im Einsatz? Danke und Grüsse Bernhard
Hallo, On Oct 27 09:06 Bernhard Bühler wrote (shortened):
Der Druckjob wird aus der Applikation als Kommandozeile gestartet zB: Pipe nach lpr -P drucker pipe an Vorschau pipe an weitere Ausgabe
Problematisch! Wie soll "pipe an Vorschau" funktionieren können? Hintergrund: Man mache sich klar, wie ein Drucksystem (CUPS und auch LPRng/lpdfilter) arbeitet, zu CUPS siehe http://portal.suse.com/sdb/de/2004/05/jsmeix_print-cups-in-a-nutshell.html und http://portal.suse.com/sdb/de/2003/05/jsmeix_print-cups-filters.html lpr oder lp erzeugen einen Druckauftrag und übergeben den an das Drucksystem. Auf stdout kommt dabei nicht der Druckauftrag raus, sondern die (Fehler)-Meldungen von lpr oder lp. Daher kann "pipe an Vorschau" nicht funktionieren. Der Druckauftrag im Drucksystem wird vom Benutzer "lp" verarbeitet. Dieser Benutzer hat normalerweise keinen Zugriff auf die graphische Oberfläche des Benutzers, der den Druckauftrag gestartet hat. Daher kann "Vorschau" nicht ohne weiteres funktionieren (*). Der einzige allgemein funktionierende Ansatzpunkt, der mir einfällt, ist die CUPS Filterkette vor "pstops" um einen zusätzlichen Filter zu erweitern, der dann als Eingabe PostScript bekommt und das dann "irgendwie" - siehe (*) - bei dem Benutzer, der den Druckauftrag gestartet hat, darstellt und je nachdem wie das Darstellungsprogramm (z.B. gv) beendet wurde, entweder das PostScript auf stdout an den Rest der CUPS Filterkette ausgibt, oder abbricht. Bzw. der wenn es nicht möglich ist, die Vorschau bei dem Benutzer, der den Druckauftrag gestartet hat, darzustellen (z.B. weil kein Zugriff auf dessen X-Display möglich ist), das PostScript auf stdout an den Rest der CUPS Filterkette ausgibt (Fallback auf die normale Verarbeitung ohne Vorschau, wenn Vorschau nicht möglich). Gruss, Johannes Meixner -- SUSE LINUX Products GmbH, Maxfeldstrasse 5 Mail: jsmeix@suse.de 90409 Nuernberg, Germany WWW: http://www.suse.de/
Am Donnerstag 27 Oktober 2005 09:58 schrieb Johannes Meixner:
Hallo,
On Oct 27 09:06 Bernhard Bühler wrote (shortened):
Der Druckjob wird aus der Applikation als Kommandozeile gestartet zB: Pipe nach lpr -P drucker pipe an Vorschau pipe an weitere Ausgabe
Problematisch! Wie soll "pipe an Vorschau" funktionieren können?
Hintergrund: Man mache sich klar, wie ein Drucksystem (CUPS und auch LPRng/lpdfilter) arbeitet, zu CUPS siehe http://portal.suse.com/sdb/de/2004/05/jsmeix_print-cups-in-a-nutshell.html und http://portal.suse.com/sdb/de/2003/05/jsmeix_print-cups-filters.html
lpr oder lp erzeugen einen Druckauftrag und übergeben den an das Drucksystem. Auf stdout kommt dabei nicht der Druckauftrag raus, sondern die (Fehler)-Meldungen von lpr oder lp. Daher kann "pipe an Vorschau" nicht funktionieren.
Der Druckauftrag im Drucksystem wird vom Benutzer "lp" verarbeitet. Dieser Benutzer hat normalerweise keinen Zugriff auf die graphische Oberfläche des Benutzers, der den Druckauftrag gestartet hat. Daher kann "Vorschau" nicht ohne weiteres funktionieren (*).
Der einzige allgemein funktionierende Ansatzpunkt, der mir einfällt, ist die CUPS Filterkette vor "pstops" um einen zusätzlichen Filter zu erweitern, der dann als Eingabe PostScript bekommt und das dann "irgendwie" - siehe (*) - bei dem Benutzer,
das "irgendwie" könnte so gehen: - der Filter schreibt die Ausgabe in eine Datei in einem Verzeichnis - der Benutzer hat einen daemon laufen, welcher a) das Verzeichnis pollt, oder b) vom Filter per Signal "aufgeweckt" wird. Findet der Daemon etwas zum anzeigen macht er das. Da der Daemon erst beim graphischen Login des Benutzers gestartet wird, kann er auch auf die graph. Overfläche zugreifen.
der den Druckauftrag gestartet hat, darstellt und je nachdem wie das Darstellungsprogramm (z.B. gv) beendet wurde, entweder das PostScript auf stdout an den Rest der CUPS Filterkette ausgibt, oder abbricht. Bzw. der wenn es nicht möglich ist, die Vorschau bei dem Benutzer, der den Druckauftrag gestartet hat, darzustellen (z.B. weil kein Zugriff auf dessen X-Display möglich ist), das PostScript auf stdout an den Rest der CUPS Filterkette ausgibt (Fallback auf die normale Verarbeitung ohne Vorschau, wenn Vorschau nicht möglich).
Gruss, Johannes Meixner -- SUSE LINUX Products GmbH, Maxfeldstrasse 5 Mail: jsmeix@suse.de 90409 Nuernberg, Germany WWW: http://www.suse.de/
-- Dr.rer.nat. Juergen Vollmer, Viktoriastrasse 15, D-76133 Karlsruhe Tel: +49(721) 92 04 87 1 Fax: +49(721) 92 04 87 2 Juergen.Vollmer@informatik-vollmer.de www.informatik-vollmer.de Internet-Telefonie: www.skype.com Benutzer: juergen.vollmer
Moin, On Thu, 27 Oct 2005 09:58:52 +0200 (CEST) Johannes Meixner <jsmeix@suse.de> wrote:
Problematisch! Wie soll "pipe an Vorschau" funktionieren können?
Na, halt statt lpr ein Vorschauprogramm starten.
Hintergrund: Man mache sich klar, wie ein Drucksystem (CUPS und auch LPRng/lpdfilter) arbeitet, [...]
Uninteressant, da das Drucksystem erst nach der Vorschau ins Spiel kommt.
lpr oder lp erzeugen einen Druckauftrag und übergeben den an das Drucksystem. Auf stdout kommt dabei nicht der Druckauftrag raus, sondern die (Fehler)-Meldungen von lpr oder lp. Daher kann "pipe an Vorschau" nicht funktionieren.
Alle Programme, die drucken, tun das für gewöhnlich, indem sie die (Postscript-)Daten an ein Programm pipen.
Der Druckauftrag im Drucksystem wird vom Benutzer "lp" verarbeitet. Dieser Benutzer hat normalerweise keinen Zugriff auf die graphische Oberfläche des Benutzers, der den Druckauftrag gestartet hat. Daher kann "Vorschau" nicht ohne weiteres funktionieren (*).
Wie gesagt, lprng/CUPS/lpr kommen erst nach der Vorschau ins Spiel. Funktionsweise siehe z.B. XPP, http://cups.sf.net/xpp/
Der einzige allgemein funktionierende Ansatzpunkt, der mir einfällt, ist die CUPS Filterkette vor "pstops" um einen zusätzlichen Filter zu erweitern, der dann als Eingabe PostScript bekommt und das dann "irgendwie" - siehe (*) - bei dem Benutzer, der den Druckauftrag gestartet hat, darstellt und je nachdem wie das Darstellungsprogramm (z.B. gv) beendet wurde, entweder das PostScript auf stdout an den Rest der CUPS Filterkette ausgibt, oder abbricht.
Wie erwähnt, würde ich CUPS nicht antasten. Was benötigt wird, ist stattdessen ein kleines bash-Programm: ---snip--- #!/bin/sh PSCACHE=$(mktemp) PDFFILE=/var/pdfarchiv/$(date +%d-%m-%y_%H-%I)_$(id -un).pdf cat > $PSCACHE gv $PSCACHE Xdialog --title "Drucken?" --yesno "Ist alles OK? Drucken?" 9 30 && lpr "$@" $PSCACHE Xdialog --title "PDF erstellen?" --yesno "PDF ins Archiv legen?" 9 30 && ps2pdf $PSCACHE $PDFFILE rm $PSCACHE ----snip---- Das einfach statt lpr benutzen und fertig ist. Es benutzt - Ghostscript - gv - xdialog Gruß, -hwh
Hallo, On Oct 27 11:06 Hans-Werner Hilse wrote (shortened):
Alle Programme, die drucken, tun das für gewöhnlich, indem sie die (Postscript-)Daten an ein Programm pipen.
Unter der Voraussetzung, dass die Vorschau nur für die Programme funktioniert, die PostScript erzeugen, ist es natürlich relativ einfach - siehe aber (**) unten. Dann gibt's aber keine Vorschau für Plain Text wie er beim Druck aussehen würde (nachdem CUPS texttops lief) oder für rohe Grafikdaten. Dabei fällt mir ein, dass die CUPS Filterkette vor "pstops" um einen zusätzlichen Filter zu erweitern nicht immer eine korrekte Vorschau liefert (also das, was dann auf dem Drucker rauskommt), denn "pstops" macht ggf. auch PostScript Umformatierung (**) z.B. N-Up, siehe "CUPS Software Users Manual" "Document Options". Daher wäre es besser, die CUPS Filterkette direkt nach "pstops" um einen zusätzlichen Filter zu erweitern, aber dann hat man evtl. die von "pstops" eingesetzten druckerspezifischen "Features" für das Darstellungsprogramm rauszufiltern (aber nicht für die weitere Verarbeitung für den Rest der CUPS Filterkette) falls das Darstellungsprogramm damit nicht klarkommt. Natürlich liefert auch das nicht immer eine korrekte Vorschau, z.B. wenn das PostScript "farbig" ist, aber der Drucker auf Schwarzweissmodus umgeschaltet wird, oder wenn das PostScript größer ist, als auf die Seite gedruckt werden kann zeigt die Vorschau normalerweise nicht an, dass beim Druck etwas abgeschnitten wird u.s.w. Gruss, Johannes Meixner -- SUSE LINUX Products GmbH, Maxfeldstrasse 5 Mail: jsmeix@suse.de 90409 Nuernberg, Germany WWW: http://www.suse.de/
Moin, On Thu, 27 Oct 2005 11:28:23 +0200 (CEST) Johannes Meixner <jsmeix@suse.de> wrote:
On Oct 27 11:06 Hans-Werner Hilse wrote (shortened):
Alle Programme, die drucken, tun das für gewöhnlich, indem sie die (Postscript-)Daten an ein Programm pipen.
Unter der Voraussetzung, dass die Vorschau nur für die Programme funktioniert, die PostScript erzeugen, ist es natürlich relativ einfach - siehe aber (**) unten.
Hm, stimmt, habe ich total ignoriert. Schade, dann also doch nur mit den von dir genannten Schwierigkeiten... Gruß, -hwh
Hallo erstmals herzlichen Dank an Alle für die Beiträge die zu meiner Frage in so kurzer Zeit eingegangen sind. Deine Antwort hat meinen Wunsch genau getroffen. Ich kann die Druckausgabe eines beliebigen Programms zuerst in eine Datei schreiben, diese analysieren (Ascii, PS,) und nach allfälliger Konvertierung nach PS ansehen und danach weiter zum Drucker, Fax oder Mail senden. Bin begeistert. Grüsse Bernhard . Am Donnerstag, 27. Oktober 2005 11.06 schrieb Hans-Werner Hilse:
Moin,
On Thu, 27 Oct 2005 09:58:52 +0200 (CEST)
Johannes Meixner <jsmeix@suse.de> wrote:
Problematisch! Wie soll "pipe an Vorschau" funktionieren können?
Na, halt statt lpr ein Vorschauprogramm starten.
Hintergrund: Man mache sich klar, wie ein Drucksystem (CUPS und auch LPRng/lpdfilter) arbeitet, [...]
Uninteressant, da das Drucksystem erst nach der Vorschau ins Spiel kommt.
lpr oder lp erzeugen einen Druckauftrag und übergeben den an das Drucksystem. Auf stdout kommt dabei nicht der Druckauftrag raus, sondern die (Fehler)-Meldungen von lpr oder lp. Daher kann "pipe an Vorschau" nicht funktionieren.
Alle Programme, die drucken, tun das für gewöhnlich, indem sie die (Postscript-)Daten an ein Programm pipen.
Der Druckauftrag im Drucksystem wird vom Benutzer "lp" verarbeitet. Dieser Benutzer hat normalerweise keinen Zugriff auf die graphische Oberfläche des Benutzers, der den Druckauftrag gestartet hat. Daher kann "Vorschau" nicht ohne weiteres funktionieren (*).
Wie gesagt, lprng/CUPS/lpr kommen erst nach der Vorschau ins Spiel. Funktionsweise siehe z.B. XPP, http://cups.sf.net/xpp/
Der einzige allgemein funktionierende Ansatzpunkt, der mir einfällt, ist die CUPS Filterkette vor "pstops" um einen zusätzlichen Filter zu erweitern, der dann als Eingabe PostScript bekommt und das dann "irgendwie" - siehe (*) - bei dem Benutzer, der den Druckauftrag gestartet hat, darstellt und je nachdem wie das Darstellungsprogramm (z.B. gv) beendet wurde, entweder das PostScript auf stdout an den Rest der CUPS Filterkette ausgibt, oder abbricht.
Wie erwähnt, würde ich CUPS nicht antasten. Was benötigt wird, ist stattdessen ein kleines bash-Programm: ---snip--- #!/bin/sh PSCACHE=$(mktemp) PDFFILE=/var/pdfarchiv/$(date +%d-%m-%y_%H-%I)_$(id -un).pdf cat > $PSCACHE gv $PSCACHE Xdialog --title "Drucken?" --yesno "Ist alles OK? Drucken?" 9 30 && lpr "$@" $PSCACHE Xdialog --title "PDF erstellen?" --yesno "PDF ins Archiv legen?" 9 30 && ps2pdf $PSCACHE $PDFFILE rm $PSCACHE ----snip----
Das einfach statt lpr benutzen und fertig ist. Es benutzt - Ghostscript - gv - xdialog
Gruß,
-hwh
participants (4)
-
Bernhard Bühler -
Dr. Jürgen Vollmer -
Hans-Werner Hilse -
Johannes Meixner