Pages: 1

#1 Re: PDF Engine » Clipping problems » 2017-01-13 14:04:09

jkelley

Thank you very much for looking into this.

In case anyone else runs into this problem, I was able to get my code working again simply by reverting the enhanced clipping process patch in my local copy of SynPDF (so I don't have any immediate needs for a fix).

#2 Re: PDF Engine » Clipping problems » 2017-01-04 19:30:06

jkelley

Thank you.

I've uploaded the metafile to https://dl.dropboxusercontent.com/u/152 … tafile.emf.

Here's a simplified version of the C++ code we're using to create the PDF.

  TPdfDocumentGDI *document = new TPdfDocumentGDI(false, CP_UTF8, false, NULL);

  document->DefaultPaperSize = psLetter;
  document->ScreenLogPixels = 254;
  document->DefaultPageLandscape = true;
  document->CompressionMethod = TPdfCompressionMethod::cmFlateDecode;
  document->AddPage();

  TMetafile *mf = new TMetafile;
  mf->LoadFromFile("c:\\temp\\metafile.emf");

  document->VCLCanvas->StretchDraw(TRect(127, 127, 2667, 2032), mf);
  document->SaveToFile("c:\\temp\\file.pdf");

  delete document;
  delete mf;

#3 PDF Engine » Clipping problems » 2016-12-21 23:24:43

jkelley
Replies: 8

One of our PDF reports (containing some metafiles drawn by some third-party code outside of our control then copied to PDF) isn't working in the current version of SynPDF.

Most of each page appears blank, and Adobe Reader is complaining that "An error exists on this page."

I have checked against the latest version of SynPDF from GitHub. The report worked in older versions of SynPDF. I did some investigating, and it looks like the "enhanced clipping process" patch's change to TPdfEnum.ExtSelectClipRgn introduced the problem. (In other words, if I edit SynPdf.pas and change back just the TPdfEnum.ExtSelectClipRgn function, my PDFs work.)

I spent some time playing around with ExtSelectClipRgn to see if I could fix the problem, but unfortunately, I'm having trouble figuring out my way around the codebase. I tried the RGN_COPY change described here, and that didn't help.

I can post examples of the functioning and non-functioning PDFs, if that would help. Unfortunately, since the report generator code involves some third party-code, I can't easily share that.

#4 Re: PDF Engine » C++Builder support » 2015-10-22 02:38:46

jkelley

I submitted a PR to https://github.com/synopse/SynPDF/pull/5. Thank you.

#5 Re: PDF Engine » C++Builder support » 2015-10-15 02:23:43

jkelley

My initial C++Builder work was only for the latest release version. I see now that the development version uses "object" for TTimeZoneData and TTimeZoneValue, and that's also causing problems for C++Builder.

Pardon my ignorance, but what's the difference between a record and an object in Delphi? It looks like changing TTimeZoneData and TTimeZoneValue to record will make C++Builder happy, but are there any disadvantages to doing so? (From looking around online, all I can tell is that "object" is needed for class-like behavior in pre-Delphi 2006. Are there other differences?)

#6 PDF Engine » C++Builder support » 2015-10-11 01:28:58

jkelley
Replies: 5

I've been looking for a good, free PDF library that's easy to integrate into our C++Builder projects. From my brief time playing with it, PDF Engine is a good, free PDF library that's... kind of easy to integrate into our C++Builder projects.

I'm sure that C++Builder support isn't a primary goal with this library, but would you be open to code changes to make it work?

Here are the problem areas:

Macro conflicts: Some constants in SynPdf.pas conflict with macros in Microsoft's wingdi.h. Fixing these is easy; just exclude them from the auto-generated SynPdf.hpp:

  {$NODEFINE MWT_IDENTITY}
  {$NODEFINE MWT_LEFTMULTIPLY}
  {$NODEFINE MWT_RIGHTMULTIPLY}

TSynValidateText: C++Builder apparently doesn't support using array elements as properties. This prevents TSynValidateText and TSynValidatePassWord from working. I can think of two workarounds:

  1. Simply exclude them from the .hpp files (using {$NODEFINE}), so that they won't be accessible from C++ code but the rest of the library will work.

  2. Make a bunch of setter and getter functions (GetMinLength, SetMaxLength, etc.) so that the properties can be implemented in terms of them and they can be implemented in terms of the fProps array.

At this point, our needs are pretty simple - we just want to create a PDF file, write to it with the VCLCanvas, then save it. So I'm tempted to use {$NODEFINE}, to avoid adding complexity to the code that isn't currently needed.

Script... records and functions: Delphi apparently can't export variant records in a format that C++Builder can use. This affects TScriptState, TScriptAnalysis, TScriptItem, and TScriptVisAttr. As I understand it, these records and the functions that use them exist only in SynPdf.pas to provide Delphi access to usp10.dll. C++ code can already access usp10.dll by including usp10.c, so it seems best to {$NODEFINE} all of these records and all of the Script... functions.

TZipWrite: The last problem is in TZipWrite.CreateFrom. Because Delphi constructors are exported to .hpp as standard C++ constructors, and because standard C++ constructor overloads are all named after the class and can only be distinguished by their parameter list, having two Delphi constructors that have identical parameter lists creates problems. The docwiki has more details. The workaround that they suggest there - adding a default-value "dummy" parameter to distinguish the two - is ugly, but it's simple and works and doesn't affect callers.

Are you willing to add these workarounds to the PDF Engine? If so, I can submit a full patch (or PR on GitHub, or whatever you prefer).

Pages: 1

Board footer

Powered by FluxBB