How your feedback shaped the PDFTron SDK core engine during 2018
By Aleksy Jones | 2019 Jan 23
PDFTron SDK has many different faces -- there are front ends available for Web, iOS, Android, UWP, WPF, and many more. Each one of these faces shares the same core rendering and processing engine, and we're always improving this engine in response to customer needs. Over the past year, our team has made approximately 1000 contributions to the core engine, the vast majority of them in direct response to customer needs.
We continually add new features and improve the behaviour of the features that are already there. Sometimes these new features and behaviour changes are only applicable to one type of workflow or use-case, but there are a few things everyone agrees on, which form the highest priorities of our core SDK team: be more robust in the face of arbitrary customer files, render and process faster, and use less memory while doing it.
Performance and efficiency
SDK performance is always welcome -- good performance can mean the difference between a seamless or a clumsy viewing experience, and it can mean the difference between a microservice that keeps on working dependably and one that gets shuts down due to excessive resource usage. A sampling of the performance improvements that we've made this year
- Performance improvements for documents that have been opened directly from memory -- reduce internal memory copies when they are not strictly required.
- Greatly reduced memory usage when converting XLSX to PDF.
- Much reduced memory usage for nested complex clipping paths (modest on most docs, up to 100x better on some extreme cases).
- Overprint preview handling has been optimized.
- Linearized save on documents with many pages is now significantly faster.
- Added caching for high-dimensional sampled functions and complex Postscript functions -- rendering speed improved by 5x on some documents.
- Greatly improved speed and memory usage while converting text files to PDF.
- Conversion from CalRGB to device colorspaces is now more than 2x faster.
- Repeated calls to PDF.GetPage are now much faster, particularly for documents with many pages.
Robustness
Customers value PDFTron SDK for being a stable and reliable part of their application. One of the most significant developments over the past year has been the development and improvement of our own internal API fuzz tester. We generate semi-random streams of API operations and perform them (and their reverse) on the PDF as fast as the testing system will allow. While doing this, we keep an eye on stability, resource usage, and how long it's taking. This has resulted in improved SDK stability and predictability, particularly for multithreaded usage (the typical PDF viewer is highly multithreaded).
Another aspect of robustness is how we mitigate the risk of crashes caused by loading corrupt PDFs. The PDF format has been around for a long time, and that's given document creators many years to develop and express some... creative interpretations of how a PDF should be constructed. If you're developing your own application that will accept arbitrary PDF documents from end users, then you won't have to worry about loading these documents with our SDK, and having it behave reliably. Towards this end we've improved our corrupt document handling in a number of ways. For instance, we offer:
- Better handling of invalid or missing fonts by seamlessly substituting a fallback
- More robust handling of missing pages or corrupt pages when viewing interactively
- Improved handling of malformed or xref tables -- we can repair these more often and repair them more effectively.
Looking forward
A big thank-you to all of our customers: thank you for choosing PDFTron, and thank you for giving us feedback, and the opportunity to make our SDK even better. We're really looking forward to the next year -- our team is growing and we've got a lot of big plans on the horizon. But even with all the big plans, performance and stability are still number one.
Aleksy Jones
Share this post
