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 https://bugs.freedesktop.org/show_bug.cgi?id=107151#c3 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 Deimingerhttps://bugs.freedesktop.org/attachment.cgi?id=140963.

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 :)

 

robstat7

 

Leave a Reply

Your email address will not be published. Required fields are marked *