Dear list,

I have a problem compiling PowerPDF and seek your knowledge to solve it.

I've written a program on Linux where the PowerPDF works perfectly, but when I tried to compile it on the machine at work (Windows XP) it gives an

"Illegal type conversion 'Short String' to 'PChar'"

in powerpdf/pdftypes.pas lines 1007, 1010 and 1146 (see below).

I'm using Lazarus 1.0, FPC 2.6.0 and PowerPDF 0.9.9.

Thanks in advance
Tobias

------ Code Sniplet (lines 1005 to 1011)-----
  {$IFNDEF UNIX}
  Len := MultiByteToWideChar(0, CP_ACP,
    PChar(Value), Length(Value), nil, 0);
  GetMem(PW, Len * 2);
  Len := MultiByteToWideChar(0, CP_ACP,
    PChar(Value), Length(Value), PW, Len * 2);
  {$ELSE}
------ Code Sniplet (lines 1143 to 1147)-----
// _WriteString
procedure _WriteString(const Value: string; AStream: TStream);
begin
  AStream.Write(PChar(Value)^, Length(Value));
end;

Looks like Delphi mode or AnsiString as default string option is missing... Strings other than ShortStrings should be convertible to PChar.

2013/1/30 Tobias Diekershoff

Hm... I'm using PowerPDF fine on Windows 7.

I even managed to remove the dependency of LCL to be able to create PDFs and CGI applications:

https://lazarus-ccr.svn.sourceforge.net/svnroot/lazarus-ccr/components/powerpdf

http://silvioprog.com.br/cgi-bin/cgi2

program project1;
{$mode objfpc}{$H+}

uses
Classes,
FPimage,
FPReadJPEG,
FPWriteJPEG,
PdfDoc,
PdfFonts,

  PdfTypes;

  function CreateImage(AImage: TFPCustomImage): TPdfImage;
  var
    VWriter: TFPWriterJPEG;
  begin
    Result := TPdfImage.CreateStream(nil);
    VWriter := TFPWriterJPEG.Create;
    try
      with Result do
        try
          AImage.SaveToStream(Stream, VWriter);
          with Attributes do
          begin
            AddItem('Type', TPdfName.CreateName('XObject'));
            AddItem('Subtype', TPdfName.CreateName('Image'));
            AddItem('ColorSpace', TPdfName.CreateName('DeviceRGB'));
            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;
    finally
      VWriter.Free;
    end;
  end;
var
  VPdf: TPdfDoc;
  VFile: TFileStream;
  VImage: TFPMemoryImage;
begin
  VPdf := TPdfDoc.Create;
  VFile := TFileStream.Create('print.pdf', fmCreate);
  VImage := TFPMemoryImage.Create(0, 0);
  try
    VPdf.NewDoc;
    VPdf.AddPage;
    VImage.LoadFromFile('image.jpg');
    VPdf.AddXObject('Image', CreateImage(VImage));
    VPdf.Canvas.DrawXObject(80, 650, VImage.Width, VImage.Height, 'Image');
    VPdf.Canvas.TextOut(90, 770, 'Print OK!');
    VPdf.SaveToStream(VFile);
    WriteLn('Print OK!');
  finally
    VImage.Free;
    VFile.Free;
    VPdf.Free;
  end;
end.

Interesting.

Do you think the basics could be included in the standard FPC distribution ?

Michael.

2013/1/30 Michael Van Canneyt

Perfectly. IMHO, PowerPDF is well modeled, separated by layers. My changes uses pure FCL. :)

There are some things to be improved in PowerPDF:

. Native support to PNG images; (I'm working on this) . Use a new version of PDF (at least 1.4);
. FlateDecode support; (I'm studying this right now) . Removes LCL dependences; (I'm studying this right now)

I was thinking of creating a fork and work on it, but if these new changes can be implemented PowerPDF and distributed in FPC, I would be very happy. :)

ps. IMHO, this is wrong:
https://github.com/jepafi/Free-JPDF-Pascal/blob/master/libjpfpdf.pas#L1681. He promises to support multiple images, but internally it converts them all to JPEG, and this causes lose quality in some images. PDF supports PNG natively, but need to implement the specification exactly how Adobe explains. Two explains below:

For JPEG:
1 - DCTDecode a lossy filter based on the JPEG standard; (I implemented it)

For PNG:
1 - FlateDecode a commonly used filter based on the zlib/deflate algorithm (a.k.a. gzip, but not zip) defined in RFC 1950 and RFC 1951; introduced in PDF 1.2; it can use one of two groups of predictor functions for more compact zlib/deflate compression: Predictor 2 from the TIFF 6.0 specification and predictors (filters) from the PNG specification (RFC 2083);
2 - LZWDecode a filter based on LZW Compression; it can use one of two groups of predictor functions for more compact LZW compression: Predictor 2 from the TIFF 6.0 specification and predictors (filters) from the PNG specification;

I would be happy too :-)

ps. IMHO, this is wrong: https://github.com/jepafi/Free-JPDF-Pascal/blob/master/libjpfpdf.pas#L1681. He promises to support multiple images, but internally it converts them all to JPEG, and this causes lose quality in some images. PDF supports PNG natively, but need to implement the specification exactly how Adobe explains. Two explains below:

If you can implement the PNG support, then we could add it all to FPC in one go, if the author agrees.

Michael.

2013/1/30 Michael Van Canneyt

:D

The PowerPDF's author: Copyright (c) 1999-2001 Takezou. <

. Will he participates in this list? :/

If he allows it, I improve all the "Pdf*.pas" units. It is possible to maintain full compatibility with FCL, and provide support for the future FPReport.

Hello leledumbo!

Looks like Delphi mode or AnsiString as default string option is missing...

Thanks, that was the missing spot :-)

so long
Tobias

--- El mi? 30-ene-13, silvioprog escribi?:

De: silvioprog
Asunto: Re: [Lazarus] compiling PowerPDF on win32
A: "Lazarus mailing list"
Fecha: mi?rcoles, 30 de enero de 2013, 5:01

2013/1/30 Michael Van Canneyt

On Wed, 30 Jan 2013, silvioprog wrote:

2013/1/30 Tobias Diekershoff

? ? ? Dear list,

What exactly have you changed?, I took your code, put it in a new 'program' project (so no LCL dependency) added powerpdf requirement, compiled and it worked without changes....?? PowerPDF has been always be able to work in console mode programs? :)
. Or perhaps console programs not always can be a cgi program? this I don't know.

Perfectly. IMHO, PowerPDF is well modeled, separated by layers. My changes uses pure FCL. :)

Interesting.

Do you think the basics could be included in the standard FPC distribution ?

Michael.
I don't know, a part of PowerPDF do not requires LCL a part it does, how good would it be splitting it? just because a part of it is supposed to work in the Lazarus IDE I prefer to have it in Lazarus rather than in FPC. It is not currently in Lazarus because, on contrary to the guys of FastReport, Inc. in the case of LazReport, the original author never replied to the petition to change PowerPDF licence to modified LGPL. There are some things to be improved in PowerPDF:
. Native support to PNG images; (I'm working on this)

. Use a new version of PDF (at least 1.4);. FlateDecode support; (I'm studying this right now). Removes LCL dependences; (I'm studying this right now)

Great, FlatDecode is already supported though, looking forward your improvements. I was thinking of creating a fork and work on it, but if these new changes can be implemented PowerPDF and distributed in FPC, I would be very happy. :)

Well, if you plan to work on PowerPDF and change it in a way that it would serve only to your purposes, you can do it of course, if not, why don't ask for permissions to work directly on the ccr repository?

Jesus Reyes A.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20130130/610c56ec/attachment-0001.html>

El 30/01/2013 12:01, silvioprog escribi?:

Hello,

I'm working in a PDF rendering unit which currently can render very basic PDFs (you know, some rects, no clipping, some texts...) so any advance in any filter will be welcome. To generate the FlateDecode you can use the "ztream" unit and the TCompressionStream class (with ASkipHeader=false).

Simple PDFs that use filters and predictors will be welcomed also.

Very far draft:

http://pastebin.com/XLKBnC01