Author Archives: somefoobar

GSoC Project comes to an end

My project under GSoC is drawing to a close. It is time to submit final evaluations.

Here is a link to all the work I have done on my feature branch:

UPDATE: The feature branch was merged with master and deleted. The commits can now be found here:

Commits with the prefix GSOC were made during the GSoC work period. (deleted)

A list of all the work that has been done in the project:

  1. The most important goal of this project was to achieve similar glyph rendering across all platforms. With the new layout engine the rendering is almost similar on different platforms. Also, I am able to reproduce same rendering bugs independent of the platform.
  2. This new layout engine uses HarfBuzz across all platforms. Currently the code can be enabled using a environment variable.
  3. The new layout engine is integrated with the rendering stack on Windows. I have used DirectWrite and GDI for final drawing of glyphs.
  4. On MacOS, the new layout engine is integrated with CoreText API for various table data retrieval and final glyph drawing.
  5. Integration on Unix based platforms is done using the existing Cairo based glyph drawing code.
  6. The new layout engine also renders Graphite fonts via HarfBuzz.

I achieved all of the goals I set for this project.

LibreOffice text rendering code has some major issues in itself, which were too large to be covered by this project. Some of them are:

  1. Using floating point arithmetic in text rendering. LibreOffice currently expresses various glyph characteristics in integers. This leads to many obscure rendering bugs (jumping characters, difference in inter-character spacing etc) and poor rendering overall.
  2. Interaction of layout code with Writer code. LibreOffice justification code is outdated and needs to be updated. For example, the justification code is responsible for incorrect rendering when using Awami Nastaliq Graphite font.
  3. Vertical text.
  4. No platform independent abstraction of font objects. LO has different classes representing a font object on different platforms.

Once these bugs are fixed, the cognitive load of the rendering code will be much less. It will be cleaner and easier to maintain. And it goes without saying that the glyph rendering will be much better.


Progress Update 2

It has been 3 weeks since my last update. I have implemented some major changes in this time. A summary:

  1. Integration of the new layout engine is complete with our unix code path. It is fully functional and rendering as expected.
  2. Integration is also complete with the Windows code path. All text layout is now done through HarfBuzz on Windows as well. This bypasses the 2 different layout implementations we have on Windows currently: Uniscribe and GDI32. Uniscribe is used for complex text layout while GDI is used for simple layout. But now all types of layout happen through HarfBuzz. I only use some methods of the GDI API for drawing the glyphs to the output device. In the future I would like to switch to DirectWrite which is more suitable for complex text layout.
  3. During the course of my project, I have discovered some bugs in the current rendering. Especially RTL text on Windows which is a mess. The good news is: these bugs do not happen with my layout engine.

That is it for this update. The only remaining platform is OSX which is next.

Progress update

It has been 2 weeks since I began my project with LibreOffice. Here is an update:

I finished writing the new layout engine. As explained in the previous post, this new engine will be used for lay-outing text across all supported platforms. Now I will integrate this new engine with the platform specific rendering code paths. Given the complexity and size of the vcl module, this will not be an easy task. I have to get the current code and the new code to work together correctly. I also have to ensure that the rendering is correct.

So that is it for this update. Will update with more progress.

GSoC at LibreOffice

I am going to be working with LibreOffice under the Google Summer of Code programme.
I am super excited about working with LibreOffice. LibreOffice is a huge project. It is used by hundreds of millions of people and is the default office suite of many Linux distributions.

My project is titled “Unification of low-level text layout using Harfbuzz”.
What is text layout? Text Layout is how the characters we type show up on the screen. But this is just a 10000ft view. Text layout and rendering are much more complex.

According to me, Text layout and rendering are crucial components for an office suite. It is one of the most visible part of an application UI. When text doesn’t look good, the UI degrades. It is especially important for word processors. LO word processor is called Writer.

In LO code, layout and rendering happens in something called the visual components library or VCL. VCL is responsible for all drawing, text rendering and operating system abstraction.

The state of the text rendering stack in LO is not exactly a pretty thing to deal with. There are different layout engines for different platforms such as Unix, MacOS, and Windows. This is a problem for the following reasons:

  1. No uniformity in rendered text across platforms. Differences introduced due to different implementations of the rendering stack. Same document opened on different platforms will look different.
  2. It is difficult to maintain so many implementations. High code complexity and higher chances of bugs creeping in. If there is a bug in the layout code, it has to be solved by someone who knows the layout code specific to that platform.
  3. Rendering is also affected by OS specific bugs.

My project is aimed at aimed at solving all these problems by unifying the layout code by creating a new layout engine which uses HarfBuzz for OpenType glyph shaping.