ViewerAX SDK versus DLLs

[jeffp]

In our application, we currently use both the ViewerAX and your SDK DLLs to manipulate PDF files. We use the DLLs with non-visual manipulations when we don't need to load the file in a viewer, like just selecting a file and then appending, extracting, unstacking pages, etc.

It occurs to me that we could just use another instance of the ViewerAX to do the same things. However, I wanted to get you input on which way we should proceed given the new major releases of both the ViewerAX and DLLs that will be out soon.

Is the code in the SDK DLLs actually the same code the the ViewerAX uses? In that case, maybe it doesn't make a big difference whether I take a DLL or ActiveX approach. I've always tried to avoid going through an ActiveX layer in the past if I didn't need to.

I have noticed with the current code, there are some things I can do in the DLLs that I can't do in the ViewerAX, and vice versa. How will this change in the new releases.

Any thoughts or direction on this issue would be helpful as we plan the next release of our product.

Thanks.

[John - Tracker Supp]

Hi Jeff,

I would suggest you wait for the new releases - particularly V3 of the Viewer before making any major code changes to existing operations. Version 3/5 of these products will share where possible common libraries and will for the most part be build as sort of 'layers' with a low/medium/higher level API that we will use to share common code and functions.

For example whereas now if you want to make 'virgin' new PDF files using our libraries you use the pxclib40.dll library and functions - and for modifying existing files you use the xcpro40.dll library or Viewer SDK, the xcpro40 and pxclib40 equivalent libraries will share common functions and where logical and allowed by the PDF format spec - you will be able to perform operations on a new file that previously required a save and then use of xcpro40 - this will now not be the case, you can just continue or pass a stream etc.

There will still be items better performed in the libraries rather than viewer and vice versa - but it will be much less arduous and difficult and code will be far more easily reused etc.

However the drawback is - it will take a little rewriting of your app most likely to take full advantage of these benefits.

So for now - I would hold off until both the new library and viewer SDK's are released and look at how to rework then.

Hope that helps

[jeffp]

Thanks John. That's wise counsel.

In this regard, do you have an estimate of when the new libraries will be ready.

[John - Tracker Supp]

Hi Jeff,

I am afraid I cannot for now - we are very close to being able to provide more detail on dates as we have pretty much nailed the detailed feature list and finalized as the coding has reached an advanced stage - but the exact dates has not been finalized.

I can tell you that the driver will be the first product released - then the libraries and finally the Viewer SDK as this is reliant in large parts on the Library products functionality and sits above this layer in hierarchical terms.

Much of the new library code has already been developed and has been in use in the Viewer SDK (for existing functionality) and therefore in logic and efficiency terms is tested and proven - and has allowed us to prove conceptually that what we want to do is possible and reliable - we now have to take that back several steps and include in the lower level products for use throughout the products where applicable.

I know thats not as full an answer as you may wish - but hopefully gives some insight.