[kde-de] Standard-Druckeinstellungen

[Thomas Michalka]

Hallo,

Kevin Krammer schrieb:
> Hi,
> 
> On Sunday, 2013-08-25, Thomas Michalka wrote:
>> Hallo Marco,
>>
>> Marco Morath schrieb:
>>> Hallo Tom,
> 
>>> Mein Vorschlag wäre es,
>>> diese Konfiguration eine Ebene bzw. zwei Ebenen nach vorne zu verlegen -
>>> also auf die Benutzerebene bzw. die systemweite Ebene.
>> Bzw. auf die Ebene des Desktop Environments (KDE, ...). Das wäre aus der
>> Sicht der Software-Architektur immer noch die Anwendungsebene, und somit
>> OK. Aber nicht auf die Ebene des Systems, denn das kann nicht wissen,
>> welche Ränder _alle_ Benutzer gerne voreingestellt hätten. Und was nützt
>> eine systemweite Voreinstellung, wenn die dann doch durch jeden Anwender
>> gleich nach der Anmeldung automatisch verändert würde?
> 
> Systemweit könnte Sinn machen, wenn es Einstellungen eines bestimmen Druckers 
> betrifft, z.B. weil er bekannte Macken hat oder spezielles Papier benutzt 
> wird.

Wenn ein Drucker Macken hat, wäre nach meinem Verständnis die erste
Anlaufstelle, wo man etwas ändern kann, der Treiber. Ich erinnere mich
da noch an diverse Laserjet-Treiber, die ich alternativ im Einsatz
hatte. Momentan kann ich mir schwer vorstellen, wie man durch Ändern der
Treiberkonfiguration, falls Du das meintest, Fehler kompensieren könnte
-- freilich will ich aber die Möglichkeit nicht ausschließen.

> Vermutlich ist es am Besten wenn man weniger versucht zu beschreiben wo eine 
> Einstellung abgespeichert wird, sondern mehr wie sie zu tragen kommt.
> Man hätte dann gerätespezifische Einstellungen ("systemweit", gilt für alle 

Na, das gibt's ja: der Treiber, dessen Einstellungen aber auch vom
Benutzer im Druckdialog verändert werden können; ist ja auch sinnvoll,
wenn man z.B. Papier sparen möchte, indem man 4 Seiten auf eine
Blattseite druckt.

> Benutzer), benutzerspezifische Einstellungen ("DE-weit", gilt für alle 
> Programme die der Benutzer ausführt),

Die müssten dann möglichst unabhängig von spezifischen Dokumentformaten
sein.

> programmspezifische Einstellungen (gilt 
> für alle Instanzen des Programms) und dokumentenspezifische Einstellungen 
> (gilt für das aktuelle Dokument in der aktuellen Anwendung).
> 
> Die letzten beiden sind vermutlich die am häufigsten veränderten.

Vermute ich auch, wie auch die derzeitige Praxis zeigt.

>>>>> [.....]
>>> [...]
>> [..]
> 
> [.]
> 
>>> werden, die nach meiner Vorstellung die Druckerränder dann beinhalten.
>>> NUR wenn ich diese Standardeinstellungen nicht anwenden möchte (z. B.
>>> weil ich mal ein Bild randlos drucken möchte) gehe ich über den
>>> Druckdialog

>> Was ist für Dich der Druckdialog? Für mich ist das jenes Fenster, dass
>> aufgeht, wenn ich in einer Anwendung [Strg][P] drücke.
> 
> Ich denke mal da sind wir alle der selben Auffassung :)

Dachte ich auch, aber Marco schrieb oben: "NUR wenn, ... gehe ich über
den Druckdialog"
Das klingt so, als würde er z.B. Mails über einen anderen Weg drucken,
wenn er die Standardeinstellungen für den aktuellen Druck beibehalten
möchte.
Aber gehen wir nicht alle meistens über den Druckdialog? Zumindest aus
Anwendungen heraus. (Klar, man kann auch anders PS erzeugen und per
Kommandozeile an die Druckerwarteschlange schicken.)

>>> und verändere die Einstellungen dann einmalig für diesen einenen Druck.
>> Das ist von der Reihenfolge her falsch gedacht. Wenn Du eine Mail
>> ausdrucken willst, dann musst Du halt in der Anwendung die Ränder
>> einstellen, nicht erst im Druckdialog, denn da gehört das nicht hin,
>> weil dieser Dialog für alle (eigtl. nur die meisten) Anwendungen gleich
>> ist.
> 
> Jein :)
> 
> Der Druckdialog ist der Teil der Benutzerschnittstelle eines Programms, der 
> speziell für dem Druckvorhang geschaffen wurde. Er ist damit der primäre 
> Zugangspunkt zu den Druckeigenschaften des Programms.

Wenn ich aus einem KDE-Programm heraus etwas drucke, hat dann der Dialog
je nach Anwendung _gravierend_ unterschiedliche Optionen? Ist mir noch
nicht aufgefallen. Nach meiner Wahrnehmung ist der KDE-Druckdialog die
Benutzerschnittstelle zum _Drucksystem_, und ist _nicht spezifisch_ für
das _Programm_ (außer dieses implementiert einen eigenen Druckdialog,
aber selbst der ist oft nur eine Schnittstelle zum Drucksystem, z.B. bei
Thunderbird); allenfalls kann es je nach Dateityp die eine oder andere
Option zusätzlich geben.
Ich glaube sogar, dass der Druckdialog, genauso wie der Öffnen- und der
Speichern-Dialog, in der Architektur der KDE-Software nicht Teil der
Benutzerschnittstelle des einen oder anderen Programms ist, sondern als
externe Komponente oder eigenes Programm von KDE-Programmen aufgerufen
wird. Vielleicht ist aber die Frage nach der Einbindung des Druckdialogs
in die KDE-Software-Architektur eher akademischer Natur ;-)

> Es ist natürlich richtig, dass der Dialog zwischen den Applikationen möglichst 
> ähnlich sein soll, im Idealfall gleich. Aber da die Möglichkeiten und auch 
> Anforderungen zwischen Applikationen variieren, kann jede Applikation den 
> Dialog erweitern.
> Das wird meist über anwendungsspezifische Tabs gemacht.

Ok, diese Tabs, das sind die zus. Optionen, die ich in meinem vorigen
Absatz erwähnt habe -- insofern sind wir uns einig. Ich denke, die
Anwendung übergibt beim Aufruf des Druckdialogs diese Tabs und ihre
Inhalte, die ich mir mal für kwrite, konqueror und kpdf bzw. okular
angesehen habe. In allen Fällen sind es _zusätzliche_ Optionen (am
meisten bei kwrite: Text-Einst., Kopf- & Fußz., Layout), die in fast
allen Fällen nur den zusätzlichen Druck von weiteren Informationen
ermöglichen. Ob durch den Tab "Layout" Einfluss genommen wird auf z.B.
Zeilenlänge (Anz. d. Zeichen) und Randbreiten, kann ich nicht sagen,
aber möglich wäre es. Klar ist jedenfalls, dass auf die Ausgabe eines
Texteditors noch am meisten Einfluss auf das Layout im Druckdialog
genommen werden kann, da der Editor außer der Schriftgröße und der
Anzahl der Zeichen pro Zeile selber noch keine weiteren Layout-Parameter
festlegt -- ist ja auch nicht seine primäre Aufgabe.

> Idealerweise hat eine Anwendung dann vorgesehen, dass solche Einstellungen 
> auch gespeichert, wieder abgerufen oder auch zur Standardeinstellunge gemacht 
> werden können.

In meinem KDE3-Druckdialog kann ich sowohl treiberspezifische als auch
sonstige Druckparameter, wie Seitenzahl pro Blatt u.ä. abspeichern. Das
sieht aber nicht die Anwendung vor, weil keine dieser Einstellungen mit
einer Anwendung zu tun hat.
In einem KDE4-Druckdialog gibt es diesen Speichern-Button nicht mehr.
Vielleicht ist er nicht mehr nötig wg. autom. Speicherung der letzten
Treibereinstellung, oder die Möglichkeit hat sich als Nachteil erwiesen.
Müsste ich erst ausprobieren anhand zweier Ausdrucke.

Die Abspeicherung als Standardeinstellung wäre demnach vor allem für
traditionell layout-schwache Programme, wie Editoren und Mail User
Agents sinnvoll, aber nur dann, wenn das Programm keinen eigenen
Druckdialog mitbringt und dadurch den KDE-Druckdialog umgeht.

Vielleicht wäre es besser, wenn man dies nicht oder nicht nur in der
Anwendung oder im Druckdialog einstellen kann, sondern in der
KDE-Systemeinstellung, und zwar je nach aufrufendem, d.h. ausdruckenden
Programm unterschiedliche Layout-Optionen (Ränder, Skalierung, ...).
Würde man z.B. für das Ausdrucken von Mails die Ränder so einstellen,
dass der Text mit der vorgegebenen Zeilenlänge und Zeichengröße nicht
zwischen diese Ränder passt, müsste man gewarnt werden, dass entweder
Text abgeschnitten oder der Zeilenumbruch verändert wird.

> Möglicherweise könnte man diese Einstellungen zusätzlich in den 
> Programmeinstellung verwaltbar machen, aber die sind oft ohnehin schon 
> ziemlich "voll".

Ein Beispiel, wo es das gibt, ist OpenOffice-Calc: Format -> Seite ...
-> Tab: "Tabelle": Skalierung (u.a. Optionen).

> Wäre vielleicht dann interessant, wenn die dokumentspezischen 
> Druckeinstellungen ebenfalls außerhalb des Druckdialogs verfügbar wären.

Genau, wie ich oben erwähnte, in den KDE-Systemeinstellungen.

>> Dort würdest Du dann die Ränder für künftige Ausdrucke ändern, was
>> Du bis zum nächsten Druck schon vergessen hättest (außer es hieße
>> wirklich: "Ränder nur für diesen Druck einmalig ändern", aber das hielte
>> ich für bedienungsunfreundlich -- meine Meinung).
> 
> Die meisten Druckeinstellungen sind eigentlich "nür für jetzt", z.B. 
> Seitenauswahl, mehrere Seiten auf einem Blatt, usw.
> 
> Was man zusätzlich benötigen würde wäre die Möglichkeit solche Konfigurationen 
> abzuspeichern und wieder aufzurufen.

Gibt es, wie gesagt, in KDE3 noch für einige Parameter, hauptsächlich
aber nur für solche, wo der Druckertreiber selber die entsprechenden
Fähigkeiten hat.

> Ich denke da an etwa sowas wie Benennungseinstellugen von K3B beim CD rippen, 
> falls das jemand benutzt :)

Yeah, ist wirklich cool!

> Dort hat man zu Beginn immer die Standardeinstellung, man kann aber sehr 
> leicht "zu letzt benutze Einstellung" oder "gespeicherte Einstellung" wählen.
> Eventuell kann man sogar eine neue Einstellung als Standard festlegen.
> 
>> Bei Anwendungen, die Datenformate, wie Mails oder HTML-Seiten anzeigen,
>> gibt es zunächst keine Ränder, da dies in der Anwendung unnötig ist.
>> Erst beim Drucken kommt ja die Verbindung mit dem Papier im gewählten
>> Format (z.B. DIN A4) zustande und Randeinstellung wird somit nötig.
>> Ich habe es gerade ausprobiert: wenn ich eine Mail aus Thunderbird
>> heraus drucken will, kann ich die Papierränder einstellen. Dann könnte
>> TB den Zeilenumbruch neu machen (ob er das tatsächlich macht, habe ich
>> nicht ausprobiert, wäre aber m.E. eher selten erwünscht). Mein alter
>> Firefox hat diese Option nicht direkt. Aber man kann die Seite auf unter
>> 100 % skalieren und so auch Ränder schaffen. Das ist wohl so umgesetzt,
>> weil Firefox sonst eigens für den Druck die Seite neu rendern müsste,
>> wobei er sich nicht nur nach dem HTML-Code richten könnte, weil HTML das
>> selber nicht hergibt. Das würde die Sache verkomplizieren.
> 
> Bei HTML, oder besser gesagt bei Webseiten, kann durchaus vom Auslieferer 
> mittels Druck-Stylesheets das Layouten erleichtert werden. Z.B. fixe 
> Pixelangaben oder ähnliches im Webmodus, aber relative Angaben im Druckmodus.

Damit kenne ich mich kaum aus, aber das würde Marco nicht helfen, wenn
er unbedingt eigene Rand-Vorstellungen umsetzen möchte. Wenn aber das
HTML-Dokument nicht völlig 'ver-layoutet' werden soll, bräuchte man
schon so etwas wie eine Skalierung, ggf. getrennt für Höhe und Breite,
wofür man evtl. leichte Verzerrungen des Seitenverhältnisses in Kauf
nehmen müsste.

>> Ich sehe auf der KDE-Ebene daher nur die Möglichkeit, die Ausdruckgröße
>> zu skalieren, um Ränder zu schaffen, weil das Programm, aus dem man den
>> Druck veranlasst, die Hoheit über die Formatierung (Zeilenumbruch u.ä.)
>> besitzt. Ansonsten müsste eine gespeicherte HTML-Seite oder Mail unter
>> einer bestimmten Randbreitenvorgabe zunächst neu formatiert werden.
> 
> Skalieren geht nur in beschränkten Größenordnungen, sowohl Mails als auch HTML 
> Dokument können sehr schnell länger werden als eine Druckerseite (unter der 
> Annahme eines Seitendruckers, kein Problem für einen Endlosdrucker :) )

Ja, wenn man nur die Breite skaliert, muss ggf. der Seitenumbruch in
Kauf genommen werden. Bei Mails ist aber meine, zugegebenermaßen seltene
Erfahrung, dass sie oft viel zu schmal gedruckt werden, was massig Platz
auf der A4-Seite verschwendet. Hier müsste man die Zeichengröße auf gut
lesbare 10 bis 12 Punkte stellen, dabei noch ca. 70 Zeichen in die Zeile
bei den gegebenen Rändern bringen. Viele Mails könnten dann sogar auf
eine Seite passen.

> Für Textmails sollte das Neuformatieren keine so große Sache sein, das 
> Mailprogramm muss dazu ohnehin z.B. für Fenstergrößenänderungen, in der Lage 
> sein.

Wieso? Bei einer Größenänderung in der Höhe werden halt mehr oder
weniger Zeilen angezeigt, hier muss nichts neu formatiert werden.
Bei einer Änderung der Fensterbreite wird der Zeilenumbruch geändert,
aber nur, wenn bei vorgegebener Zeichengröße weniger als die maximale
Anzahl der Zeichen pro Zeile angezeigt werden können. Aber darauf könnte
ich auch verzichten, weil ich immer ca. 70 Zeichen pro Zeile lesen will.
Mit Bandwurmzeilen tue ich mich schwer, besonders mit solchen Mails, die
mit "quoted-printable" keine echten Zeilenumbruchszeichen (LF, LF-CR)
enthalten. Aber das ist ein anderes Thema.

> Bei HTML Dokumenten kann es schwieriger sein, weil mittlerweile viele 
> Ersteller fixe Größen vorgeben. Da müsste man dem Benutzer die Möglichkeit 
> bieten, solche Angaben für nichtig erklären zu können.
> 
>> Woher soll aber der KDE-Druckdialog etwas über die Formatierung wissen,
>> wenn eine fertig formatierte, gespeicherte Datei direkt gedruckt werden
>> soll?
> 
> Am Besten wir benutzen dafür einen anderen Begriff um diese Hilfprogramm nicht 
> mit dem Anwendungsdruckdialog (STRG+P) zu verwechseln.

Das gedachte Hilfsprogramm müsste sozusagen bei Rechtsklick auf die
Datei (Aktionen ... -> Drucken) unsichtbar die für den Dateityp
vorgesehenen Optionen in den Druckdialog als Tabs einfügen und die vom
Benutzer gewählten Einstellungen speicherbar übernehmen können.

> Im diesem Falle, also das Drucken unter Umgehung des erstellenden Programms, 
> ist man natürlich eingeschränkter. Eventuell könnte man da noch was mit 
> Plugins machen, aber es wird im Endeffekt auf die Fähigkeiten des Druckers 
> ankommen.

Nach meinen bescheidenen Kenntnissen von MacOS X wird dort alles, was
man irgendwie auf dem Bildschirm anzeigen kann, intern für die Anzeige
on-the-fly in PDF umgewandelt. Man sieht also schon am Bildschirm exakt
das Format der Druckausgabe (falls der Druckertreiber und der Drucker
keine Fehler haben). So könnte ich mir für KDE auch ein Vorschaufenster
vorstellen, allerdings mit der Möglichkeit, das Layout anzupassen.

>> Je näher man sich das überlegt, desto mehr scheint eine für jede
>> Anwendung spezifische Randeinstellung wohlüberlegt zu sein und einiges
>> gegen eine KDE-weite Randbreite zu sprechen, denn es gibt einfach Daten,
>> wo nur die Anwendung die mit der Randbreite untrennbar verbundene
>> Formatierung vornehmen kann. 
> 
> Unter der Annahme, dass KDE-weit hier benutzerweit bedeutet, könnte durchaus 
> eine Anwendung darauf reagieren. Zwischen einer interaktiven 
> Einstellungsänderung und einer geladenen Einstellung sollte im Idealfall kein 
> Unterschied sein.

Gut, das wäre aber nur so, solange der Benutzer im speziellen Programm
bzw. im Dokument keine Ränder eingestellt hat. Hat er das getan, dann
sollten diese Einstellungen dominieren.

> Allerdings können sich immer Fehler einschleichen, bzw. solche Automatismen 
> für Anwendungentwickler neu oder unerwartet sein.

Deshalb muss ja die Einstellung in der Anwendung dominieren. Dann müsste
es aber auch den Zustand "Nichts eingestellt" geben und nicht einfach
eine Voreinstellung (Default).

>> Es ist einfacher, wenn Anwendungen über
>> Papierformate o.a. Randbedingungen Bescheid wissen, als dass z.B. KDE
>> alle möglichen Dokumente umformatieren können sollte. Außerdem käme
>> dabei oft etwas Unlesbares heraus.
> 
> Das sind ohnehin zwei verschieden Baustellen.

... die sich aber auf breiter Front berühren.

> Ein "universelles" Druckwerkzeug 
> wird nie die selben Möglichkeiten bieten wie der direkte Druck aus der 
> Quellanwendung.

Genau das wollte ich ausdrücken, denn die Quellanwendung 'kennt' das
eigene Dokumentformat am besten.

Das universelle Druckwerkzeug könnte aber aus der KDE-Systemeinstellung
wissen, wie sich z.B. eine Änderung einer Randeinstellung auf einen
spezifischen Dokumenttyp auswirken kann.
Man könnte dazu die Layout-Module der Programme für verschiedene
Dokumenttypen aufgrund der objektorientierten Entwicklung im
universellen Druckwerkzeug vollständig wiederverwenden. Allerdings wäre
dann der Nutzen der Formatierung im Programm fraglich.
Ich glaube, man muss an dieser Stelle der Überlegungen ins Detail gehen
und nochmal den Nutzen gegen den Aufwand und besonders gegen mögliche
Schwierigkeiten abwären.

Ein vorläufiges Fazit wäre für mich:
Eingeschränkte (Um-)Formatierung unmittelbar vor dem Drucken, z.B. in
der Vorschau, wäre wohl nützlich für Programme, die i.d.R. nichts
drucken, bzw. für die eine Ansicht, bezogen auf ein bestimmtes
Papierformat, von eher untergeordneter Bedeutung ist. Solche Programme
wecken in der Bildschirmanzeige nicht unbedingt eine Erwartung an ein
bestimmtes Aussehen auf dem Papier. Deshalb wären hier im Falle des
Ausdrucks einfache Möglichkeiten der Formatierung sinnvoll. Für die
entsprechenden Dokumenttypen wäre dann die benutzereigene bzw. KDE-weite
Speicherung nur noch Nebensache und sicher nicht schwer umzusetzen.


Ciao, Tom