Beiträge von Arthur Hoornweg

It gives this error (A real value is larger than 2^15-1) for any page size, even for PDF's that are only DIN A4 or A3 in height.

Hello WPDF team,

I am having the problem that Adobe Acrobat Viewer won't display some pdf's that I make using WPDF. These are files which have very large pages (several metres). The weird thing is that these files display perfectly correctly on other pdf viewers. My problem is that my customers absolutely demand such large pages and are unwilling to compromise.

I found an online PDF validation tool at http://www.pdf-tools.com/pdf/validate-pdfa-online.aspx and it shows me the following error report when I upload my pdf there:

Validating file "xxxx.pdf" for conformance level pdfa-1a
A real value is larger than 2^15-1.
The key CIDSet is required but missing.
The dictionary must not contain the key 'Encoding'.
The embedded TrueType font WPCUBE+Wingdings contains more than one cmap entries.
The width for character 34 in font 'WPCUBE+Tahoma' does not match.
The width for character 35 in font 'WPCUBE+Tahoma' does not match.
.... (this goes on several hundred times)
The document does not conform to the requested standard.
The document contains fonts without embedded font programs or encoding information (CMAPs).
The document contains fonts without appropriate character to unicode mapping information (ToUnicode maps).
Done.

They also have an online pdf "repair" tool. I tried hat too, but it gives me the following error report:

Open file.
Analyze Objects.
0x80410303 - E - The object's identity 40 doesn't match with the object's reference identity 8.
- File: C:\TEMP\tmpCF9F.tmp
0x80410303 - E - The object's identity 40 doesn't match with the object's reference identity 9.
- File: C:\TEMP\tmpCF9F.tmp
0x80410303 - E - The object's identity 40 doesn't match with the object's reference identity 10.
- File: C:\TEMP\tmpCF9F.tmp
0x80410303 - E - The object's identity 40 doesn't match with the object's reference identity 11.
- File: C:\TEMP\tmpCF9F.tmp
0x80410303 - E - The object's identity 43 doesn't match with the object's reference identity 18.
- File: C:\TEMP\tmpCF9F.tmp
0x80410303 - E - The object's identity 43 doesn't match with the object's reference identity 19.
- File: C:\TEMP\tmpCF9F.tmp
0x80410303 - E - The object's identity 43 doesn't match with the object's reference identity 20.
- File: C:\TEMP\tmpCF9F.tmp
0x80410303 - E - The object's identity 43 doesn't match with the object's reference identity 21.
- File: C:\TEMP\tmpCF9F.tmp
Analyze Outlines.
Analyze Pages.
0x80410113 - E - The file is corrupt and cannot be repaired. Some of the contents can possibly be recovered.

I don't know if any of these errors are serious enough for Acrobat to reject my file but I would be grateful if you could somehow help me to get my files to work.

Arthur

Hi Julian,

no, the EMF does not create an intermediate bitmap. It is just a very large page with lots of text, lines and dashes and two small bitmaps.

I am having problems with Acrobat Viewer, newer versions won't display my large pages (5m) anymore and my customers require an endless printout.

So I need to find the "magical limit" of the page size.

So for testing I created a page of 2.5 m and simply output the same metafile twice just to see if Adobe would swallow the two-page document.

The first wpdf.DrawMetaFileEx() runs fine, the second causes heap errors.

Hello WPCubed team,

if I call "wpdf.DrawMetaFileEx (0,0,0,0,hMetafile,dpi,dpi)" twice in succession with the same (huge page) hMetafile as a parameter, then the first call succeeds, but the second attempt fails.

The Delphi event log then shows lots of "Heap corruption detected at xxxxx" messages during the second call.

This is with WPDF300A version 3.77.0.0.

I have finally found the solution to this riddle.

If the reference device of a metafile is a HP Laserjet, SelectClipRgn() appears to behave unreliably. Since WPDF uses metafiles internally, it is affected by this.

I used to use this code to create a rectangular clipping area:

hrgn := CreateRectRgn(left, top, left + width, top + height);
resultcode:=SelectClipRgn(hdc, Hrgn);
DeleteObject(hrgn);

... but it turns out that "resultcode" often indicates that the clip region is a NULL region (even though the coordinates of the region are fine and well within the page rectangle) and subsequent plotting goes into Nirvana.

But there's a simple workaround. I have found the following to work 100% reliably and it performs the same task as the code above:

SelectClipRgn(hdc,0);
IntersectClipRect (hdc,left, top, left + width, top + height);

Hello all,

I am trying to create *huge* PDF pages but I'm experiencing crashes.

When I create a pdf page with 96 dpi (reference device = screen) that is 9362 pixels high, 1123 pixels wide, the computer crashes all over the place as soon as I perform "tWPPdfPrinter.enddoc".

In the Delphi IDE, the CPU window opens with a breakpoint in the routine "ntdll.DbgBreakPoint". Subsequently the computer reports "out of memory" though the machine has 3 GB of which most is free.
Small pages are no problem, of course, but I really need to create extremely large pages. They are no problem whatsoever in either Adobe PDF or CutePDF at 150 dpi.

Are there any limitations on complexity or page size inside WPPDF (apart from the 32000 pixel coordinate system limitation which I'm well aware of) ?

Hi Julian,

I'll try your test suggestion and report back.
The missing objects are not just images, they are lines, polylines and fills as well. Not just at the edges of the page but everywhere, randomly. The page size in this particular file was DIN A4 and resolution was 600dpi IIRC. I can send you the file in the "right" and "faulty" versions if you want but you must treat them confidentially.

Might I suggest, as an improvement to WPDF3, that the user be allowed to specify *which* printer he wants as a reference device and not just the default printer? That way I could check the list of installed printers and avoid any HP's.

What I would really like most of all is a simple way to simply specify a page size and a resolution (300 or 150 dpi) and not needing to bother with reference devices at all. That way I can lower the DPI if the page size gets too big. I'm more or less stuck with mm_anisotropic because the class library I use relies on that. BTW, both Adobe and CutePDF work fine without needing reference devices and offer me various resolutions. How do those guys do it?

[/b]

Hello all,

I need to produce high-resolution graphics. I use WPDF in HDC mode and because I need high resolution and large paper sizes I use pdf.CanvasReference := wprefprinter.

Unfortunately, this causes problems if the default printer happens to be a certain type of HP color laserjet. Lots of graphic objects are simply missing on the pdf page. It works correctly when the default printer of the PC is of a different type (such as Canon or Epson inkjet printer).
This is a huge problem for me because all people in our company have a HP laserjet as their default printer. So do many of our customers, I get bug reports all the time.

I know that HP Laserjets have an issue in their drivers that affects Delphi applications in general. More precisely, they change the floating-point coprocessor control word (see Delphi function set8087cw()) which can cause haphazard crashes and unpredictable behaviour in programs compiled with Delphi and Cbuilder. The bug is known to Codegear/Embarcadero (see Codecentral for a more complete description and a workaround).

I wonder if WPDF is suffering from this same particular issue?

Anyway, I desperately need a solution or a workaround.

Screenshot of the buffer overrun/GPF in WPDFDEMO sent to your E-mail address. Maybe it happens only on Vista?

Hello mr Ziersch,

Yes, the pages are huge.

But this is precisely what my customers (on oil well sites) want.
They really want ONE SINGLE continuous page with NO page
breaks and complain bitterly because I can't deliver that yet.
They get similar logs from other companies and want to compare
them side-by-side on the screen and make annotations in these
logs using Adobe Acrobat. Also, the logs are printed on huge
Hewlett-Packard inkjet plotters that handle this page size (5 metres
or so) with ease.

I realize that PDF has a 32k limit in its coordinate space but at a lower
resolution of 72, 96 or 144 dpi that should easily give me the 5-6 m
I need. The advantage of PDF (and EMF) is that the font resolution is
independant of the graphic resolution so the fonts come out OK even
at a lower graphic resolution.

By the way, the freeware printer driver CutePDF can do all of this!!!
I can produce HUGE plots using CutePDF and the resulting PDF files
are only 6 mb or so and display fine using either Adobe or Foxit PDF.
But I'd rather do it using WPDF (because in that case, I can calculate and
set the page size automatically. In CutePDF, the user has to set it manually).

Your idea of rendering the page as one huge bitmap and feeding it to WPDF
is really not feasable because it has two side effects:

1 - the customer cannot select and copy text from the pdf

2 - I would have to INCREASE the resolution to 300 DPI to make the fonts look
acceptable on the printout. The file would be huge and I would hit the 32k
limit of the coordinate system after only 2.5 metres.

I would be grateful if you would fix the buffer overflow/gpf in WPDF.
A page size of a dozen megabytes or so is really no problem for today's computers.

Hello Julian,

I am aware of the high-res mode (IIRC it divides the coordinates by 10, which would give me only 60 dpi since my reference printer has 600 dpi) .
However, I really need as many dpi as I can get, therefore I'd rather use the 96 dpi which the screen hdc gives me. A maximum size of 320" is just about right for me (oil well graphic, drilled 6000 m deep, scale 1:1000) .

I'll try and produce an EMF plus test application which I can send you.

(using latest WPDF 3.31 version)

I am currently experimenting with VERY large paper sizes in WPDF.

The document I am currently creating is roughly 18000x1100 units. The contents are very complex. I use the screen's hdc (96 dpi) as reference for the canvas because I read that the PDF coordinate system is limited to 32000 units. It is not nice, but if it really has to be, I can live with the small resolution.

However:

Upon calling wpdf.endpage, I get the following general protection fault:

[3484] Zugriffsverletzung bei Adresse 04D838A6 in Modul 'wpdf300a.dll'. Lesen von Adresse 05B2E248 (4536)

Hello all,

I have to print very long graphics (oil well data, having a total length of 5 - 10 metres).

I am having some frustrating problems achieving two "simple" things.

The output has to look "continuous" to the user, either by displaying the pages in continuous mode (without whitespace between the pages in Acrobat) or alternatively by setting huge paper sizes.

(1) If I set a relatively small paper size (DIN A3 or A4), how do I tell WPDF that Acrobat should display the pages in "continuous" mode so that the user can scroll through the pages as if it were one huge plot ?

(2) Is it possible to set very long paper sizes (30 cm x 5 m) ? All my attempts so far result in WPDF hanging or causing GPF's in NTDLL.DLL. In the original Acrobat printer driver I can get pages as long as 3 metres but not in WPDF.

I am using WPDF 3.31, by the way.

I've just sent you a demo application by mail, demonstrating that wpdf will not correctly print Hebrew and Persian text contained in a trichedit.

Hello mr Ziersch,

is there a demo version of version 3.10 available? I downloaded WPDF3DEMOSETUP.EXE today, but it contains an outdated version 3.0.7.9 of the DLL that is still very unsatisfactory with regards to foreign fonts.

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.

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?

Thanks, I'll try that.

But it puzzles me (I am logged on as admin, and hkey_current_user is always readable for the current user anyway)

Hello all,

I'm currently evaluating the trial of wpdf but nothing will work. I installed wpdf in the directory "d:\delphi\wpdf" and compiled and installed the package successfully in my BDS 2006.

When I compile the "standalone" demo and start it, it throws the following exception:

The dll "{hkcu}\Software\Wpcubed\wpdf\3.0\path" was not found.
PDF Export is not possible.

Using regedit, I verified that a valid path to the dll is present in the registry. Copying the dll into the directory where the executable is located didn't help either. Nor did copying the DLL to c:\windows.

What can I do to test it?