Monthly Archives: October 2014

PDF form filling

Today’s question, which we are asked frequently, is “is it possible to have interactive form-filling in a secure PDF?” Here is our immediate response:

The brief answer is “no” – in fact this is a particularly problematic area where a document is encrypted, as “by definition” it cannot be amended because that would require decryption, modification of the document, and then re-encryption… which for truly secure offline documents is not possible. However, less secure solutions may be able to do this, and systems that interact with web-based facilities may also be able to do it. If you have an interactive PDF the probability is that it was produced using Adobe software, and their interaction and processing facilities are, in large measure, proprietary, so the main response would be “use Adobe reader/an Adobe-based solution” for those parts of the application that you need form-filling etc. This could mean separating a PDF into two parts, for example a secure document that was designed simply for reading etc, and some interactive forms that go with it and are essentially unprotected. Another option is to have a secure document but permit limited printing of forms – we have customers who do this, for example for medical interviews and assessments. Another option is to provide the solution entirely “on line” and have interactive forms provided programmatically and/or via standard tools such as flash or html5, or a forms builder. For Adobe’s core offerings in this area see:

PDF Print scaling

In previous posts we have commented on handling PDFs that have large page sizes. The question of how to print such pages frequently arises, so an update on our earlier discussion would seem to be timely. The first observation to make is that most consumers can only print A4 or US Letter paper sizes … less than 10% will have printers capable of handling larger formats, at least, that will the case at home – most offices have a wider range and print shops can handle a very large range of page sizes.

Typically a PDF reader (from Adobe or elsewhere) will re-scale any oversized PDF document to “best fit” the page size supported by the default print device. The re-scaling results may or may not be satisfactory and may vary by printer type, paper etc. In order to be sure of the end results, a simple option is to re-scale the source PDF. Then, when the end user prints the document, there is no re-scaling required and the results are exactly as you expect. If you want the user to be able to see the resulting printout in a larger format, all they then need to do is to photocopy it with a setting to enlarge the document to their preferred size. However…

… for documents that are 2+ times the size of standard paper sizes and/or require very precise scaling (e.g. dress patterns), this still leaves a major issue – re-scaling may be undesirable and/or unreadable. The solutions in this case are either: (i) offer an on-demand in-network print service, with delivery to the customer by post; (ii) offer pre-printed copies of selected documents that are over-sized, e.g. posters, newspapers, technical drawings, dress patterns etc; or (iii) permit the user to have the source PDF printed by a suitable (approved) print shop. Option (iii) is only possible if the source PDF is made available to the print shop and meets their requirements (i.e. a completely unsecured PDF) – in most cases using export settings (e.g. from InDesign) specifying that the output PDF is designed for print production will produce satisfactory results. The key variables are resolution (which must be 300dpi or greater), embedded fonts (to ensure the end result looks correct/uses the correct fonts), and sufficient bleed (2-3mm) to ensure pages can be trimmed to size where necessary. For most conventional documents the trim issue will not present problems. For precision printed documents (e.g. technical drawing to scale, patterns to be cut out) option (ii) is the only practical solution.

Kindle Fire HD – test drive for PDFs and secure PDFs

The Kindle Fire range of devices is Amazon’s answer to demands for a more functional device than the basic Kindle. All the more recent versions run an amended variant of the Android operating system, tailored to be Kindle-like, but also capable of running a wide range of applications. However, these applications are generally only available from the Amazon app store, not from Google Play or other Android app stores. Furthermore, Amazon’s terms and conditions for apps hosted on their App Store include requirements to pay them a substantial royalty if an app from the store is used to “sell” an item, such as a publication or training course materials. So what is the solution for PDF publishers? Well, Javelin for Android will run on Kindle Fire devices – see below for more details.


Javelin for Kindle

The Javelin secure PDF reader for Android is compatible with Kindle Fire (KF) and  is easy to install and run…  The screen resolution on the KF 7inch model is 800×1280, so not bad (much cheaper but not nearly as good as the new iPADs), and its dual 1.5Ghz processor is fast enough for even the most demanding of PDFs. We tested it on a couple of the largest documents distributed by our customers. These books have around 1000-2000+ pages and a large number of images and links. They load in a couple of seconds from completion of downloading, and because the entire document is held in virtual memory, they are almost instant when accessing any page.


Installing and running the Javelin app

Installation of Javelin on the Kindle is quick and simple – full details are provided here. To run the app you simply touch the Javelin icon and the Home page opens. For many users the documents they wish to view will be included within a catalog, either the built-in Catalog or a separate downloadable catalog of books, training materials or other documents. The publisher creates these and explains to end users how to download them. Touching the cover of a title in a catalog then downloads that book or document.For standard PDFs the file may then be opened immediately, whilst for secure PDFs (drmz files) an authorization code is usually required, after which the file may be opened and read.


If the Kindle Fire is your preferred reading device for ePUB books, newspapers and other materials, it can also be used for standard and secured PDF reading. As most Kindle Fire devices are quite small and not very high resolution it is best used for PDFs where the font is larger, the page sizes are smaller than standard, and/or the materials are graphical. It is also good for holding reference documents, where the user wishes to select an item and can zoom in to check details, rather than reading lengthy blocks of text.

Screen capture protection

A very common question we are asked is “can we include protection against screen capture” for our PDFs on a cross-platform basis? The simple answer is “no”, whatever system or supplier you look at and whatever others may claim! A little background should help clarify this.

With the introduction of screens for interacting with computers in the 1980s it was necessary to provide dedicated hardware components to manage the display of text and graphics. As PCs and similar devices became more advanced, graphical demands became greater and specialized “graphics cards” (and later, “chipsets”) were included to provide this functionality. The cards and chipsets included both processing and memory handling functions, and software tools soon became available that would access the stored information directly. These were initially utility programs, and then rapidly this functionality was included in third party photo/image processing software and built-in tools (e.g. the Snipping tool in Windows 7 and Grab on Mac OSX 10). This allowed users to display information on screen and then “capture” all or part of the screen for subsequent editing. The user did not need to understand where this information came from, just that it was readily accessible. The operating system was essentially bypassed by the screen capture software, which could go straight to the hardware memory to read the information that was displayed visually on-screen.

To prevent such programs from being used to capture screens mechanisms had to be found that interfered with the way they worked. The principal mechanism was to identify that a process was running that was known to have screen capture functionality, and then to refuse to display some or all of the screen until the offending process (program) was terminated. This worked fine for some years, until new devices, operating systems and ways of working were introduced in the last few years.

With the introduction of mobile devices (tablets) manufacturers quickly realized that many customers wanted to capture screens for onward processing. Instead of leaving this to third party software providers they included combinations of buttons that could be pressed to screen grab and save to the local image “Gallery”, in the same way that photographs taken with built-in cameras were stored. This hardware-based screen capture facility meant that information display, such as a PDF on screen, could always be captured and no software mechanism could prevent it. In parallel, more advanced versions of desktop operating systems from Apple and Microsoft started to include screen capture software as standard, running in a background thread or process, that end users were completely unaware of. An example is Microsoft’s OneNote software, which even when closed still retains a background process for screen capture. These changes to the hardware and operating system environment have meant that mechanisms to prevent screen capture either no longer work in a cross-platform world or create more problems than they solve. However, limited scale protection is possible for specific operating systems, notably Windows variants, where systems such as Javelin now incorporate some quite clever procedures for preventing screen capture if this option is specified for secured PDFs.

A further development has been the introduction of much higher resolution screen displays. Until very recently all computer screens were less than 100dpi (dots or pixels per inch). This compares with typical print output which is at least 300dpi, and high quality print and image data which is 1200-2400dpi. High resolution screens require far more memory and processing, which is why they have only started appearing in the latest range of tablet and mobile phone devices (e.g. iPhone6 has a 400dpi screen). Such devices can be scanned or digitally photographed, so the display itself becomes like a paper copy of the source material, and nothing can prevent the use of such external mechanisms from capturing screens at a resolution that enables reading and/or conversion via OCR to structured text.

The only workable cross-platform solution to such issues is to add static and dynamic watermarking to secured PDFs. This information then forms part of the in-memory and on-screen data, and as such will always be included in any capture process, and can be difficult or impossible to remove. It is even possible to include invisible watermarks, using special characters or hidden graphics. The use of watermarking is discussed in another of our blog entries – please see here for more details.

Drumlin Security’s Javelin PDF readers support several mechanisms for content and screen capture protection. The first is the displayed information is essentially just a graphic image, rather than selectable text – there is no facility for text selection nor any support for the clipboard (i.e. copy/paste functions) and all information is held in memory, with no temporary disk files that include decrypted data. The second is support for static and dynamic watermarking, as discussed above. Finally, recently enhanced, there is the screen capture protection option. If you have any questions regarding this blog item, do please contact us or add your own comment to this entry.