Probleme mit PrintPreview

[hbr]

Hallo,
ich verwende für den Ausdruck aus einem IpHtmlPanel "IpHtmlPanel1.PrintPreview;“ was auch funktioniert.
Es erscheint daraufhin Die Druckervorschau von „PrintPreview“ und alles Funktioniert korrekt.
Wurde aber im Windows- System kein Drucker eingerichtet oder man verwendet den "PDF-Drucker „Microsoft to PDF“
als Standard Drucker anstelle eines normalen Druckers, erscheint zuerst eine Windowsmaske(von Microsoft to PDF),
wo der Name der PDF-Datei angegeben werden soll.
Wird daraufhin ein Name eingetragen und bestätigt, wird eine 0 Byte PDF Datei erzeugt.
Nach der Windows Maske/Eingabe und Ausführung erscheint dann die Normale „PrintPreview“ Maske,
wo man dann den "Microsoft to PDF Drucker“ auswählen kann und dann ein korrekter PDF-Druck erzeugt wird.
Ich hoffe das meine Beschreibung des Problems aussagekräftig ist, wenn nicht bitte nachfragen!

Und nun meine Frage:
Wie kann ich den Windows Druckdialog umgehen bzw. verhindern das er überhaupt erst erscheint
wenn in Windows der "Microsoft to PDF Drucker“ als Standarddrucker eingestellt wurde?
Natürlich kann ich, wenn die Maske erscheint auf Abbrechen bzw. schließen klicken damit der normale Prozess abläuft.

Wo an welcher Stelle in IpHtml kann man das bewerkstelligen?

Übrigens der Dialog erscheint auch bei den Druckertypen „Adobe PDF, Foxit PhantomPDF Printer“ aber nicht bei PDFCreator.

Bitte um Antwort.

[wp_xyz]

Zunächst mal: Bei mir ließ sich das IpHtml-Package mit aktiviertem Druckersupport ($DEFINE Html_Print) gar nicht kompilieren, weil vor einiger Zeit einige Deklarationen in eine neue Unit (IpHtmlTypes) gewandert sind, die in der Preview-Unit IpHtmlPv nicht in der Uses-Zeile steht. Eingefügt - läuft (leider fallen mir solche Fehler immer dann auf, wenn das neue Release (jetzt v2.2.6) fertig ist...).

Der Microsoft PDF-Druckertreiber will offenbar den Namen der Ausgabedatei immer dann wissen, wenn Printer.BeginDoc aufgerufen wird; das erfolgt auch zu Beginn der Vorschau, um Druckerauflösung etc. abfragen zu können. Anschließend, wenn alles Nötige bekannt ist, wird mit Printer.Abort der begonnene Ausdruck gleich wieder abgebrochen. Bescheuert...

Man kann die Abfrage des Dateinamens verhindern, wenn man Printer.FileName mit einem nicht-leeren String vorbelegt. Nachdem am Ende dieser "Erkennungsroutine" der Druck abgebrochen wird, kann man dort auch den ursprünglichen Inhalt von Printer.FileName wiederherstellen.

Die vorzunehmenden Änderungen in Unit IpHTML wären also folgende:

Code: Alles auswählen

procedure TIpHtmlInternalPanel.ResetPrint;
var
  ...
  oldPrinterFileName: String;   // <--- NEU
begin
  // check ir BeginPrint was called
  if not Printed then begin
    SetRectEmpty(PrintPageRect);
    if Hyper.TitleNode <> nil then
      Printer.Title := Hyper.TitleNode.Title
    else
      Printer.Title := 'HTML Document';
    oldPrinterFileName := Printer.FileName;   // <--- NEU
    Printer.FileName := 'test';               // <--- NEU
    Printer.BeginDoc;
    ...
    Printer.Abort;
    Printer.FileName := oldPrinterFileName;         // <--- NEU
  end else
    raise Exception.Create('BeginPrint must be called before ResetPrint.');
end;

Ich habe nicht zu intensiv getestet, aber der Microsoft-PDF-Treiber verlangt die Druck-Datei nun nur einmal, auch auch Standard-Ausgabe auf Papier wird nicht in eine Datei umgeleitet.

[hbr]

Vielen Vielen ....... Dank!

Funktioniert Hervorragend

Gruß

[wp_xyz]

Hast du auch mal auf einen "normalen" Drucker (Papier) gedruckt?

[hbr]

Hast du auch mal auf einen "normalen" Drucker (Papier) gedruckt?

Ups,
das geht jetzt nicht mehr.

[hbr]

Komando zurück,
geht doch!!! Sory.

[hbr]

Hast du auch mal auf einen "normalen" Drucker (Papier) gedruckt?

Hallo,
leider gibt es noch ein Problem mit Gedruckten Bildern aus dem iphtml.PrintPreview Modul.
Die Bilder sind .png transparent, haben aber beim drucken aus der IpHtmlPanel1.PrintPreview einen schwarzen Hintergrund.
Die Bilder werden im IpHtmlPanel1 korrekt dargestellt.
Werden sie auf Papier gedruckt, so haben sie einen schwarzen Hintergrund.
Der Ausdruck auf Papier aus einem Browser heraus ist OK, auch das drucken in eine PDF Datei.
Das sieht aus, als wäre noch ein Fehler im Druckmodul vorhanden.
Hier ein Beispiel

browser.zip

(38.6 KiB) 30-mal heruntergeladen

[Joh]

ähem... test Lazarus 2.2.4: der Compiler sagt:

unit1.pas(95,16) Error: identifier idents no member "PrintPreview"

IMHO liegt der Fehler etwas tiefer; ich möchte gerade nicht graben bei dem Wetter...

[hbr]

ähem... test Lazarus 2.2.4: der Compiler sagt:

unit1.pas(95,16) Error: identifier idents no member "PrintPreview"

IMHO liegt der Fehler etwas tiefer; ich möchte gerade nicht graben bei dem Wetter...

Also warum in allen Versionen in turbopower_ipro in ipdefine.inc {$DEFINE Html_print} deaktiviert ist, weis ich auch nicht.
Wahrscheinlich weil es noch voller Fehler steckt?
Bei jeder LZ-Neu- Installation muss es erst freigegeben werden.
Ich habe jetzt mal die Version 2.2.4 neu installiert, dass Ergebnis ist das gleiche wie bei den Vorgängerversionen.

[theo]

Ich habe es mir nicht angeschaut, aber aus dem Bauch heraus:
Kann man mit Lazarus überhaupt alphatransparente PNG drucken?
Hast du das schon mal getestet, einfach nur mit einem Canvas unabhängig vom dem iphtml Dingens?
Alpha-Tranparenz und Drucken passen ja irgendwie nicht so recht zusammen.

Wenn die PNG unter deiner Kontrolle sind, würde ich die einfach mit einem weissen Hintergrund zusammenführen und die Alpha-Tranparenz weglassen.
Alternativ könne man auch als PDF speichern und dieses drucken (lassen).

Just my 2 ¢

[wp_xyz]

Hallo,
leider gibt es noch ein Problem mit Gedruckten Bildern aus dem iphtml.PrintPreview Modul.
Die Bilder sind .png transparent, haben aber beim drucken aus der IpHtmlPanel1.PrintPreview einen schwarzen Hintergrund.
Die Bilder werden im IpHtmlPanel1 korrekt dargestellt.
Werden sie auf Papier gedruckt, so haben sie einen schwarzen Hintergrund.
Der Ausdruck auf Papier aus einem Browser heraus ist OK, auch das drucken in eine PDF Datei.
Das sieht aus, als wäre noch ein Fehler im Druckmodul vorhanden.
Hier ein Beispiel browser.zip

Das Beispiel-Projekt benötigte noch einiges an Nacharbeit (andere Dateistruktur nach dem Auspacken als in der lpi-Datei angegeben, Bild-Dateien nicht im pics-Ordner). Und anschließend kann ich das Problem nicht reproduzieren, die Bilder haben im Papier-Ausdruck (und auch im PDF) keinen schwarzen Hintergrund (Windows 11, Laz 2.2.4/FPC 3.2.2 (32 bit), Laz-main/FPC 3.2.2 (32bit und 64bit), zumindest auf meinem Drucker (EPSON Stylus Office BX535WD).

Vielleicht liegt bei dir ein Problem im Druckertreiber vor (wobei sich dann die Frage stellt, warum das aus dem Browser heraus dann doch funktioniert...).

Also warum in allen Versionen in turbopower_ipro in ipdefine.inc {$DEFINE Html_print} deaktiviert ist, weis ich auch nicht.
Wahrscheinlich weil es noch voller Fehler steckt?
Bei jeder LZ-Neu- Installation muss es erst freigegeben werden.

Das IPro-Package ist in Lazarus enthalten, weil man sich dadurch die Hilfe-Texte "schöner" anzeigen lassen kann. Aber dafür braucht man keinen Drucker. Daher ist die Druckerunterstützung durch das Html_print Define ausgeschaltet. Andernfalls müsste auch das Package "Printer4Lazarus" und wahrscheinlich auch "Printers4LazIDE" automatisch eingebunden werden, was man offenbar nicht wollte. Und irgendwie ist Drucken heutzutage ja auch ein Anachronismus (wobei ich weiß, dass das papierlose Büro weiter in der Zukunft liegt als die papierlose Toilette).

[hbr]

Zunächst mal: Bei mir ließ sich das IpHtml-Package mit aktiviertem Druckersupport ($DEFINE Html_Print) gar nicht kompilieren, weil vor einiger Zeit einige Deklarationen in eine neue Unit (IpHtmlTypes) gewandert sind, die in der Preview-Unit IpHtmlPv nicht in der Uses-Zeile steht. Eingefügt - läuft (leider fallen mir solche Fehler immer dann auf, wenn das neue Release (jetzt v2.2.6) fertig ist...).

Genau das habe ich jetzt bei der Installation von LZ 3.0 festgestellt.
Was genau muß dann wo eingefügt werden, damit IpHtml wieder Funktioniert?

[wp_xyz]

Zunächst mal: Bei mir ließ sich das IpHtml-Package mit aktiviertem Druckersupport ($DEFINE Html_Print) gar nicht kompilieren, weil vor einiger Zeit einige Deklarationen in eine neue Unit (IpHtmlTypes) gewandert sind, die in der Preview-Unit IpHtmlPv nicht in der Uses-Zeile steht. Eingefügt - läuft (leider fallen mir solche Fehler immer dann auf, wenn das neue Release (jetzt v2.2.6) fertig ist...).

Genau das habe ich jetzt bei der Installation von LZ 3.0 festgestellt.
Was genau muß dann wo eingefügt werden, damit IpHtml wieder Funktioniert?

LZ 3.0? Meinst du Laz-main (2.3.1)? Zieh dir die aktuelle Version vom GitLab-Repository, dass bekommst du den richtigen Code. Ansonsten öffne die Unit IpHtmlPv und schreibe "IpHtmlTypes" ans Ende der "uses"-Zeile des Interface-Teils.

Bei dem Testprogramm musste ich für Laz/main auch noch die Unit IpHtmlNodes in der Uses-Zeile angeben, weil die Node-Deklarationen zur Vereinfachung des Monster-Codes in IpHtml in eine separate Unit ausgelagert wurden

Siehe auch: https://wiki.freepascal.org/Lazarus_2.4 ... Power_ipro

[hbr]

LZ 3.0? Meinst du Laz-main (2.3.1)? Zieh dir die aktuelle Version vom GitLab-Repository, dass bekommst du den richtigen Code. Ansonsten öffne die Unit IpHtmlPv und schreibe "IpHtmlTypes" ans Ende der "uses"-Zeile des Interface-Teils.

Danke,
ich Installiere über fpcupdeluxe(auch GitLab),
Habe dann die Trunkversionen installiert.
Dann hat er LZ 2.3.0 und FPC 3.3.1 installiert.
Dort sind die Änderungen nicht enthalten, habe sie dann Manuel eingesetzt.
Aber auch mit dieser Version bleibt der Hintergrund der *.png’s schwarz.

[wp_xyz]

Den schwarzen Hintergrund sehe ich jetzt, wenn ich dein Testprogramm unter Linux verwende; dort werden auch in der Vorschau die dunklen Partien der knienden Person in der Hintergrundfarbe dargestellt, offenbar arbeitet IPro hier mit Farb-Transparenz. Dieses Bild ist im gif-Format, dessen Unterstützung in FPC nur sehr rudimentär ist. Ich habe es mit einem Bildbearbeitungsprogramm in ein png mit Alpha-Kanal konvertiert und den html-Quelltext entsprechend geändert -- nun wird es auch unter Linux korrekt angezeigt und ausgedruckt.

Wenn du dir diese Akrobatik sparen willst, müsstest du nach einer anderen Bibliothek für gif-Support suchen - evtl reicht GifAnim oder GifViewer im OPM, oder vielleicht kann auch bgrabitmap mit gif umgehen.