Q: What is preventing PDFNet from being written as a dll that can be consumed directly by a Silverlight application and running on the Silverlight client? We are using PDFNet and Silverdox in an enterprise application where we expect to have several hundred concurrent users. I feel the biggest issue we have right now is the fact that we expect to have some very large PDFs that the user will be editing (moving pages between PDFs, rotating pages, reordering pages streaming, etc) and the fact that we have to keep passing these large byte arrays across the wire. If we could be doing all the processing on the client our performance would be much better.
We are taking a look at PDFNet WPF control (PDFViewWPF -
http://www.pdftron.com/IDR49Z9-B31B/PDFNetDotNet4.zip), but I wonder why is PDFNet DLL not available as a Silverlight assmembly?
A: PDFNet has some requirements (security, temp files, memory, threads, etc.) and dependencies (on image compression, rasterization, WPF, etc) that would make it really difficult (and painfully slow) to run under Silverlight.
In case you need more processing power on the client side, you could use PDFNet SDK (e.g. for WPF). The main disadvantage of this approach is that resulting app would need a higher permission to run (compared to Silverlight browser app).
At the same time it should be possible to architect a SilverDox solution that is highly scalable and does not require constant back and forth conversions.
Basically we are seeing that the majority of our time is spent “on the wire”
I am not sure how your current app is designed, but in case you are constantly converting and streaming from PDF, it is probably not very efficient and scalable.
Ideally you would cache XOD on the server side. This mean that any subsequent request for viewing/editing would be immediate. Also, because you would use random access PartRetriever instead of streaming PartRetriever you would drastically cut the network traffic.This means that only parts of the document that are being viewer would be transferred over the Web. This approach would also be much more effective than sending the entire PDF back and forth (i.e. the clinet only solution)!
I am not sure how you are currently implementing editing operations in your app, but an efficient approach would be to send changes to PDFNet server (e.g. as custom XML; similar to how annotation handling is implemented in SilverDox - http://www.pdftron.com/silverdox/samples/AnnotationsTestPage.html). A lazy, server side batch process would consume incoming XML files, perform editing on the original PDF, and then update the preview.
Btw. we about to release a new version of SilverDox (which will be rebranded as PDFNet WebViewer), which initially also support HTML5 (desktop/mobile), followed by Flash frontend. For HTML5 viewer beta (desktop version) preview please see: