Stop Wasting Bandwidth with PDFs - Transfer Changes with Instant JSON

In this blog post, we’ll explore options that allow us to reduce bandwidth when sending a PDF from one place to another. As we know, users are sensitive to speed and bandwidth use. As such, any optimizations in these areas will lead to a better user experience, and in turn, increased user satisfaction!

What’s the Problem?

PDFs can be a mixed bag. Some are simple and only kilobytes in size. Others can be hundreds of megabytes in size, with large images scattered everywhere. However, even with this known variation, the PDF format is great for fidelity across lots of environments and software. For that reason alone, it remains the top choice for many technical solutions.

Now think about transferring large documents from a client to a server, or the other way around. The potential bandwidth usage could be unforgivable, especially in a mobile environment.

With a single transaction of a customer downloading a document, editing it, and uploading it, we could be talking dozens of megabytes. If these transactions are performed hundreds of times a day, your user will soon eat through their data usage. There’s also the possibility of slow network traffic causing user experience issues.

In many situations where we’re transferring documents from one location to another, we’re only interested in what has changed since the last known state. An example of this is if a user has filled out a form and we want to know the new values of the form, or we want to store the filled-out form on a server somewhere. There’s no need to send the whole document over the network time and time again when we could just send the changed information and recreate the same document on the server, potentially saving many megabytes of bandwidth.

Instant JSON is our approach to solving the bandwidth problem. We save the changes made into a JSON file, which can be read at a different location. If the other location has the same base document that was used to create Instant JSON, the document can be recreated and will represent the same state in the original location.

A Real-World Example

Instant JSON works best when we’re using the same PDF over and over again, but with different users adding unique information to the document. A great example is that of users filling out a form with their information. Sending only the form field changes rather than the entire PDF results in a significant reduction in network traffic.

In this example, we’ll use Instant Document JSON to synchronize all the annotation changes of a document (this includes form fields). Note that this differs from Instant Annotation JSON, which can sync individual annotation changes.

When a user is filling out a form, they’ll use a UI, which in our example could be PSPDFKit for iOS, Android, Windows, or Web. I’ll only show the iOS implementation here, but you can find similar examples in our other products below:

• Android

• Windows

• Web

Next, we’ll need a solution to process the Instant JSON once it reaches the server. For this, we have multiple products for different environments. In this example, we’ll focus on our PSPDFKit Libraries product, which supports .NET and Java, but you can follow the links below for other options:

• Server

• Processor

Saving Instant JSON Changes in iOS

Using iOS, we’ll write some code that takes any changes a user has made and writes them out as Instant JSON. The data can then be sent over the network, saved to a file, or transferred via any other method we desire:

let data = try? document.generateInstantJSON(from: document.documentProviders.first)

NSError *error;
NSData *data = [document generateInstantJSONFromDocumentProvider:document.documentProviders.firstObject error:&error];
if (!data) {
  // Handle error.
}

Retrieving and Recreating the Document with Libraries

Let’s now imagine we retrieved the Instant JSON changes that were written to our instant.json file. We can instantiate that same document locally with our PSPDFKit Libraries instance and apply the Instant JSON changes to recreate the same state the user had on iOS:

File file = new File("instant.json");
document.importDocumentJson(new FileDataProvider(file));

val file = File("instant.json")
document.importDocumentJson(FileDataProvider(file))

document.ImportDocumentJson(new FileDataProvider("instant.json"));

You may now be thinking, “But wait, what if I don’t have the same document? Or what if I happen to use the wrong document when importing the Instant JSON?” That’s where PDF IDs come into play.

According to the PDF specification, a PDF must contain a permanent ID and a changing ID. We use the permanent ID to verify that the PDF we’ve opened together with the Instant JSON is indeed the correct one. If it isn’t, an error is thrown.

Analyzing the Traffic Figures

If we have a PDF consisting of multiple form fields, we could be looking at a file size of around 1 MB. If we were to send that document back and forth from the server to the client, we’d expect to upload 1 MB of data and download 1 MB of data. We could reduce the upload by only sending the changes, which might consist of roughly 1 KB of data. That’s nearly half our total network transfer amount contributing to a 1 MB download but only a 1 KB upload!

To improve the experience of the user further, the PDF doesn’t even have to be downloaded on demand. It could be distributed with app data, meaning that we’ll only transfer 1 KB of traffic on demand, which speeds up the experience and results in a satisfied user.

Conclusion

In this post, we saw how powerful the Instant JSON feature can be in reducing network traffic. With Instant JSON change data starting at as low as 200 bytes, it’s possible to reduce the amount of data transferred by quite a bit.

If you’d like to try out Instant JSON on any of our products, head over to our trial page and get coding!