PDF XChange Forum

johnr@etakeoff.com

I have a file where 2 pages display very slowly using the SDK. The file is 9.7 MB so I can't upload it. The same pages display almost instantaneously in Adobe Reader and other PDF viewing applications. Is there any way to get it to you to look at? It's available here: http://eTakeoff.com/downloads/P...

johnr@etakeoff.com

I'm getting watermarks when I use the functions PXCp_InsertPagesTo() and PXCp_WriteDocumentA()

Should I be passing different arguments to PXCp_Init() than I pass to PXCV_Init()?

johnr@etakeoff.com

After further exploration it looks like what we need is just the core layer. When will that product be available.

BTW, the editor is no faster that the current DLL.

A sample file it attached.

johnr@etakeoff.com

At first glimpse. it looks like the editor uses it's own window. Can it be used to display a PDF file in different window the way the Simple DLL does?

johnr@etakeoff.com

We're using version 2.5.312.1. We're seeing slow display times on some files that display very quickly in Adobe. Is there any improvement in this from version 2.5.312.1 to the latest version 2.5.315.0?

johnr@etakeoff.com

The view posted doesn't seem even vaguely related.

But I think the XCPRO40 Text Extraction methods will do what I want. It took me a while to figure out that the matric contained the coordinates. (That's explained in the documentation but I missed it.)

Thanks.

johnr@etakeoff.com

I'm asking how to do it programmatically, using the SDK.

Since my original post I found the text extraction methods in the XCPRO40 library. It appears they would let me search for the text. But I don't see how to determine where the text would appear on the page so that I could highlight it.

johnr@etakeoff.com

I'm not sure which forum to post this in.

We would like to search documents for keywords then display pages with the keywords highlighted.

Is there a way to search, then get the document coordinates for where matches are located? Then we could do the highlighting ourselves.

johnr@etakeoff.com

It happens on several different printers. Personally I've had problems with the CutePDF print driver and with an Epson WF-3540 printer.

johnr@etakeoff.com

You can get it here:
http://etakeoff.com/downloads/eTakeoffPrintProblems.pdf

johnr@etakeoff.com

I have a particular multi-page PDF file that displays fine but when I try to print it, the call to CDC:EndPage() returns -1 ( a general error). If I comment out the call to PXCV_DrawPageToDC(), EndPage produces no error. In one of your code samples I noticed calls to release the cache between DrawTo...

johnr@etakeoff.com

OK, I'm an idiot. I relinked but forgot to change out the DLLs so I was still running with the old pxcview.dll. Sorry to waste your time.

johnr@etakeoff.com

Well, now I'm baffled. I compiled and ran your example pxcview36_sample_app and it displays correctly. I checked the parameters I pass to PXCV_DrawPageToDC and they're the same (except for the rectangles) I checked the call to PXCV_Init() and even plugged my licensing stuff in but still it's fine in...

johnr@etakeoff.com

I downloaded the latest just now. The problem still exists in the SDK.

Look at page 5. The upper right plan is not displayed
(above ELECTRICAL ENLARGED PLAN - TYPICAL SUITE)

Also on Page 1, the upper-left logo looks different than in the Adobe Viewer

johnr@etakeoff.com

It's 17MB so it probably won't work via email either.

You can find it here: http://etakeoff.com/downloads/DisplayProblem.zip

johnr@etakeoff.com

Here are the zipped files.

johnr@etakeoff.com

Three files are attached:
- The PDF file
- An Adobe screen shot
- An SDK screen shot

johnr@etakeoff.com

Has this been fixed yet?

johnr@etakeoff.com

I have a file where some parts that display fine in your viewer and Adobe Reader are blank when displayed in our application using the simple DLL. I have downloaded the latest versions. The file is available here: http://etakeoff.com/downloads/DoesntDisplayViaSDK.pdf The missing part is in the upper...

johnr@etakeoff.com

Any progress?

johnr@etakeoff.com

The problem is still present in 2.5-200

johnr@etakeoff.com

When calling PXCVDrawToDC with the pxvrpf_UseVectorRenderer option, the attached file, the function just hangs.

johnr@etakeoff.com

Just downloaded and installed it. It fixed the problem. Thanks.

Is there any place to subscribe to get notices when a new release is posted?

johnr@etakeoff.com

Is this fixed in 2.5.199?

We're getting majopr complaints from our end users on this problem.
http://forum.etakeoff.com/topic/time-delay

johnr@etakeoff.com

Any update on when the next version will be available?

johnr@etakeoff.com

Any estimate on when version 3 might be released?

johnr@etakeoff.com

void CRViewImgPdf::Draw(CDC* pDC, const RECT* pRectDst, const RECT* pRectCrop, UINT nFlags) const { PXV_CommonRenderParameters dp; HRESULT hResult; double dblMult; RECT rectPg; RECT rectDraw = *pRectDst; dblMult = ((double)(pRectDst->right - pRectDst->left)) / ((double)(pRectCrop->right - pRectCrop-...

johnr@etakeoff.com

When the user moves from one page to another, we call it on the previous page:

PXCV_ReleasePageCachedData(m_doc, nPgRelease, pxvrcd_ReleaseDocumentImages);

The slowness we're seeing happens even when zooming and scrolling on the same page.

johnr@etakeoff.com

I'm not sure that's the case we're seeing. I would expect you to decode them once when you load the page. We're seeing each screen refresh be slow as we pan and zoom.

johnr@etakeoff.com

We're using the simple SDK rather than the ActiveX. I don't see anything on MemUsage in the help.

We're already using PXCV_ReleasePageCachedData.

johnr@etakeoff.com

I'll work on getting more information about the systems where we see this. We're using the SDK. How can I use that to do the equivalent of "changing the memory allocated from Automatic to 50%"? You say "scrolling backwards is immediate". Does that mean you're cacheing all viewed ...

johnr@etakeoff.com

We're seeing PDF files containing large bitmaps display much more slowly with the PXCView SDK (0r the PDF XChange Viewer) than with Adobe. The problem is particularly bad with older CPUs. The file below displays in about 1 second in Adobe but takes nearly 10 seconds with PXCView. http://etakeoff.com...

johnr@etakeoff.com

Thanks to all.

I already had banding logic so it only took a few minutes to make sure no band was more than 4M pixels (128MB). The result was that what previously took 28 seconds to generate now takes less than 5 seconds.

I greatly appreciate your assistance.

johnr@etakeoff.com

Thanks for all the information. I'd always wondered why your viewer was blindingly fast when drawing to the screen but a dog when drawing to a large bitmap. Now I know. Yes, I know that a TIFF file is a bitmap. I'm not an idiot. What I didn't know was that you draw to an internal bitmap then draw th...

johnr@etakeoff.com

You're saying that whenever you draw, you draw to a bitmap first, then bitblt that image to the DC?

That would explain A LOT.

Any way to turn that off - other than the banding.

johnr@etakeoff.com

What you're saying is not true in our case. To create the TIFF file, we create a monchrome bitmap, select it into the DC, draw and save it as a TIFF file. There's no 32 bit bitmap. To make sure, I ran our application on a pdf file that was 18x24 300 dpi. By your calculation this would be 311 MB. By ...

johnr@etakeoff.com

Actually, because the bitmaps are monchrome, it only requires 24 MB per bitmap (30*40*400*400/8). That's not much memory for today's machines. Back in 1996 when we started it was a serious challenge, even at 200 DPI.

johnr@etakeoff.com

We generate large 30"x40", 400 DPI, monochrome bitmaps. But let me dig deeper into this before I use any more of your time. My preliminary investigation indicated a possible multi-threading problem but that may not be the case.

Thanks for your help.

johnr@etakeoff.com

I'm aware of all the issues with writing to a large bitmap. We do that regulalrly and it typically takes 10-20 seconds. What we're seeing here is quite different. It's easily 50 time longer. But you've answered my basic question that it should be multi-thread safe. I'll dig into it further. BTW, we ...

johnr@etakeoff.com

You say to use one of your example apps. Can you suggest one? I'm not really familiar with them.

johnr@etakeoff.com

That's a possibility. (If it happens with a cooperative customer.) Would your viewer be an appropriate application? It may be a few weeks before we run into it again.

BTW, next time we run into a REPEATABLE crash, I'll pass that file along.

johnr@etakeoff.com

We have an application to generate TIFF files from PDF files/pages. It uses three threads. The main thread displays the current page for the user to view. A second thread opens the next file/page in the background. After the user enters some information, a third thread generates the TIFF file by wri...

johnr@etakeoff.com

We are using the simple viewer DLL, not the ActiveX. Recreating this is nearly impossible. It happens on a customer's system, but when we transfer the PDF file to another system (or reboot the system), everything works fine. I'm not even sure it's a PXCView problem. The crash happens in pcxview.dll ...

johnr@etakeoff.com

We're seeing this on the viewer SDK. I'll have our support staff grab the file on the next example.

johnr@etakeoff.com

We're seeing behavior that I want to report in case others are seeing it. Sometimes our application crashes while opening a file withe the viewer library. Usually this is because the PDF file is corrupt. But somtimes we find that the file is fine. The problem goes away if the system is rebooted. My ...

johnr@etakeoff.com

WOW! Build 189 sure fixes it.

The display time went from 41 seconds to less than 3.

Also, the speed of converting to TIFF by drawing to a large bitmap has been improved by 400%-500%.

You guys are AWESOME!

Thanks.

johnr@etakeoff.com

Page 3 is the one that displays slowly.

johnr@etakeoff.com

We had reported this problem in earlier versions of the SDK and we're told it would be fixed in version 2.5. It's not. We run in to this from time to time where a page will take over 30 seconds to display. I have an example but it's too big to attach (6 MB). You can get it here: http://www.etakeoff....

johnr@etakeoff.com

Unfortunately I'm using the simple DLL viewer SDK. But I don't make any changes to the PDF file through either the toolkit or the viewer SDK. Here's what I'd like to do: - Open the file in the viewer - See if it has multiple pages (80% won't for the files we deal with) - If multiple pages: - Open th...

johnr@etakeoff.com

The header files I'm referring top are those in "C:\Program Files\Tracker Software\PDF-XChange Viewer SDK\Include" and "C:\Program Files\Tracker Software\PDF-Tools 4 SDK\Examples\Include". All those in the viewer folder reappear in the Tools folder. They're identical today but wh...

Search found 54 matches