Druckt PowerPDF Komponente fehlerhaft?

[Perlsau]

Hallo,

ich befasse mich seit einigen Tagen mit verschiedenen Möglichkeiten, aus Delphi heraus PDF-Dateien zu erzeugen, ohne einen PDF-Drucker einzusetzen. Dabei bin ich auf die Komponente PowerPDF gestoßen, die mir für mein Vorhaben passend schien.

In meinem Testprogramm verwende ich eine ListBox zum Sammeln einiger JPG-Dateien, mit denen die PDF-Datei erzeugt werden soll (siehe Bild im Anhang). In einer Scrollbox rechts im Formular befindet sich eine TPRPage, darauf ein PRLayoutPanel und auf diesem wiederum ein TPRJpegImage und unten (nicht sichtbar) ein TPRText. Wenn ich nun zum PDF-Drucken meine Listbox-Items durchgehe und einmal das dort angegebene JPG in die TPRJpegImage-Komponente lade, des weiteren den String aus der Listbox in die Komponente TPRText, entsteht ein PDF mit der richtigen Seitenanzahl, aber mit immer demselben ersten JPG-Bild. Der Text unten wiederum enthält den gewünschten String. Steht das Property SharedImage der Komponente TPRJpegImage auf FALSE, bleiben die Seiten im PDF außer der ersten ganz leer ...

Meine PDF-Druck-Methode sieht so aus:

Delphi-Quellcode:

// PDF erstellen
procedure TFormMain.Button2Click(Sender: TObject);
VAR
   i    : Integer;
begin
     IF ListBox1.Count = 0 THEN EXIT;

     PReport1.BeginDoc;

     FOR i := 0 TO ListBox1.Count -1 DO
     BEGIN
          PRJpegImage1.Picture.LoadFromFile(ListBox1.Items[i]); // JPG einlesen
          PRJpegImage1.Repaint;                                 // auffrischen
          PRText1.Text := ListBox1.Items[i];                    // String einlesen
          PRText1.Repaint;                                      // auffrischen

          PReport1.Print(PRPage1);                              // Seite in Report erstellen
     END;

     PReport1.EndDoc;

     IF Dialogs.MessageDlg('Erzeugte PDF-Datei mit Adobe Reader anschauen?',
                           mtConfirmation, [mbYes, mbNo], 0, mbYes) = mrYes THEN

     ShellExecute(Handle, nil, PWideChar(PReport1.FileName), nil, nil, SW_SHOW);
end;

Seltsam dabei ist, daß die verschiedenen JPG-Dateien durchaus in die Komponente TPRJpegImage geladen werden, beim Druckversuch ebenso wie beim Zuweisen via ListBox1Click:

Delphi-Quellcode:

procedure TFormMain.ListBox1Click(Sender: TObject);
begin
     PRJpegImage1.Picture.LoadFromFile(ListBox1.Items[ListBox1.ItemIndex]);
     PRJpegImage1.Repaint;
     PRText1.Text := ListBox1.Items[ListBox1.ItemIndex];
     PRText1.Repaint;
end;

Bestimmt mache ich irgend etwas grundsätzlich falsch ... wenn ich nur wüßte was ...
Das komplette Testprojekt kann man sich runterladen:
http://www.delphiman.de/Test/PowerPDFTest.zip

[Perlsau]

Offenbar hat PowerPDF einen Bug in der Jpg-Kompo, denn wenn ich ein TPRImage statt eines TprJpegImage nehme und damit BMPs lade, wird die PDF-Datei korrekt erzeugt.

[Perlsau]

Nun hab ich endlich eine Lösung gefunden: ich erstelle ein JBild :
TJPegImage, das die JPG-Dateien einliest:

JBild.LoadFromFile(ListBox_Bilder.Items[i]);

Danach weise ich dem Bitmap des PowerPDF-Image das Bild zu:

PRImg.Picture.Bitmap.Assign(JBild);

Damit wird die PDF-Datei korrekt erstellt.


Hinweis: CrossPost im Usenet:
de.comp.lang.delphi.misc

[teebee]

Habe den Fehler in der Komponente (in PdfJpegImage.pas) gefunden, es wird immer ColorSpace DeviceRGB ins PDF geschrieben, auch wenn es ein Graustufen-JPEG ist. Der Reader findet dann natürlich nicht genug Daten. Alle Bilder, die in Deinem Beispiel nicht funktionieren, sind Graustufen-JPEGs.

Delphi-Quellcode:

// CreateImage
function TPdfJpegImage.CreateImage(AImage: TGraphic): TPdfImage;
begin
  // check whether specified graphic is valid image.
  if not (AImage is TJpegImage) then
    raise EPdfInvalidValue.Create('only jpeg image is allowed.');

  result := TPdfImage.CreateStream(nil);
  with result do
  try
    TJpegImage(AImage).SaveToStream(Stream);
    with Attributes do
    begin
      AddItem('Type', TPdfName.CreateName('XObject'));
      AddItem('Subtype', TPdfName.CreateName('Image'));

      // Hier auf Graustufen prüfen
      If TJpegImage(Aimage).Grayscale Then
       AddItem('ColorSpace', TPdfName.CreateName('DeviceGray'))
      Else
       AddItem('ColorSpace', TPdfName.CreateName('DeviceRGB')); // ursprünglich wird immer RGB geschrieben

      AddItem('Width', TPdfNumber.CreateNumber(AImage.Width));
      AddItem('Height', TPdfNumber.CreateNumber(AImage.Height));
      AddItem('BitsPerComponent', TPdfNumber.CreateNumber(8));
      PdfArrayByName('Filter').AddItem(TPdfName.CreateName('DCTDecode'));
    end;
  except
    result.Free;
    raise;
  end;

Gruß, teebee

[Perlsau]

Zitat:

Zitat von teebee (Beitrag 1159409)

Habe den Fehler in der Komponente (in PdfJpegImage.pas) gefunden, es wird immer ColorSpace DeviceRGB ins PDF geschrieben, auch wenn es ein Graustufen-JPEG ist. Der Reader findet dann natürlich nicht genug Daten. Alle Bilder, die in Deinem Beispiel nicht funktionieren, sind Graustufen-JPEGs.

Okay, das leuchtet mir sofort ein. Weil ich aber sowieso verschiedene Bildformate als Quelle ermöglichen will, werde ich bei meiner Lösung ohne PdfJpegImage bleiben und dafür sorgen, daß in die PowerPDF-Bitmap-Komponente eben immer nur Bitmaps geladen werden. Der Anwender soll ja auch BMPs, PCXs, TIFs und weitere Formate als Quelle für seine PDF-Datei auswählen können.

Dennoch bedanke ich mich herzlich bei dir für diesen wertvollen Hinweis. Meine PowerPDF-Kopie werde ich sofort demtentsprechend korrigieren ... hab's korrigiert und es funktioniert mit dem direkten Laden von Graustufen-JPGs.

[Klaus01]

.. kan auch einer den Entwickler in Kenntnis setzen ...

Grüße
Klaus

[Perlsau]

Zitat:

Zitat von Klaus01 (Beitrag 1159419)

.. kan auch einer den Entwickler in Kenntnis setzen ...

Ist erledigt, habe eben dem Roman Kassebaum eine entsprechende Message via Sourceforge-Messenger zukommen lassen.

[teebee]

Wusste gar nicht, dass es einen neuen Maintainer gibt. Habe die Komponente von dort. Na ja, allzuviel hat sich bisher noch nicht geändert.

Gruß,
teebee

[Perlsau]

Zitat:

Zitat von teebee (Beitrag 1159427)

Wusste gar nicht, dass es einen neuen Maintainer gibt. Habe die Komponente von dort. Na ja, allzuviel hat sich bisher noch nicht geändert.

Dort steht aber auch ganz deutlich:

The PowerPDF project is obsolete.
I am sorry to say, I am not already Delphi user.
If anyone wishes to develop PowerPDF instead of me. Please contact me.

[teebee]

Stimmt, aber dass sich schon jemand gemeldet hat, steht da ja nicht, geschweige denn, wer...:wink:

[Perlsau]

Zitat:

Zitat von teebee (Beitrag 1159434)

Stimmt, aber dass sich schon jemand gemeldet hat, steht da ja nicht, geschweige denn, wer...:wink:

Vermutlich deshalb, weil sich Takeshi Kanno eben nicht mehr darum kümmert. Immerhin scheint diese Komponente doch ganz brauchbar zu sein für nichtkommerzielle bzw. kleine Projekte wie meines ... Das alleine zählt für mich.

[romankassebaum]

Hallo zusammen,

vor einiger musste ich ein bestehendes großer Projekt von D2007 nach D2009 (Unicode) konvertieren. Dieses Projekt nutzt PowerPDF.
Also habe ich Takeshi Kanno angeschrieben, mit der Bitte, das Projekt weiterführen zu dürfen.
Da der sich nicht gemeldet hat, habe ich das Projekt unter SourceForge gehostet.

Unter DXE2 habe ich am Freitag noch ein großes Problem bemerkt:
Der ursprüngliche Entwickler nutzt with-Anweisungen für ein TRect. Seit DXE2 hat ein TRect auch die Eigenschaft Height, was zu Konflikten mit der Height der Komponenten führt.

Ehrlich gesagt, möchte ich niemanden empfehlen, PowerPDF in neuen Projekten einzusetzen. Ich habe jedenfalls keine Pläne, PowerPDF für andere Plattformen anzubieten.

--
Roman Kassebaum

[Perlsau]

Zitat:

Zitat von romankassebaum (Beitrag 1159563)

Hallo zusammen, vor einiger musste ich ein bestehendes großer Projekt von D2007 nach D2009 (Unicode) konvertieren. Dieses Projekt nutzt PowerPDF. Also habe ich Takeshi Kanno angeschrieben, mit der Bitte, das Projekt weiterführen zu dürfen. Da der sich nicht gemeldet hat, habe ich das Projekt unter SourceForge gehostet.

Finde ich Klasse, daß du das übernommen hast und daß du hier Rückmeldung erstattest ...

Zitat:

Zitat von romankassebaum (Beitrag 1159563)

Unter DXE2 habe ich am Freitag noch ein großes Problem bemerkt: Der ursprüngliche Entwickler nutzt with-Anweisungen für ein TRect. Seit DXE2 hat ein TRect auch die Eigenschaft Height, was zu Konflikten mit der Height der Komponenten führt.

Das läßt sich ja leicht beheben. Werd' ich gleich nach dem Essen angehen ...

Zitat:

Zitat von romankassebaum (Beitrag 1159563)

Ehrlich gesagt, möchte ich niemanden empfehlen, PowerPDF in neuen Projekten einzusetzen. Ich habe jedenfalls keine Pläne, PowerPDF für andere Plattformen anzubieten.

Den Verdacht hatte ich auch bereits. Aber was gibt's sonst noch Kostenloses?

[Delphi-Laie]

Aus gutem Grunde mag ich die with-Anweisung bis heute nicht. Einmal mehr eine Bestätigung, dem Bauchgefühl zu vertrauen.

Der eine findet den einen, der andere den anderen Fehler. Die Quelltexte sind also vorhanden. Was hindert demnach noch wen daran, die Komponente zu korrigieren, einzusetzen und ggf. moderat (!) weiterzuentwickeln?

[romankassebaum]

Übernächste Woche habe ich Zeit und kann PowerPDF auf SourceForge aktualisieren.

Falls jemand bei PowerPDF mitmachen möchte, dann kann ich ihn zu dem Projekt hinzufügen.

In den neuen kommerziellen Projekten nutze ich zur Zeit den PDF-Export des FastReports.

--
Roman

[Sir Rufo]

Zitat:

Zitat von romankassebaum (Beitrag 1159601)

In den neuen kommerziellen Projekten nutze ich zur Zeit den PDF-Export des FastReports.

Obwohl der grauselige PDFs erzeugt?

Die Engine an sich finde ich sehr gut, aber der PDF-Export ist unterirdisch

[Bummi]

@Sir Rufo

zugegeben sehr hübsch ist der Export nicht, für meine Zwecke hat es meist gereicht.
Bei den Projekten, bei denen der Kunde mehr Wert auf die Optik legt verwenden Kollegen Fastreport im Zusammenspiel mit http://www.gnostice.com/edocengine_vcl.asp