GSoC :: Coding Period – Phase Three (July 8th to August 6th): Create and parse DA string in poppler-core and font family implementation

Hi everyone,

The coding period phase three is now completed. After the second evaluation, Poppler’s maintainer Albert Astals Cid commented on my bug report stating that the current parsing and creation of DA string is handled by Qt5 frontend whereas the API should be changed and the creation and parsing of the DA string and font color should be the concern of poppler-core.

So I needed to shift my plans for the font family implementation in Poppler and I began to work on correcting the creation and parsing of DA. Both the Qt5 frontend and the Core were modified and after a series of reviews, I finally submitted the patch co-authored by my mentor Tobias Deiminger

Meanwhile, my mentor was sending me the emails and was pushing his researched results into the scratch repo regarding the font family implementation in Poppler. In the last days when I completed with the font color and DA creation and parsing patch, I began to hack into the font family. I have written the full post about my own understanding and experiment here: FreeText Annotation :: Font family implementation in Poppler. My experimental patch can be found here.

After incorporating D13203 and both the patches, this is how it finally works:

  1. It adds the typewriter tool to the annotation toolbar
  2. You can select a font color for the annotation’s text
  3. You should choose a Base-14 font and it would be correctly displayed

As you can see in the above image that you are able to make the different base-14 font for the different typewriter annotations text within the same document when loaded but neither it writes the font dictionary into the PDF document nor you will get the same fonts on document reload. It falls to the default font “Helvetica”.

But this experimental patch is very promising for the intuition of accurate solution and the support for the embedded fonts.

What’s Left

The experimental font family implementation for the base-14 fonts is quite buggy and is not an accurate solution. It is also not nicely structured and requires the proper implementation to write the streams and embed fonts into the PDF document and we need to create an in-memory Appearance with an in-memory Resource Dictionary, where the /Font entry points out to the on-disk Font Subdictionary inside AcroForm->DR.
It would actually be good to save the in-memory appearance as /AP into the document (PDF 2.0 requires this, and a number of existing Okular issues arise from not saving AP). But that’s unrelated to the font family issue.

I want to thank my mentor for constantly motivating and monitoring me by putting the enormous efforts and it was really nice working with him :)


I’m going to Akademy 2018 – Vienna, Austria

Being an active open source contributor to KDE Community and a GSoC 2018 student in the same organization, I’m going to attend Akademy 2018 in Vienna, Austria from August 10 to August 17.

Akademy is KDE annual conference and comprises of hundreds of attendees from the global community. The venue is Technische Universität Wien (TU Wien) and I’m glad that I’m being sponsored by the KDE e.V.

I have a short presentation on my ongoing GSoC project where I will spread the word about Okular under the Student Presentations Slot on day 1 at 16:30. Besides that, I’m planning to attend the Public Speaking Training and Practicals by Marta Rybczynska and various BoFs for the next 6 days. I will be lucky to witness the awesome speakers there.

See you in Wien!



GSoC :: Coding Period – Phase Two (June 13th to July 7th): Font color implementation in Poppler and Okular

Hi everyone,

The coding period phase two is now completed and I’m done with the font color implementation in Poppler’s Qt5 frontend and in Okular’s typewriter annotation tool. I have updated the phabricator revision D13203 and filed a bug and attached the patch in freedesktop’s bugzilla

As per the agreed timeline, I have patched the poppler-qt5 with the font color by introducing the ‘rg’ operator in the GooString which formats the font color in the RGB color model. In Okular, the font color chooser is introduced in the typewriter annotation setting dialogue which sets both the text annotation’s color and the engine color and hence colorize the typewriter icon color accordingly. The generator side and the doctype XML metadata for saving text color are also adapted. It is well supported in PagePainter too. The review comments (if any) from my mentor, Tobias Deiminger, is yet to come.

This is how it works:

Following is my plan for the next phase:

  • Respect font family in Poppler

You can track my commits at

Feedbacks and suggestions are always welcome :)


GSoC :: Coding Period – Phase One (May 14th to June 12th): Initial implementation of typewriter annotation tool in Okular

Hi everyone,

The phase one of the coding period is now completed and I’m done with the initial implementation of typewriter annotation tool in Okular along with writing the integration tests for the same. I have created the revision on Phabricator and it is currently under review. Some review comments by my mentor are still to come.

As per the agreed timeline, I have implemented the fully functional typewriter tool that creates the annotation with the transparent background in all the supported document formats and the text input UI in the current implementation is the popup QInputDialog window which is in accordance with the inline note.

This is how it works:

Thanks to Tobias Deiminger, my mentor, and other Okular developers who helped me in all the ways whenever I was stuck anywhere.

The typewriter tool icon is inspired from Adobe Reader’s one and currently, we are missing a number of vital features in others annotations plus the typewriter annotation which we have planned to complete in the next phase. I need to do some fixes before proceeding to the other goals of this project.

The first 15 days of the phase one were quite busy for me as I had my college exams and so I only devoted 15 hours a week and the last 10 days were spent in figuring out how to write the tests and in writing a few of them. Following is our next plan:

  • Font color implementation in Poppler
  • Font color chooser in typewriter annotation’s settings dialog
  • Respect font family in Poppler
  • Writing integration tests

You can track my commits at

Feedbacks and suggestions are always welcome :)

Wait for the next post…


FreeText typewriter annotation WYSIWYG implementation ideas

As a part of the GSoC project, I’m working with my mentor Tobias Deiminger on implementing the FreeText typewriter annotation with click-to-type WYSIWYG editing feature in Okular to write directly on PDF page. Here we have come with the following high-level implementation ideas:

Idea 1: Dedicated annotation widgets

This is inspired by the existing FormWidget implementation. FormWidgets have a unified interface towards PageView. They scroll and scale with the viewport and let the user edit content in place. They come in different flavors, e.g. radio buttons and text input. Especially the in-place text input sounds quite like what we want for the typewriter. So let’s get a similar TypewriterWidget and making all annotations separate widgets could be a path towards better design. The typewriter can be the first doing it in real.

Idea 1.1: Custom typewriter widget rendered by the generator

With every text input keystroke, TypewriterWidget shall update the underlying annotation object. The TypewriterWidget::paintEvent shall request an up-to-date QImage with the single annotation from poppler and paint that. There is only “splash” rendering engine at work and hence the annotation is rendered by it.

PDF supports saving annotations into the document and defines the native rendering, all is done by means of poppler. Currently, in the print and PageView::paintEvent case, the generator renders annotations.

This idea probably requires something like Annotation::renderToImage to save CPU time, because Page::renderToImage says “x, y, w, h are not well-tested” and it is rather expensive. It is the best WYSIWYG approach to write directly on PDF page but implementing it might take a long time.

Idea 1.2: Use KTextEdit during user input

Here we have to relinquish WYSIWYG during user input phase. It’s more like “what you see during user input is similar to what you get when printed or page is painted”. There’s a flag “do not render this annotation by generator”. Let’s set it while user input is in progress. After finishing user input, switch to generator rendering again.

Here is the output from an experimental code:

You can see that visible differences are the downside of this idea before and after the editing. We should at least fine-tune KTextEdit to make it less notable. This way we could get rid of the position offset and have the more similar font. But FreeText ignores the font and causes the most notable difference. See

There’s another more fundamental issue in the above example: It’s just different rendering engines at work. In KTextEdit the font is rendered by the Qt paint system. After you switch to poppler, the annotation is rendered by “Splash”. Both may or may not use libfreetype (see and poppler/splash/ So algorithms like for hinting and anti-aliasing may or may not differ. And poppler uses styling rules from the PDF, whereas KTextEdit carries its own set of styling rules.

Idea 2: Don’t make typewriter UI a QtWidget

Instead, we handle input events, state, and painting directly in PageView. Keep the idea that we request a QImage with a single annotation from poppler and paint that. This makes PageView a bit worse again, but the approach is in good tradition.


There’s class MouseAnnotaiton which handles selecting, moving and resizing annotations. It was not designed to work with widgets. It just draws into the PageView. We either have to redesign it or duplicate relevant events; send one to MouseAnnotaiton, and the same to TypewriterWidget. Can’t say anything about the mess it will create.