Evaluating Wpdf - some problems

Hello all,

I am working on a huge (Unicode-enabled) application that produces very detailed graphic output and I want to give it PDF support without resorting to a PDF printer driver such as Adobe Acrobat. My application generates so much graphic output that, for speed reasons, it uses Windows GDI commands rather than the methods wrapped by Delphi's tCanvas object.

So, from a Delphi point of view, I grab the HDC wrapped by the Tcanvas.Handle property and do all my painting using GDI. My application works well with any Windows GDI device, and it also works problem-free with the Adobe Acrobat printer driver. I am currently evaluating several PDF libraries, including wpdf, that support tcanvas/hdc, hoping to be able
to use the best candidate as a drop-in replacement for Acrobat.

So far during my test of Wppdf I am encountering some unexpected problems and even crashes.

Problem 1: text not getting printed.

This is my biggest problem. For some reason, a lot of text produced by my application (using TextOutW) does not get printed, whereas it prints perfectly on all other GDI devices. Maybe it has to do with the way I create fonts (GDI:createfontindirect)?

Problem 2: pdf.CidFontMode=WPCidUnicode produces GPF's

My application supports unicode. Setting property "pdf.CidFontMode" to "wpCIDUnicode" results in GPF's while printing. I had to set it to wpcidoff to prevent that - must be a bug.

Problem 3: LineTo() appears to draw endpoints too.

This is only a minor problem: Upon closer examination of the output, it appears that lines drawn using the GDI Method LineTo() are drawn including their endpoints. GDI devices should exclude the end points.

Problem 4: Resolution of Wppdfprinter HDC is difficult to set

My next problem is obtaining a sensible resolution. I need at least 300 REAL dpi's, better even would be 600 dpi. If property "pdf.canvasreference" has its default value WpRefScreen, that gives me a resolution of only 96 dpi. Explicitly specifying 300 dpi in pdf.startpage does give me a logical coordinate system of 300 dpi, but the accuracy "on paper" appears to be still only 96 dpi so that doesn't really help.

Setting property "pdf.canvasreference" to wpRefPrinter gives much better results, but specifying any other resolution than 600 dpi (which happens to be the resolution of my default printer) results in partly empty pages (GDI objects not being drawn). The only resolution that kinda works is 600 dpi. The end user of my product may have different hardware, so how do I obtain the dpi that works for him or her?

To clarify for other readers, mr Ziersch was extremely friendly and helpful in testing some EMF and PDF files that I sent him, even though I am only a potential buyer yet.
It appears that the wpdf demo file that I downloaded from the website was a bit outdated (3.0.0.0 instead of 3.0.7.6). The latest demo file fixes most of the problems.

The one and biggest problem that remains for me is the lack of support for mixed-language Unicode strings that contain a mixture of different character sets (e.g. Latin / Arabic). In my business (oilfield) that support is mandatory, we have customers who write reports in Arabic or Russian and who need to be able to embed English foreign words into their text and vice versa.

This has never been a problem with Adobe Acrobat or even with freeware PDF printer drivers such as CutePDF. So the problem is new and unexpected for me; in the past a GDI procedure like TextOutW() simply produced correct results no matter what strings I fed it with. I readily admit that this won't be a problem for 99% of Wpdf users, but I'm kind of stuck with this. I will probably have to pre-process all strings I want to output to the canvas and subdivide them into substrings with different character set requirements and then manually switch character sets for each substring, even though the original unicode font I selected (in this case, "Tahoma") already contains all necessary characters (Windows has a character set viewer utility to verify this) ... this process kinda contradicts the whole Unicode thought IMHO.

What worries me, though, is the fact that the same problem occurs with richedits.
Wpdf isn't outputting the content of mixed-language reports in richedits correctly either, and I have no influence at all over the richedit rendering process (it's all done by the richedit control). This is puzzling, because I am pretty sure that the richedit control switches character sets during the rendering process; a competing pdf product (that otherwise suffers from the exact same problem as wpdf) DOES render the richedit's text correctly, whereas wpdf produces Umlauts (ÖÄÜ) instead of Arabic characters.

I really need mixed-language richedits to work correctly with wpdf, because there's no way I can tweak the rendering process to make it work.