Q:
1) Does your SDK provide UI customization? For example, in your sample, can we customize the icons in the PDFViewCtrl class? Another example is can we instead of using long press to popup the annotation options, we would like to use a set of buttons instead.
2) What is the max support file size?
3) Zoom option, I noticed that there is a api to set the zoom. Can we use gesture to perform zoom in/out on top of PDFViewCtrl class?
4) Does your sdk support encrypted pdf, iOS data protection, NSData object, etc?
> 1) Does your SDK provide UI customization?...
Yes, the UI is completely customizable, including the icons used in the sample app. You are also able to change the control's response to user input, including changing the response to a long press and building a toolbar to change tool modes instead. Please see this forum post for more information.
> 2) What is the max support file size?
There is no explicit upper limit on file size other than what the iOS file system can handle.
> 3) Zoom option, I noticed that there is ...
Yes, if you run the included sample application you will see that the standard pinch gesture can be used to zoom. You are also able to implement zooming in response to other gestures.
> 4) Does your sdk support encrypted pdf, iOS data protection, NSData object, etc?
Yes, our SDK supports encrypted PDFs. If you open an encrypted PDF document with the sample app, you will be prompted for a password that must be entered correctly before the document will display. If you want to save a PDF document using iOS data protection, you can use the PDFDoc selector SaveToBuf: to save the document to a NSData object, which you can then save using iOS data protection.
> 5) What is your licensing model?
Licensing information can be found on our website here: http://www.pdftron.com/store/index.php?gotoPage=pdfnet.html
I have just a couple of more questions for you.
1) when I zoom in, is there a way to have a scrollbar? So, it gives feedback as to where we are in the page.
2) Integration - We are evaluating a PDF annotation library to integrate our ipad application that upload/document pdf documents from a cloud storage securely.
a) For protected documents, does your APIs write anything to a disk or just in memory?
b) Can we stream a pdf document (protected or not protected) through NSData to your SDK?
c) After annotation of a document, do you provide APIs to save the modified version to a remote site through webservice, REST or other methods?
Re 1) As the control is based on a UIScrollView, this is essentially an iOS issue. After you zoom in, you should see the scroll bars flash momentarily, indicating where you are in the page. When you are scrolling the page (i.e. tracking), then the scroll indicators are also visible, indicating where you are on the page. I don't believe iOS provides any method for persisting the scroll indicators on screen when not tracking.
Re 2: Currently PDFNet does not write anything to disk during read/view operations. Data is written to disk only during create/edit operations (which may be the case in the demo version which stamps pages with demo watermark). This can be changed with PDFNet selector SetDiskCaching:NO so that everything is stored in memory (even for create/edit operations).
Re 2b) It is possible to create a new PDFDoc from NSData. Regarding streaming, we are currently working on a downloader that will open and stream a linearized PDF via a http and https connections directly into the viewer. It is not though streamed via an NSData object. Is that an important aspect of your program? One thing to be aware of is that many (most) PDF documents are not linearized, that is the data is not saved in the same order as the pages appears, and so would need to be re-saved (for example with PDFNet using the e_linearized option) before streaming.
Re: 2c) There is no built-in support for saving changes in a
document to a remote site. However, we do provide programmatic access
to all aspects of a PDF, including annotations, so it would be possible to
implement your own annotation serialization method, and send it to a web
services powered by PDFNet to update the PDF in question. For a sample of
iterating through all annotations in a document, please see the Annotations
sample online on our website here: http://www.pdftron.com/pdfnet/samplecode.html#Annotation
Q: I would like to have an annotation toolbar like the Acrobat or iAnnotate instead of using long press on the screen to popup the toolbar options. one issue I found is that if I select "hand free" annotation, one my finger is touch up, it stop the "hand free" drawing and I need to long press again to get the toolbar to continue my drawing.
It is certainly possible to create this sort of toolbar using the PDFNet SDK. As mentioned previously, the control's response to user interaction is implemented in the library libTools.a, and the source code for this library is provided to customers. Let me briefly explain how the tools library works. The main PDF viewing control, PDFViewCtrl, has a tool property, where a tool is defined as a class that conforms to the ToolDelegate protocol defined in PDFViewCtrl.h. When a PDFViewCtrl receives an event, it passes the event data to its tool so that the tool may respond in some way, for example drawing a line or selecting an annotation that already exists. Each main "interaction mode" is implemented as a separate tool, such as one tool for creating ellipses, another for freehand annotations, another for editing existing annotations, etc. With the source code to libTools.a, you can alter any existing tool, or create entirely new ones.
Now that I have hopefully explained how "tools" work, you can see that switching tools is just a matter of assigning the correct tool to PDFViewCtrl's tool property. This could be done in response to a toolbar button press, e.g.
[pdfViewCtrl setTool:[[[LineCreate alloc] initWithPDFViewCtrl:pdfViewCtrl] autorelease]]
or
I have noticed that the library footprints is high. Are you able to provide alternatives that would reduce the footprint?
We could probably shrink the size down to ~4MB. Decreasing file size below 4 MB is probably not technically feasible without loss of core viewing functionality (e.g. files can’t be rendered etc.)
PDFNet comes with ~3.4MB worth of resources (e.g. fonts, cmaps, etc) which are not required for many documents. To decrease the size of initial download, these resources could be downloaded on demand - when referenced for a first time. There are other components of the library that could be optionally removed.
Btw, as a comparison the following are file sizes of some AppStore titles for comparison:
Adobe Reader 5.9 MB
Soonr Scribble 14.2 MB
iAnnotate 15.7 MB
PDF Expert 21.7 MB
Goodreader 23.1 MB
PDF Reader Pro 41.7 MB
Adobe's offering is the smallest, but also offers by far the least functionality beyond plain viewing. Also they are probably downloading resources on demand (which is not ideal for some users – e.g. for offline access). Also, it is worth mentioning that it is not necessary to include both armeabi and armeabi-v7a libraries. You could just include armeabi library, but it won’t run as fast as armeabi-v7a library when v7 support is available.
A: In order to build the SDK yourself, you have to follow the following steps:
If you have already done this, I guess it is an emulator issue. In fact, I had a lot of hard times with Android emulator and sometimes it simply stops working for no reason. You can try to shut down the emulator completely and then restart it. Then launch the view from Eclipse. Also, sometimes the emulator will report “Not enough memory in emulator” and you can try to address this issue as http://stackoverflow.com/questions/7306373/android-emulator-error-not-enough-memory-in-emulator
Maybe the ultimate solution to this problem is to get a device. J
1. PDFViewCtrl itself is just a bare bone PDF viewer and it is included in PDFNet.jar. However, we enhanced it by adding UI features, such as text search, text selection, form filling, annotation editing, etc.. The source code of these add-on features comes from Tools.jar. Official customers will have the source code of Tools.jar and hence be able to fully customize the UI and behavior of these add-on features. Therefore, yes, you can easily remove, add features, and customize the UI. Just for a quick test, you can remove the following line mPDFView.Tools.ToolManager(); from PDFViewCtrlDemo.java and see how the bare bone PDFViewCtrl looks like.
2.
3. Bookmarks and TOC are not built-in and we might add this feature in the future. However, you can easily add them yourself in a separate View. Some discussions on bookmarks can be found from
4. As discussed in 1, you can fully customize UI, therefore, yes, you can use any other language.
5. Do you mean that you want all the found instances being listed in some certain View? This is another example of UI customization, I think.
6. You will have source code of Tools.jar, but not PDFNet.jar. You are free to change Tools.jar to meet your needs.
7. There is a readme.html in the SDK package and a doc folder. You can also check out the online version from http://www.pdftron.com/pdfnet/mobile/Javadoc/index.html
I have additional questions.
(1) Yes, it can open password protected PDF files. When such a file is provided, PDFViewCtrl will prompt for password. If you want to suppress the prompt, you can call PDFDoc.initStdSecurityHandler(“the password”) first before you call PDFViewCtrl.setDoc().
(2) Yes. Any other languages are supported, including rendering, searching etc., as long as the corresponding font is embedded in the PDF file. If the font is missing you can provide a substitute with PDFNet.setFontSubst().
(3) The easiest way to obtain the string from the highlights is when it is created. In the current implementation, some text is selected first and then highlighted. You can get the current selected text by using PDFViewCtrl.getSeletion. If you only have a highlight annotation to start with, you will have to do more low-level work in order to retrieve the text. However, we are planning to add an auxiliary function for this purpose soon.
(4) Currently, the SDK supports devices running Android 2.2 or newer.
The PDFViewCtrlDemo uses pdftron.PDF.PDFViewCtrl included in PDFNet.jar. It per se is just a bare bone viewer, but we add various functions such as text search, text selection, form filling, annotation editing, etc., through Tools.jar library. The tools in Tools.jar library talk to PDFViewCtrl through PDFViewCtrl.ToolManager and PDFViewCtrl.Tool interfaces. You can turn off all the tools by commenting out the following two lines:
pdftron.PDF.Tools.ToolManager tm = new pdftron.PDF.Tools.ToolManager();
mPDFView.setToolManager(tm);
in PDFViewCtrlDemo.java.
Note that all the functions in Tools.jar are based on PDFNet.jar. For example, the text search module in Tool.jar is based on pdftron.PDF.TextSearch, and the form filling module is based on pdftron.PDF.Annots. That being said, you are free to write your own Tools.jar to achieve whatever UI factors you want. However, in order to facilitate a quick development, we provide licensed customers the source code to Tools.jar to full customization. So you cannot modify the Tools.jar file right now until you become an official customer.
So for your questions (1) and (2), they are easy to address when you become a licensed customer and have access to the source code of Tools.jar.
For (3), we might consider adding this function as a built-in feature of PDFViewCtrl in the future. However, you can try to implement this feature yourself . One possibility is that you can use pdftron.PDF.PDFDraw class to obtain a page snapshot and then simulate the curling effect (e.g. using https://github.com/harism/android_page_curl).
We've noticed one missing feature or problem:
we have been testing the PDFViewCtrl class to use it for the interactive forms rendering.
But we haven't noticed any signs of interactive form filling features (e.g.
user touches the textfield inside PDF document and the touch keyboard appears).
We have gone through the methods inside the PDFViewCtrl class which could enable the user to interact with interactive forms but with no satisfying results.
PDFViewCtrl class is just a bare bore viewer and it doesn't provide form filling itself. The form filling and other PDF-related functions are provided in PDFNet.jar (or PDFNet.a on iOS). You can see a sample code from:
Java (Android): http://www.pdftron.com/pdfnet/samplecode/InteractiveFormsTest.java
Objective C (iOS): http://www.pdftron.com/pdfnet/samplecode/InteractiveFormsTest.m
So you can use PDFNet.jar (or PDFNet.a on iOS) APIs to manipulate the form data in the PDF file and then tell PDFViewCtrl to update. In fact, we have already implemented various add-on features for PDFViewCtrl, such as form filling, text search, text selection, annotation handling, etc. These functions are included in Tools.jar (or Tools.a on iOS), which extendes the core control with annotation/markup/forms and other feaures. Licensed customers are given the source code of Tools.jar/a for full customization and rapid development.
From a licensing perspective, licensing the SDK for multiple platforms (whether desktop or mobile platforms) will entitle you to discounted pricing as a package. From a technical perspective, working with the same SDK on both desktop and mobile side, should reduce your coding efforts as there is no need to eval, learn, test, and work with many different/incomaptible toolkits.
From what I can see in the provided sample code:
http://www.pdftron.com/pdfnet/samplecode/InteractiveFormsTest.java
it creates programatically the interactive form and then the form is also
programatically filled and updated using PDFNet API.
But can it be done by the user? i.e. the user clicks (touches) the textfield
on the screen and fills it by himself, just by typing the letters using his
mobile device?
-----
A: Yes. Definitely. I pointed you to the sample just to show that the APIs are there in PDFNet.jar.
PDFViewCtrl sample shows how to use Tools.jar and use built-in interactive forms/markup support.
I’m bundling up an android app which has the PDFTron library in to use on a Blackberry playbook – do you know if this is possible?
I just had a quick look at this issue and it probably will NOT run due to the use of the native library (libPDFNetC.so).
“It should be noted that not every Android application is expected to work on the Player. Android NDK apps that use C and C++ libraries will not function — only apps that are written specifically to the Android Gingerbread 2.3.x implementation of the Dalvik VM will run.”
http://www.zdnet.com/blog/perlow/blackberry-playbook-20-android-support-a-work-in-progress/19118
I think this makes sense since the PlayBook’s Android Player is probably only able to emulate the Dalvik VM code, but not the native code specific to Android.
I see that the PDFNet SDK works on Android, but does the add-on for PDF to XPS API conversion work on Android as well?
-----------
A:
Yes, both PDF to XPS (and XPS to PDF) also work on Android/iOS.