Apryse SDK allows you to intercept annotation events and add custom code for when they are triggered.
By default, the Tools library will respond to user actions such as a click event on a link or form widget, or a property change event on a selected annotation. It is possible to customize such behavior before it is executed within the Tools library, as well as getting notified of an action after it has happened.
If you would like to customize the behavior executed in response to user actions prior to it being handled by the Tools library, it is possible to do so with the BasicAnnotationListener.onInterceptAnnotationHandling(Annot, Bundle, int)
API. If this method returns true, then it will intercept executing the default logic.
In BasicAnnotationListener.onInterceptAnnotationHandling(Annot, Bundle, int)
, the second parameter, Bundle
, contains the name of the action intercepted by this function, as well as some extra information. You can get the name of the intercepted action by calling bundle.getString(Tool.METHOD_FROM)
:
To get extra information, first obtain the information keys by calling bundle.getStringArray(Tool.KEYS)
:
Then, you can get the information values by looping on each key obtained above:
For example, the following code demonstrates several scenarios and how you can get notified before each: clicking on a radio button, changing the annotation opacity, and clicking on a link. See the comments in the code for details.
If you simply want to get notified after the action has happened, you can do so via the AnnotationModificationListener.onAnnotationsModified(Map<Annot, Integer>)
API. This event callback is raised when an annotation change has occurred. For example, in order to get notified when the value of a checkbox has been changed and when annotation opacity has been changed, do the following:
We are always interested in expanding the customization options through APIs, and will be adding more options in the future. If you would like to suggest changes, please don't hesitate to get in touch.
Annotation and PDF interaction is implemented within the open-source Tools.framework
. This includes annotation creation & selection, text selection, form filling and link following.
The behavior is implemented via a collection of "Tools": classes that derive from the abstract base class PTTool
and that are coordinated by a PTToolManager
. The PTToolManager
provides the ability to customize tool behavior, and enable/disable the ability for users to create or edit annotations (both in general and on an annotation type by annotation type basis).
To disable (or re-enable) the ability to create or edit annotations, options can be altered as shown below. When disabled, the relevant annotation tool is removed from the annotation toolbar, and from the UIMenuController
.
Further control over annotation interaction behaviour via the PTToolManagerDelegate
protocol.
There are several methods that allow you to be notified of, and if desired modify or prevent, default behavior from occurring. For all methods, if false
is returned, then the default behavior will not occur.
UIMenuController
object is passed so that menu items can be added or removed as required.The sample code uses ShouldShowMenu
to restrict use of the UIMenuController
to copying and defining text found in the PDF. This is done by stopping the UIMenuController from popping up in any case other than selecting text, and by removing options to highlight/underline etc. from the selected text UIMenuController popup.
Default Menu Options | Customized Menu Options |
---|---|
Tools.framework
frequently creates new instances of objects defined within the framework (e.g. a new instance of PTAnnotEditTool
is created when a user taps on an annotation). In order to customize certain aspects of the default behavior, it is required to create and use a subclass of the built-in tool. To enable this without requiring source code modification, Tools.framework
includes a system to "inject" an externally defined subclass that will be used by the Tools.framework
during its normal operation. This is done via the PTOverrides
class as follows:
Note that in order to be compatible with the external override system, the base class must conform to the PTOverridable
protocol.
Because Tools.framework
is open source, any and all changes are possible by editing the source code directly. The project is found in /Lib/Tools/src
.
If you customize the tools source code, you will likely want to use a universal framework (one that contains architectures for both simulators and devices), which is not done automatically by Xcode. The Tools project includes a custom script step that automatically creates a universal framework, located in a folder next to the default build location, with the name {Debug,Release}-universal
.
(Building a universal framework also be done manually by first building for device, then simulator, and using the terminal command xcrun -sdk iphoneos lipo -create
to merge the binaries (Tools.framework/Tools
) into a universal binary.)
Then create the Xamarin binding as described here: Create Tools package from PDFViewCtrlTools Objective-C source code .
Did you find this helpful?
Trial setup questions?
Ask experts on DiscordNeed other help?
Contact SupportPricing or product questions?
Contact Sales