By Ts. Lukas J. Tan | 22 September 2026

From a Small File Problem to a Long-Term R&D Journey in Secure Document Processing

When we first started thinking about PDF-X, the idea looked almost too simple.

People have PDF problems.

A file is too large to upload. Someone needs only a few pages from a document. Several PDFs need to become one. A document needs a password before it can be sent.

There are already many PDF tools on the Internet, so at first glance there seems to be very little left to invent.

But that was exactly what made this project interesting.

The more we studied the market, the more we realised that the problem was not simply whether a PDF tool already existed.

The more important questions were:

  • Why are people still struggling with these problems if so many tools already exist?
  • Why do simple document tasks still require users to understand technical settings?
  • What happens behind the scenes when a public website processes a document uploaded by a stranger?
  • How much of the existing experience is designed around what the software can do, rather than what the user actually needs?

Those questions changed PDF-X from a small utility project into something much more interesting to us from a research and development perspective.

Today, I see PDF-X not as the end product of an idea, but as the beginning of a much longer exploration into document processing, secure execution, user experience, infrastructure efficiency and eventually the future relationship between people, documents and intelligent software.

It Started With the Market, Not the Technology

Our first step was not to decide which programming language or PDF library to use.

We started by looking at how people currently solve document problems.

There are large international PDF platforms with dozens of tools. There are desktop applications. There are free websites supported by advertising. There are paid subscription products. There are developer APIs.

Technically, the market is already mature.

But mature does not necessarily mean finished.

What we saw was a gap between technical capability and human intention.

For example, a user may be asked whether they want low, medium or high compression.

But that may not be the user's real question.

Their real question may be:

"The government portal says my PDF must be below 2 MB. Can you make it fit?"

That difference looks small, but from a product-design perspective it is significant.

The user should not need to understand DPI, JPEG quality, image recompression, object streams or PDF optimisation algorithms.

The software should understand those things.

The user should simply be able to communicate the outcome.

That became one of the earliest principles behind PDF-X:

Tell us what you need. Let the system handle the technical complexity.

This principle later influenced almost every decision we made.

We Deliberately Reduced the Product Before Expanding It

Early in the research process, it was very easy to imagine a large document platform.

PDF to Word. Word to PDF. Images to PDF. OCR. Signing. Watermarks. Rotation. Extraction. Conversion. Compression. And dozens more.

But we eventually moved in the opposite direction.

Instead of asking, "How many tools can we launch?", we asked:

What are the few problems worth solving first?

The initial public focus became four functions: Reduce PDF Size. Split PDF. Merge PDF. Protect PDF.

That reduction was intentional.

R&D is not only about adding capability. Sometimes R&D is also the process of discovering what not to build yet.

Word-to-PDF is a good example.

Technically, it is possible. But document conversion introduces another class of complexity: fonts, layout fidelity, images, headers, tables, office formats, rendering engines and additional execution risk.

Rather than releasing it simply because we could, we decided that it should wait until we were satisfied with the processing and isolation model.

That decision represents an important philosophy we developed through the project:

A feature is not finished merely because it works. It is finished when we understand how it behaves, fails, scales and affects the rest of the system.

That is a very different way of looking at product development.

"Reduce PDF" Became a Research Problem

Compression initially sounds straightforward. Take a large PDF. Compress it. Return a smaller PDF.

But once we looked more deeply, we realised the user's expectation is different from a generic compression function.

If someone asks for a PDF below 1 MB, reducing a 10 MB file to 3.5 MB is technically successful compression, but it has failed the user's task.

So the engineering problem becomes:

Given a PDF and a target maximum size, can we produce the highest practical quality result that fits within that limit?

That changes the problem. Now we are dealing with optimisation rather than a simple command.

Different PDFs behave differently.

  • A text-heavy document is different from a scanned document.
  • A document containing photographs is different from one containing vector graphics.
  • An already optimised PDF behaves differently from one containing oversized embedded images.
  • A document may not be reducible to the requested target without unacceptable quality loss.

Suddenly, a very ordinary button, Reduce PDF Size, becomes a technical research problem involving content analysis, iterative optimisation, quality trade-offs and honest communication with the user.

This is where PDF-X became particularly interesting to me.

The simpler we wanted the user experience to become, the more sophisticated the engineering underneath sometimes needed to be.

That is a pattern I believe will become increasingly important in software.

Complexity should move away from the user and into the system.

Then We Reached the Security Question

The biggest change in our thinking came when we started looking at the processing architecture itself.

A public PDF platform has a fundamental characteristic: it accepts files from people it does not know.

From a security perspective, that changes everything.

An uploaded PDF cannot simply be treated as a document. It must be treated as untrusted input.

PDF parsers and document-processing engines are complex pieces of software. They process compressed data, fonts, images, metadata, object structures and many different variations of the format.

Software can contain vulnerabilities.

So we asked a new question:

If a document-processing engine is ever compromised by a malicious file, what would that process be able to access?

This question became one of the most important R&D directions in the entire PDF-X project.

Normally, a PHP application may start an external document-processing program under the same Unix account as the application.

Without additional isolation, that child process may inherit much more access than it actually needs:

  • Application files
  • Environment variables
  • Other temporary directories
  • Network connectivity
  • Other resources visible to that account

But a document processor may only need:

/work/input.pdf
/work/output.pdf

Why should it see anything else?

That simple question eventually led us to investigate process isolation on Linux.

From PDF Processing to Sandbox Engineering

We studied how we could create a smaller execution boundary around external document-processing programs.

That led us to Bubblewrap, a Linux sandboxing technology based on namespaces and filesystem isolation.

The design gradually became very clear.

  • Each processing job should have its own workspace.
  • The external processor should see only the files required for that job.
  • It should not inherit the application's full environment.
  • Network access should be unavailable unless explicitly required.
  • Commands should be invoked as structured argument arrays rather than assembled into shell strings.
  • Processing should have time limits and resource controls.

And perhaps most importantly:

If the sandbox cannot be created, the system should fail rather than silently run without it.

That last principle became especially important.

A security feature that disappears without telling you can be more dangerous than having no security feature at all, because it creates false confidence.

So the approach became fail closed. If the containment environment is unavailable, processing stops.

Security Research Also Taught Us to Be More Precise

One of the most valuable lessons from this project was learning what not to claim.

It would be easy to say: "Our PDF processing is secure."

But security does not work as a simple yes-or-no state.

  • The sandbox isolates the spawned processing process.
  • It does not automatically sandbox the entire PHP application.
  • It does not sandbox the queue worker that started it.
  • It does not replace operating-system security.
  • It does not remove vulnerabilities from Bubblewrap or the Linux kernel.
  • It does not make output files trustworthy simply because they were produced inside a sandbox.

Some resource controls also require capabilities outside the library itself.

The deeper we went into security engineering, the more careful our language became.

Instead of saying "This makes document processing safe", the more accurate statement is:

This reduces the attack surface and limits what a compromised child process can reach.

That distinction matters.

And I believe responsible technology companies need to become much more comfortable communicating limitations.

Trust should not come from claiming perfection. Trust should come from explaining the boundaries honestly.

The Internal R&D Became an Open-Source Project

At this stage, something unexpected happened.

The sandboxing work was originally just one part of PDF-X. But we realised that the problem was not actually specific to PDF-X.

Many PHP systems execute external programs against untrusted input: OCR engines, image converters, Office-document processors, media tools, archive utilities, analysis binaries.

They all face a similar architectural question:

What is the minimum this external process needs to access?

So we extracted that work into a separate open-source project: PDF-X Secure Runner.

The package became independent from the private PDF-X application. It is framework-independent PHP. It can be used with Laravel, but Laravel is not required. It does not bundle the PDF-processing engine itself.

Its purpose is narrower: provide a controlled execution boundary around an external process.

That work was released publicly through Composer, Packagist, GitHub documentation and automated Linux containment testing.

And that created another dimension to the project. PDF-X was no longer only producing a user-facing tool. It was producing reusable infrastructure.

Open Source Changed the Nature of the Research

Once something becomes open source, the engineering mindset changes.

Internal code only has to satisfy the team maintaining it. Public infrastructure has to explain itself.

  • What does it protect?
  • What does it not protect?
  • What assumptions does it make?
  • What operating systems does it require?
  • What happens when dependencies are unavailable?
  • How can another developer verify that the containment model is actually functioning?

This led us to build documentation around architecture, security boundaries and integration. It also led to containment tests and a self-check mechanism rather than relying entirely on assumptions.

This is an important part of R&D that is sometimes overlooked.

Research is not complete when something works on the developer's machine. It becomes much more valuable when the assumptions behind the result can be tested and understood by other people.

That is one reason I am increasingly interested in open-source work.

Public review creates pressure for clarity. And clarity improves engineering.

We Also Had to Study the Reality of Infrastructure

Another lesson came from deployment.

Engineering cannot happen in isolation from business reality. It is easy to design the perfect architecture if budget, infrastructure and operating constraints do not exist. In the real world, they always exist.

We studied how much isolation could realistically be achieved on our existing Linux hosting environment.

We looked at process ownership, file permissions, shared server behaviour, queue workers, temporary storage, cleanup, memory, disk availability, request admission, rate limits and operational monitoring.

Some things could be improved through application design. Some things could be isolated through Bubblewrap. Some things ultimately depend on the host architecture itself.

And there is an important lesson here:

Application security has boundaries that application code alone cannot cross.

If strict host-level isolation is required, infrastructure may eventually need to change. Recognising that limitation is part of engineering maturity.

The answer is not always another function or another package. Sometimes the answer is architectural.

Reliability Became Part of Security

Our research also reinforced something I believe strongly: security and reliability are connected.

If a processing system runs out of memory, fills disk space or accumulates thousands of abandoned jobs, that is not only a performance problem. It can become a security and availability problem.

So we introduced controls around processing jobs:

  • Temporary job directories and automatic cleanup
  • Queue-based processing
  • Signed status and download access
  • Rate limiting
  • Disk and memory admission checks
  • Process timeouts
  • Maximum file sizes and workspace controls

The goal was to prevent a simple document-processing feature from becoming an uncontrolled resource consumer.

Once again, something that looks like a small utility on the frontend becomes a systems-engineering problem behind the scenes.

The Market Research Changed Our Definition of Innovation

When people hear the word "innovation", they often expect something dramatic. AI. Robotics. Blockchain. A completely new technology.

But working on PDF-X has reminded me that innovation can also come from reframing an existing problem.

PDF compression is not new. Splitting a PDF is not new. Sandboxing is not new. Linux namespaces are not new. PHP is certainly not new.

But innovation can happen in the way those pieces are combined.

  • Can an ordinary office worker use a technically sophisticated document-processing pipeline without having to understand any of it?
  • Can a free online utility be designed around user outcomes instead of technical settings?
  • Can the security work developed for one product become reusable infrastructure for other developers?
  • Can a document-processing platform become a laboratory for exploring secure execution, optimisation and intelligent automation?

Those questions are far more interesting to me than simply asking: "Can we build another PDF website?"

PDF-X Is Beginning to Show Us a Larger Opportunity

This is where I think the long-term R&D journey becomes interesting.

A document is one of the most common interfaces between people and organisations. Invoices. Reports. Applications. Contracts. Statements. Certificates. Forms. Purchase orders. School documents. Government submissions. Corporate paperwork.

For decades, we have focused mainly on creating, storing and displaying these documents.

The next stage may be different. Software will increasingly need to understand the user's intention around a document.

Not "Choose compression level 1, 2 or 3." But: "Make this acceptable for my application portal."

Not "Select pages 17-22." But eventually: "Give me only the pages containing the invoice and payment details."

Not "Merge file A, B and C." But: "Prepare these documents in the correct order for submission."

This is where document utilities may eventually meet intelligent systems.

But there is an important condition. AI should not be added merely because AI is fashionable. It should appear only when it reduces the amount of thinking required from the user.

The intelligence should remain underneath. The simplicity should remain on top.

Privacy Will Become More Important, Not Less

There is another future direction we are watching carefully.

As software becomes more intelligent, more user data is likely to be processed. Documents may contain some of the most sensitive information people handle: financial information, personal identification, contracts, business records, internal correspondence.

So future document intelligence cannot be developed independently from privacy engineering.

This may lead to different architectural models. Some processing may remain server-based. Some may eventually move closer to the browser or user device. Some organisations may require private deployments. Some workflows may need isolated workers. The right architecture will depend on the sensitivity of the task.

For us, this means privacy is not simply a legal page at the bottom of the website. It is an R&D topic.

We Are Also Beginning to See PDF-X as an Engineering Platform

The public sees four tools. From an engineering perspective, we now see several deeper research layers underneath them: document optimisation, untrusted-file handling, secure execution, temporary storage, resource governance, asynchronous processing, user intention, privacy, developer infrastructure, and potentially later, intelligent document understanding.

This is why I say PDF-X is only beginning.

The product may remain visually simple. But the technology behind it can continue evolving for years.

Some of that technology will remain part of PDF-X. Some may become standalone open-source components. Some may become services. Some experiments may fail completely.

That is normal R&D. The objective is not to pretend that we already know the final destination. The objective is to continue asking useful questions.

Build, Observe, Learn, Then Build Again

One of the mistakes technology companies can make is to treat launch day as the finish line. For us, launch is closer to the beginning of the experiment.

Now we can observe real behaviour.

  • Which file sizes are common?
  • Which operations are used most?
  • Where do users abandon the process?
  • Which PDF types create problems?
  • What do people ask for that we did not anticipate?
  • What security assumptions change when usage increases?
  • What becomes expensive at scale?
  • What should remain free?
  • Which infrastructure needs to be separated?
  • What should never be automated?

Those answers cannot come entirely from planning documents. They require real systems and real usage.

This is why I like building. You discover things by moving.

What I Hope PDF-X Becomes

I do not want to define PDF-X too narrowly today. At the moment, it is a simple online PDF utility. That is what users should see.

Behind it, however, we are building knowledge: how people interact with documents, secure document processing, file optimisation, resource management, infrastructure boundaries, and how much complexity can be hidden from the user without hiding important truth.

Over time, that knowledge may become more valuable than any individual button on the website.

That is often how meaningful technology develops. The first product solves a problem. The process of solving that problem reveals a deeper problem. Solving the deeper problem produces reusable technology. That technology creates the next opportunity. And the cycle continues.

This Is Why I Call It R&D

Research and development is not only something that happens inside a laboratory. For a software company, it can happen while solving very ordinary problems.

You research the market. You observe the user. You study existing technology. You test assumptions. You discover limitations. You redesign. You fail. You isolate the failure. You improve the architecture. You document what you have learned.

Then sometimes you discover that a small component of one product can become something useful on its own.

That is exactly what happened with PDF-X Secure Runner. And I suspect it will not be the last thing to come out of PDF-X.

The Beginning, Not the Conclusion

When we started, we were trying to build a useful PDF website. Today, I see something larger. Not necessarily a larger website. A larger field of exploration.

  • How can document processing become simpler for humans while becoming more disciplined underneath?
  • How can intelligent automation understand outcomes rather than force users to understand settings?
  • How can untrusted document processing be isolated more effectively?
  • How can privacy and security remain part of product architecture rather than being added after the product is built?
  • And what other reusable technologies will we discover while trying to solve these ordinary problems properly?

I do not know all the answers yet. That is exactly why this is interesting.

PDF-X is live as a product. PDF-X Secure Runner is now open source. But from an R&D perspective, both are still at the beginning.

We built something. Then we looked underneath it. And underneath that simple PDF tool, we found a much larger area worth exploring.

That is where I believe the next chapter starts.

  • PDF-X: pdf-x.co
  • PDF-X Secure Runner: open-source infrastructure developed from the engineering work behind PDF-X.

And from here, we continue to build, study, test and discover.

Because sometimes innovation does not begin with trying to invent the future. Sometimes it begins by taking one ordinary problem seriously enough to ask:

"Can this be done better?"

Ts. Lukas J. Tan
Founder & CEO, OPERION Ecommerce & Software Sdn Bhd
R&D | Secure Document Processing | AI & Business Systems