Acroform Field Data Extraction

[DolphinMann]

I was looking for some help on this as I could not find anything in the example files provided.

I can use the PDF X-Change viewer application to extract the Acroform Field data into and FDF/XML file from the file menu, but are there any examples on executing this via code?

Edit: I have found how to create Acroforms, but not simple read/export them.

[Ivan - Tracker Software]

You can run JavaScript code into Viewer AX to export your fields to FDF/XFDF files (please take a look at doc.exportAsXFDF, doc.exportAsFDF, etc. methods in JavaScript for PDF reference).

[DolphinMann]

So the only way to do this is view the viewer SDK which has the additional licensing restrictions? There is no way to do this via the PDF SDK library at a service level?

Edit: It also seems that the PDF Viewer AX Library is not part of the Full SDK PRO download, even though it is listed as part of the complete PRO SDK Package. I had to download it separately.

[Ivan - Tracker Software]

The only alternate method to get form fields and their value is to use Low Level API in PRO SDK, but it is too complex because you will have to create own export fields enumerations and export routines.

[DolphinMann]

I have been playing around with the PDF X-Change Viewer SDK as you suggested and I've found the AcroForm/JavaScript demo.

I can run the demo, pass in the correct javascript and get XML string as a result....now to convert this feature in to my application!

The problem is that my application has no Forms or Controls. It is a windows service that can, among other things, read a PDF and create an XML file from the Acroform/FDF data.

I am using the following technique to create the PDF X-Change class, but I continue to get a null pointer exception with on the open document line when it seems to try and locate the windows form.

Thread thread = new Thread((ThreadStart)
delegate
{
pdfDocument = new AxCoPDFXCview();
pdfDocument.CreateControl();

pdfDocument.OpenDocument(this.FilePath, "", out pointer, 0);

pdfDocument.RunJavaScript(ACROFORMSCRIPT, out returnValue, 0, 0);

Application.Run();
});
thread.SetApartmentState(ApartmentState.STA);
thread.IsBackground = false;
thread.Start();


I'm a bit confused as this technique will work for loading and using other ActiveX controls without requiring a windows form. I really can't have a form or GUI in the application and I would prefer not to launch a hidden window if at all possible. Do I have any options here beyond digging into the low level API just to output the FDF/XFDF?

[Vasyl-Tracker Dev Team]

Hi, DolphinMann.

No way to use our ActiveX Control without GUI, without parent-form on your side. Our control is windowed object that is developed by standard microsoft's technology as simple ActiveX Control and requires normal host-object(your form for example) to be placed into it.

Best
Regards.

[DolphinMann]

Are there any plans to be able to call insert javascript function or do a simple AcroForm export, as we can in the PDF X-Change Viewer, through a non-windowed control outside of using the Low Level API?

[Vasyl-Tracker Dev Team]

Hi, DolphinMann.

Are there any plans to be able to call insert javascript function..

I'm not sure that is technically possible because JavaScript Object Model requires the normal windowed pdf-control as its environment.

..or do a simple AcroForm export, as we can in the PDF X-Change Viewer, through a non-windowed control..

It will be possible only by our new Editor's SDK (upcoming), please wait..

Cheers.

[DolphinMann]

What is the timelime for the Editor SDK? And will those of us who have already purchased and pay maintenance on the PDF X-Change PRO SDK(full version) have access to it?

[John - Tracker Supp]

As posted on numerous previous occasions ...

Being perfectly honest - it is not likely this will be addressed in the current Viewer products as it would take a considerable effort to add such functionality to the Viewer and is one of the reasons the entire codebase required to be rewritten as it has been with the Editor.

As far as the Editor SDK goes - it is largely completed - what is not yet completed (and requires perhaps 3 months to bring to fruition by 2 experienced team members) is the documentation and the examples and regrettably the reality of things as they stand are; that we achieve some 80-90% of our revenue from NON developer SDK products - but adding developer functionality and all the additional elements represent around 80% of the work and thus the pure hard economics of the situation is that until we have reached a fundamental point of functionality in the current range of end user products we cannot take staff from this to attend to completing the outstanding developer SDK items - so it is a little way off yet.

We are aware of the 'pent' up demand from our developer clients and will attend to this just as soon as possible.

There will be a means to upgrade to the Editor SDK from any previous versions - but the license terms and ongoing costs are likely to be modified to reflect the following;

1; Very few of our Viewer SDK clients seem to exceed the imposed limits before additional CDLP licenses are required - considering the PDF-Tools/Driver/PRO SDK distribution limits are set between 2500-7500 client installations, so we are drawn to one of 2 conclusions, very few developers are actually distributing their app's to more than a few 100's of clients - or dev's are just not being honest in what they distribute.

2: The cost of maintaining and supporting developer clients to a standard we wish to offer and developers wish to receive with the Viewer SDK and allowing us to devote sufficient resources to continue to develop such a product is clearly not met by the revenue we are receiving - we are having to 'underpin' the SDK sales with End user product revenue.

The above means we cannot devote sufficient resources to both end user clients and developers to proceed with product development as fast as we would wish and obviously our clients too and it is unrealistic for us to continue to support developer products with end user revenue and also to stifle our development on End User products where the bulk of our revenue is generated.

So to be blunt - developer's will be expected to pay a higher price for the products offered to ensure we can fund support and development without comprise. I expect to be able to offer a firmer idea of dates and costs during October - as we are currently actively recruiting new staff for new development location we expect to open in Vancouver this autumn.