Druckausgabe über Printer / Problem mit einigen Schriftarten

[stefanniehaus]

Vielen Dank schon mal für deine Ausführungen.

Im Anwendungsfall geht es um die dynamische Erzeugung von Rechnungen. Dynamisch in dem Sinne, alsdass es eine frei definierbare Layout-Datei gibt, die dann verarbeitet wird.
Entsprechend sind mm-Angaben gegeben.
Die komplette Druckroutine ist schon etwas älter und kann leider nicht mal eben so "auf links" gezogen werden.
Das Problem trat bisher nur nicht auf, da i.d.R. Arial oder Times New Roman verwendet wurden.

Meinst du mit Endgerät den jeweiligen PC oder den Drucker?
Vor dem Druck wird sicher gestellt, dass die verwendete Schriftart auf dem PC installiert ist.
Oder muss der Drucker diese Schriftart explizit unterstützen? Und wenn er dies nicht tut, kann man solche Ergebnisse nicht direkt beeinflussen?


edit: Im PDF-Dokument ist die Schrift kann ich die Schrift kopieren und woanders einfügen. Kann es dann noch ein Image sein? Mit ist klar, dass ein PDF-Drucker nicht Maß aller Dinge sein kann. Ich hätte das Dokument auch ausdrucken und zur Veranschaulichung wieder einscannen können. Das Problem wäre dasselbe.
edit2: Bim Druck beispielsweise über Word gibt es das Problem mit der Schriftart bei selbem Drucker nicht.

[MeierZwoo]

Drucklayouts sind normal immer in mm .. weil das Endgerät ja nicht bekannt sein muß, und dessen Auflösung (dpi) auch nicht - wohl aber das Ausgabe-Format bekannt ist (z.B. DIN A4) - und das hat als Maß eben mm.

Nur besteht keinerlei Grund, nur weil das Endformat mm hat, auch die logische Einheit auf mm zu setzen. Die logische Einheit ist normal immer Pixel (ausgenommen bei Plottern etc.). Aber sowohl Bildschirme wie auch Drucker sind pixelorientiert - die mm des Layouts werden dann entspr. der dpi Werte in x-Richtung wie in y-Richtung (können verschieden sein) umgerechnet.

Mit ENDgerät ist immer das Gerät gemeint, auf dem endgültig die Ausgabe erfolgt: Ein Drucker, der Bildschirm, eine eMail, ein FAX ... der ERZEUGER kann nicht ENDgerät sein.

Ein Drucker "unterstützt" keine Schriften - er hat diese installiert, sie werden vorm Druck untergeladen oder er hat diese Schrift nicht. Aber Canvas weiß, welche Schriften der Drucker (aktuell) installiert hat und unterscheidet dann, ob der Drucker entspr. Commands bekommt, diese Schrift zu benutzen oder ob Canvas die Schrift selber "malt" und das Ergebnis per Image zum Drucker schickt.

Eine benutzte Schrift sollte schon auf dem PC, auf dem Canvas läuft, installiert sein - alternativ wird eben eine Ersatzschrift verwendet - bei Windows mit Vorliebe Courier <schauder> obwohl die API anderes behauptet.

Es gibt übrigens keinen Grund, für Rechnungen Exoten-Schriften zu benutzen, bei denen man dann nicht sicher sein kann, ob sie zur Laufzeit vorhanden sind. Vorallem kann man keinem Benutzer zumuten, die passende Schrift ohne exakte Angabe selber nachzuinstallieren - da die Schriftnamen im Font-Verzeichnis nicht mit dem internen Schriftnamen übereinstimmen müssen.

[stefanniehaus]

Wie gesagt ist sicher gestellt, dass die benötigte Schrift vorhanden ist.
Die Wahl einer anderen Schriftart ist im aktuellen Fall auch keine Option.

Das Problem kann man soweit also nicht lösen? Umrechnung der mm-Angaben in px hilft ja offensichtlich auch nicht immer.

[hathor]

Das Druckergebnis hängt auch vom BS und vom Drucker ab (Stichwort: GDI, OPENGL).

Der Fehler liegt eindeutig bei der Schrift Gill Sans MT - mit Tahoma sieht es gut aus.

[stefanniehaus]

Zitat von hathor:

Ich nehme mal an, dass Printer : TPrinter; eine GLOBALE Varable ist, denn sie ist in der Procedure nicht deklariert.
Besser ist es, sie LOKAL zu deklarieren, um auszuschliessen, dass andere evtl. langsame, parallele Threads die Variable ändern.
Das Druckergebnis hängt auch vom BS und vom Drucker ab (Stichwort: GDI, OPENGL)

Ein TPrinter-Objekt wird automatisch erzeugt, wenn es nil ist.
Ich habe aber auch schon lokal ein TPrinter-Objekt erzeugt, was keine Veränderung mit sich gebracht hat.

[MeierZwoo]

Zitat von stefanniehaus:

Wie gesagt ist sicher gestellt, dass die benötigte Schrift vorhanden ist.

Das wage ich zu bezweifeln, oder administrierst Du das Programm mit täglicher Wartung dein Leben lang?

Zitat von stefanniehaus:

Das Problem kann man soweit also nicht lösen? Umrechnung der mm-Angaben in px hilft ja offensichtlich auch nicht immer.

Das Problem ist doch gelöst, wenn Du dieses unselige MM_LOMETRIC wegläßt, was niemand braucht. Die logische Einheit mm von MM_LOMETRIC hat nichts, aber auch garnichts mit der Umrechnung mm/Pixel bzw. dem Maßsystem des Endformates zu tun! Zumal das Endgerät zwar mm im Ausgabeformat hat, aber im Gegensatz zu MM_LOMETRIC, das gleiche Einheiten in x und y setzt, das Endgerät in x und y verschiedene dpi haben kann. Aber diese Werte kennt canvas, weil sie per Treiber ermittelt werden (DeviceCaps des Printers).

Es wird immer von mm auf Pixel umgerechnet, weil jeder Drucker mm-Formate als Ausgabemedium hat und Canvas immer Pixelorientiert ist - alle Canvas-Methoden erwarten Pixel als Werte.

[stefanniehaus]

Zitat von MeierZwoo:

Das wage ich zu bezweifeln, oder administrierst Du das Programm mit täglicher Wartung dein Leben lang?

Es wird vorher geprüft ob die Schriftart auf dem System vorhanden ist. Ist sie das nicht, wird nicht gedruckt.

Zitat von MeierZwoo:

Das Problem ist doch gelöst, wenn Du dieses unselige MM_LOMETRIC wegläßt, was niemand braucht. Die logische Einheit mm von MM_LOMETRIC hat nichts, aber auch garnichts mit der Umrechnung mm/Pixel bzw. dem Maßsystem des Endformates zu tun! Zumal das Endgerät zwar mm im Ausgabeformat hat, aber im Gegensatz zu MM_LOMETRIC, das gleiche Einheiten in x und y setzt, das Endgerät in x und y verschiedene dpi haben kann. Aber diese Werte kennt canvas, weil sie per Treiber ermittelt werden (DeviceCaps des Printers).

Es wird immer von mm auf Pixel umgerechnet, weil jeder Drucker mm-Formate als Ausgabemedium hat und Canvas immer Pixelorientiert ist - alle Canvas-Proceduren erwarten Pixel als Werte.

Das Problem ist nicht gelöst, da - wie oben beschrieben - auch ohne Verwendung von SetMapMode und mit Verwendung von Pixel-Angaben es zur Stauchung kommen kann, je nach Drucker (im o.g. Beispiel: Keine Stauchung beim PDF-Drucker, Stauchung bei einem HP-Drucker (jeweils bei ohne MM_LOMETRIC))
Bei Arial beispielsweise kommt es in keinem Fall zur Stauchung.

[p80286]

Zitat von stefanniehaus:

Das Problem ist nicht gelöst, da - wie oben beschrieben - auch ohne Verwendung von SetMapMode und mit Verwendung von Pixel-Angaben es zur Stauchung kommen kann, je nach Drucker (im o.g. Beispiel: Keine Stauchung beim PDF-Drucker, Stauchung bei einem HP-Drucker (jeweils bei ohne MM_LOMETRIC))
Bei Arial beispielsweise kommt es in keinem Fall zur Stauchung.

Die patzige Antwort lautet "Dann besorg Dir einen ordentlichen Font"
Leider ist das was als fontx auf dem Markt ist nicht immer das gleiche und schon garnicht das selbe. Letztendlich ist das Ergebnis auf Papier nur durch das Zusammenspiel von Druckertreiber,Font und Druckerhardware zu erreichen. Wobei es theoretisch die Möglichkeit gibt, daß der PC ein vollständiges Druckbild malt, oder auf der anderen Seite, daß der Drucker ein paar Steuerbefehle und Ascii-Text erhält.

Wenn Du keine ordentliche Doku für die eingesetzte Hardware/Software hast, dann hilft nur Trial n Error.

Gruß
K-H

[MeierZwoo]

p80286, danke