Google Summer Of Code ‘26 at KDE— My Journey

Background

I got selected to contribute at KDE community at Google’s Summer of Code 2026 program where I would now work on implementing a novel optimization called “Font Subsetting” inside a 25 year old PDF rendering library.

The following is a description of what I did in the pre-selection period (before getting selected into GSoC).

Note: The following is LLM formatted. For some reason, my english feels very clunky today. I hope you don’t mind :D

Main content

GSoC wasn’t my primary goal when I started contributing to KDE. I had planned to spend two hours each day studying DSA and another two hours on open source contributions. My intent was simply to write C++ for an organization and experience working on large codebases for the first time. At that stage, my goal was to deepen my understanding of C++ and become a better programmer.

A few days later, I learned that my university was conducting GSoC mentorship sessions to introduce students to such programs and guide them through the contribution process. I remember debating whether to attend, as I wasn’t sure if I could — or even wanted to — pursue GSoC, since it hadn’t been part of my original plan. Eventually, I decided to give it a try. I thought, “What’s the worst that could happen? Rejection?” Since I was already contributing to KDE, there was little to lose. If it worked out, great; if not, I would still gain valuable experience. Committing to GSoC wasn’t a prerequisite for learning, so I joined the mentorship.

Over the following months, I contributed to Kate and Poppler (the C++ PDF rendering library), with support from the KDE community and guidance from my university mentor. That summary may sound like a simple step forward, but in reality, it felt like going from zero to a hundred in terms of learning.

For the first time, I wrote real multi-threaded C++ code for a tool that people actually use. I found it exciting to work on making a widely used utility like pdftotext multi-threaded. However, after regression testing with my Poppler mentor, we uncovered several issues — bugs, race conditions, and lock-ordering problems — which made me appreciate how challenging debugging multi-threaded systems can be.

I also recall suggesting, early on, that Poppler’s search functionality could be made multi-threaded. Looking back now, that idea feels a bit naive.

Another major task I worked on was enabling multi-font support for PDF forms. This was by far the most difficult problem I tackled, and I spent nearly a month on it. There were stretches where I wrote no code at all, and days when I struggled just to understand how the system worked. I explored multiple approaches — studying how annotations handled similar cases, experimenting with partial implementations, and gradually refining imperfect solutions. Eventually, I managed to make it work.

The merge request is still under review, which has reminded me that getting something to work is only part of the problem. Writing clean, maintainable, and understandable code is equally important — and something I’m still working on.

Alongside these larger efforts, I also contributed to smaller improvements, such as enhancing the cache in the XRef class.

My mentor at KDE also played a significant role in shaping my approach. I asked my fair share of basic questions, but his responses led to some important realizations:

• Nothing is guaranteed. Outcomes are uncertain, and you only control the effort you put in. It’s better to focus on the process rather than the result.
• Ownership matters. You’re expected to do most of the work yourself. Mentors and the community are there to help, but it’s most effective to reach out after you’ve genuinely explored possible solutions.

(I’m still working on fully applying these lessons.)

In the end, things worked out, and I was fortunate enough to be selected.

Thank you for reading — I hope this wasn’t too long or dull.