Streaming XOD Questions

[David Collins]

I am using custom file encryption on PDFs residing on my webserver, and I would like to avoid having to keep a separate store of XOD files. I have tweaked the streaming sample in the .NET SDK to load the decrypted PDF from memory stream into a PDFDOC, then create the XOD in memory from that. That works for the most part; however with larger PDFs, later pages never seem to display in the WebViewer control.

I read somewhere in another post that I should be using a StreamingPartRetriever. Perhaps that would resolve the issue with larger PDFs.

Beyond that, I also have the requirement to work with annotations, so I believe I need to be using the ReaderControl (?)

Is there an example of how to use the StreamingPartRetriever with the ReaderControl, or could you provide some sample code?

Thanks in advance,
David Collins

[Matt Parizeau]

Hi David,

The nature of creating and streaming the XOD file in memory obviously means that it will be slower than loading a XOD file that had been converted ahead of time.  We've found that with large files streaming can take a long time to load the entire document and it may seem like the later pages never come in when in actuality it is just taking a very long time.  When you're running the sample with a large file that doesn't seem to load can you look at the Visual Studio output and see if you're continuing to receive debug messages saying "Server sent total xxxxx bytes" and eventually "Done".  If it eventually finishes sending all the data and WebViewer still doesn't display later pages then it may be an issue with the WebViewer and we can look into it more.

One alternative to this is to effectively have a XOD file cache on your server.  The first time you receive a request for a document you could convert it to XOD, save it to an actual file and then set the WebViewer initalDoc to that location and streaming to false.  The next time that file is requested it could be served straight from the cache.  You could then periodically remove files from the cache when you've reached some predefined limit.  One thing to note is that when "streaming" is set to false in WebViewer that does not actually make the file loading slower as we can then request parts of the file using byte ranges (assuming your server supports it).  As a user scrolls through the file we can just request data for the parts that we need making for a much faster loading time.

As for your other questions, the sample is already set to use the StreamingPartRetriever because we pass in "streaming: true" as one of the options when creating the WebViewer control.  WebViewer is automatically using ReaderControl behind the scenes so you don't have to worry about that.  If you wanted to do heavy customization then you could edit ReaderControl directly but for most cases this isn't necessary.  If you want to enable annotations then you can include "enableAnnotations: true" in the options object that is passed in.  After doing that you'll find a fourth tab in the side panel that will allow you to work with annotations.

Matt Parizeau

Software Developer

PDFTron Systems Inc.

[David Collins]

Matt,

Thanks for your reply.  Sorry for the confusion on my part.   I like the idea of a XOD cache, so I reworked things and am having better luck.  Small files load very quickly, however the quality from the XOD conversion is poor.  Images and text are grainy and barely readable.  I'm still running in trial mode, is that a limitation?  If not, is there a way to increase the quality of the conversion?

I'm having problems getting the larger files (> 40MB) to XOD.  Depending on which file a load, I get PDFNETExceptions at the same point in the process each time, either when trying to create a PDFDoc from memory stream or attempting to save the XOD file to disk.

I've attached some screen caps for you.  Any suggestions?

Thanks,

David

[Matt Parizeau]

Hi David,

From the screenshot it looks like only the scaled up thumbnail is being shown so something is probably failing.  Can you open the developer console and check to see if there are any errors.  If possible could you send us the XOD file as well.

As for the exceptions, from your code it looks like you're saving the decrypted pdf?  Do the issues occur when you try to convert that saved file to XOD instead of using the PDFDoc?  If possible could you send that PDF file so that we could test it out.  If you'd rather not have it available in a public forum then you can email it to mpar...@pdftron.com.

Matt Parizeau

Software Developer

PDFTron Systems Inc.

[Support]

 

To rule out that you are not using outdated version of PDFNet/DocPub could you please try one of the following:

 

http://www.pdftron.com/ID-f94ls2-edm0aqZ/docpub.zip
http://www.pdftron.com/ID-f94ls2-edm0aqZ/PDFNetDotNet4.zip
http://www.pdftron.com/ID-f94ls2-edm0aqZ/PDFNet64DotNet4.zip
http://www.pdftron.com/ID-f94ls2-edm0aqZ/PDFNetC.zip
http://www.pdftron.com/ID-f94ls2-edm0aqZ/PDFNetC64.zip Show trimmed content

 

In you need Linux, Mac tools please contact support for the latest unoffical version.

 

[Support]

FYI:

 

Besides streaming doc conversion via PDFNet SDK (see WebViewerStreaming sample http://www.pdftron.com/pdfnet/downloads.html) 

 

you can also stream via DocPub command-line utility ( using '--console_out' oprionl; e.g. docpub --console_out -f xod my.pdf > my_response_pipe etc).

 

 

[Support]

 

The following discussion on different part retrievers comes from WebViewer Silverlight clinet (i.e. SilverDox) but may be relevant since it provides a decision tree to pick match the part retriever with how things are done on the server side:

 

   http://www.pdftron.com/silverdox/documentation/html/429caea2-50aa-401d-8c9f-d58510dca752.htm 

[Support]

Although streaming seems attractive on first look it could put a heavy burden on servers (e.g. if there are many users viewing docs at the same time). A more efficient alternative is to cache converted XOD files. You can either do either a full mirror of the entire library or partial cache (e.g. storing last 1000 files or something like that). 

This will remove the strain from the server and will also improve viewing experience (better performance, instant access to random pages etc.).