Beiträge von winpple

I cannot load the DLL to attempt testing the product. Am I hitting a limitation of the demo where the demo dll cannot be loaded except by the official demo executable ?

They apparently don't.
I produce a PDF file using some Type1 fonts (.pfm/.pfb), and this font is embedded in the pdf, according to the pdf library used.
The resulting pdf file is displayed correctly on Adobe Reader 8.1, in Foxit Reader, and on Mac OS X in Preview, but it looks like a complete mess with wpViewPDF.

Is this a limitation of the evaluation version?

I will change that program to use the evaluation version of wpPDFControl and I will report if I get better results or not.

Ok found the answer. wpcubed has no license to redistribute those fonts but the component can use them if they are available as .pfb files. command 136 "setfontfolder" can be used to point the component to the right location.

I suppose I now have to check with Adobe how much it would cost me to distribute these with my own application.

Okay, found what happens.
It is not possible to:

LoadLibrary();
Create a windows of class WPCubed_PDFVIEW_Demo_01
Use it (success)
Close/Destroy the window
FreeLibrary()

then start again:
LoadLibrary()
Create a wind... bang! crash processing WM_NCCREATE inside the DLL.

I have worked around it by calling LoadLibrary once at start of executable. It deserves a fix anyway, I think. I can test an updated build if you like, when you're ready.

I can add that it looks like always on processing a WM_NCCREATE. It does not *always* happen, but often, and most of the time when I create a new viewer after having closed a previous one. When it happens it is while the DLL Wndproc is processing a WM_NCCREATE message.

Using the demo version of the dll and creating windows of class "WPCubed_PDFVIEW_Demo_01" from a single executable, often, after a first window had been created, showed, used and then destroyed, a second CreateWindowEx crashes in wPDFViewDemo02.dll!119fea60().

Is there any demo-related limitation or mechanism that could interfere with successfully creating a viewer, closing it, re-creating a new one ? (My app opens a window to show a pdf - just built on the fly -, then the user close the window and a new window can re-open to show a new pdf.

Thanks,

Don't get me wrong, I like your product and I'm *very* close to commit myself on it. But I had to dig in multiple places to get a view of native dll interfaces. Creating a window in pure Win32 model (Petzold style) with your dll is easy. Just need to know the class name and then it is only a matter of finding the right messages to send or expect to / from the window to interact with it. Short of a minor detail which I'm still debugging today, I could even build a control class in MFC which encapsulate pretty well the visual control.

But I had to dig in your C# interface to find most of my answers. Maybe the documentation might see some improvements in a future version. Again don't get me wrong, I'm mostly impressed with what I have seen.

Is it solely for the purpose of keeping the main dll smaller? Are there other factors?

Yes, I'm evaluating the product and considering the delivery/setup issues.

Licensing issue or technical issue?
It's small, I guess everybody would prefer to have it always than optional.

--
Olivier

Hello,

If a pdf is built with a tool which references the common fonts Courier, Courier-Bold, italic versions, Helvetica, Times Roman and one symbol if I remember well, is the viewer able to properly display those fonts (not embedded in the pdf) or not ?

In an external reader like the one of Adobe (of course) but also in some others (Foxit on windows and Preview on Mac), those fonts display just well. It looks they are mapped to anything else with the viewer. Is this by design (those fonts descriptions not embedded in the viewer dll)? A bug of the component or some I might have done wrong?

--
Olivier