Development/GSoC/Ideas without a mentor

From The Document Foundation Wiki
Jump to: navigation, search

For the following ideas, you need to find a mentor. If you are interested, send a mail to our dev list. See also the list of proposed projects with a mentor.


Subpixel and stable glyph positioning tdf#103322

Fixing the bad text spacing we have due to lack of subpixel positioning. All graphics system we use (except GDI, but this is dying) support subpixel glyph positioning but we make no use of it as all our glyph positions are stored using integers and to rounding errors often accomulate resulting in bad and unstable text spacing and it gets worse on hidpi screens (resizing Writer window, for instance, causes glyphs to jump around but this shouldn’t happen).

Required skills / knowledge: C++, Reading other's code, some familiarity with fonts and text rendering is a plus
Difficulty: Hard
Potential mentors

Support multicoloured font formats tdf#104403 tdf#105488

The latest version of the OpenType specification introduced few tables that allow for having multi-colored glyphs, which have many uses the most common is color Emoji.

The simplest of them is COLR/CPAL, which use layers of normal glyphs and color palettes to assign colors to each.

Another alternative is SVG table which embeds full SVG graphic for each glyph. This one might be a trickier as instead of rendering layered glyphs with different colors we will need to render SVG graphics. We already have decent SVG support, but I’m not sure how usable is it from a low level as text rendering in VCL.

Required skills / knowledge: C++, Reading other's code, some familiarity with fonts and graphics rendering is a plus
Difficulty: Medium
Potential mentors

Make Arabic text justification more robust tdf#104921

Currently finding kashida insertion positions and the width of each is done by Writer, but the actually kashida insertion is done by VCL. However, the positions and widths are not communicated explicitly between the two; instead Writer will modify the DX array at the kashida insertion position by the required width, then VCL will guess based on the character and script whether a given DX adjustment is a regular width change or a kashida insertion. This is clearly very brittle and is a source of all kinds of hard to fix random kashida insertion bugs.

To fix this, Writer should explicitly pass the kashida insertion points and widths to VCL, separate from the DX adjustments.

Required skills / knowledge: C++, Reading other's code, ability to read Arabic is a plus but not required
Difficulty: Medium to hard
Potential mentors

Analyse and optimize SfxItemSet, make it use a STL container internally

SfxItemSet is fundamental data structure heavily used while reading documents. It is also a very ancient, nonobvious container implementation. This task would be to analyse the use of SfxItemSet in default operations, for example:

  • How many slots does an average ItemSet have?
  • How much of an average ItemSet is usually filled?
  • How many read/writes does an ItemSet perform over its lifetime?
  • Could the SfxItemSet possibly gain from using Copy-On-Write?
  • ...

And then, depending on the results of this analysis, make the implementation a wrapper around an suitable STL container.

Required skills / knowledge: C++, callgrind, debugging
Difficulty: Hard
Potential mentors

More and better tests

While there are some automated tests for LibreOffice, there are not nearly enough. The goal here is to make developers who work on the code more productive by allowing them to find regressions as early as possible.

There is some support in LibreOffice for automated tests, both at the level of unit tests, and at the level of system tests that drive a full LibreOffice instance. Currently tests can be written in C++, Java, or Python. Various new automated tests should be developed to improve the test coverage.

Tests written exclusively for Java (eg. the JUnit framework) should be ported to C++ so that they can execute much more rapidly. Similarly, tests that do remote control of an existing LibreOffice instance, should be re-factored to run inside that instance to make debugging much easier.

Required skills / knowledge: Either C++, Java, or Python; for unit level tests reading other's code
Difficulty: Medium
Potential mentors

Packaging and Window Management fixes for LibreOffice on Android

We currently have a LibreOffice desktop app for Android (see build instructions), however it has a couple of major problems. First it is not going to fit inside the 50Mb app-store limit, and retain it's wealth of functionality. So we need to package and distribute it more cleverly - this is a matter of splitting the .apk into two downloads, one smaller wrapper, and one containing the bulk of the native code see details. Secondly - we need to implement a 'window manager' to handle the problems of popup windows, multiple documents and more. This latter task involves exposing the multiple (non-popup) windows that LibreOffice creates through a different interface, and building a sidebar to switch between these bitmaps similar to that seen here for fennec.

Some code pointers for the latter task are from: this module, currently renderVCL renders a whole set of windows to a single Java Bitmap (very lamely), which we display. Instead we need to expose a list of windows which can be rendered to bitmaps. The callbackDamaged needs to notify which window was damaged, and the work needs doing in the BitmapView::onDraw or there abouts. The relevant C++ is in vcl's androidinst.cxx and should be reasonably easy to follow - see Java_org_libreoffice_experimental_desktop_Desktop_renderVCL eg.

Required skills / knowledge: C++, Java
Difficulty: Medium
Potential mentors: Michael Meeks, IRC: mmeeks mail: michael . meeks @

LibreOffice appliances

LibreOffice runs on very cheap ARM hardware now, like the Rasperry Pi (25$), Ouya (99$), the ODROID-X (129$), the Pandaboard (~180$). All of these can display Impress presentations. Multiple products can be imagined with that:

shop slide display

  • A raspberry pi board that:
    • when connected to a LAN:
    • runs a minimal HTTP server to upload a presentation
    • displays the URL to upload the presentation on the screen
    • when disconnected, starts to loop the presentation

All in all, this could be a <50$, easy to use and low energy display solution for shopping windows of small shops etc.

conference/hotel room display server (on e.g. a Pandaboard) The same as above, except that it allows a few more things:

  • constantly running the server, which allows:
    • uploading multiple presentations
    • serving the uploaded presentations as odp and pdf
    • queuing the presentations in a playlist
    • moving through the 'current' presentation with the Android remote

So a conference could get rid of all the:

  • 'my notebook doesnt work with the screen'
  • 'can I just give you my slides on a USB stick so we dont have to switch machines'
  • 'hey, I somehow have to collect the slides from everyone, and they are already on their flights home'
  • 'we want to make lighting talks, we need all the stuff on one machine somehow'

madness, for some 150-200$ plus an old Android phone. And the Android Remote is really nifty for itself, and this conveniently circumvents the setup (which is the most tricky part with it).

Given the prices conference room hardware usually has, the second one might actually be commercially exploitable.

Required skills / knowledge: Building LibreOffice on ARM, some C++, Webserver could possibly be done in Pythons httplib without too much reinventing the wheel
Difficulty: involved
Potential mentors: Matúš Kukan, IRC: matus, mail matus DOT kukan AT gmail DOT com

Improving the updater

The Updater is crucial to getting Windows (and macOS) users onto current LibreOffice versions. Unfortunately, it is rather clumsy to use currently, the worst thing being that trying to download an update opens the default browser where the user has to click another download button. There are other failings, too, e.g., that users are not presented with a short list of what to expect after the update to motivate them. Finally, each update requires going through the entire installer again.

The proposal would be to alert users whenever an update is ready, and if they then click the alert, inform them about the three to five most substantial changes between versions. If the user clicks the Update button, download the update inside the LibreOffice window. When that is done, remind the user to save their work, so LibreOffice can be closed and updated, then update it in the most silent manner possible. Finally, LibreOffice should be restarted.

Bonus points for letting only administrative users download updates, and telling restricted users that they need to have administrative access to update.

Required skills / knowledge: Building LibreOffice on Windows, C++, Microsoft Installer
Difficulty: hard
Potential mentors:

Connecting to iCloud

It would be nice if LibreOffice on the Mac could load / save files in iCloud. Most likely implementing this would also as a side-effect make it easier to interface to the new NSDocument stuff in general, too, i.e. automatic versioning etc, and make LibreOffice's document model, as visible to the user, be more in line with current Mac conventions.

Relevant documentation is included with Xcode; look for NSDocument docs and the iCloud Design Guide for starters. (But eligible students should already know what to look for, more or less;)

Possibly a new UCP ("Universal Content Provider") in LibreOffice would be needed. For an example of a recently written, fresh, UCP, see ucb/source/ucp/cmis. Unfortunately how UCPs work and interact with the other layers of LibreOffice is somewhat weirdly engineered. But for iCloud, we definitely do not want to force the user to use the silly "own" file picker, that would be very foreign to users.

Full-time access to a reasomably modern Mac, running a current OS is required. Hackintosh use is frowned upon. Membership in the Mac Developer Program is probably necessary in order to be able to actually test iCloud-using code.

And actually this task is perhaps not so useful any longer as it was some years ago, as the normal file dialogs now also show iCloud.

Required skills / knowledge: C++, Objective-C, macOS API, Reading other's code. Experience writing non-trivial NSDocument-based macOS applications required. Actually we are surprised if any student shows up with the required knowledge...
Difficulty: Hard
Potential mentors

Font handling - Substitution & Listing

A large number of user requests comes from issues with fonts. The substitution of fonts is unclear and cannot be easily configured and browsing through the list is tedious for a large number of installed fonts.

Feature request:

Required skills / knowledge
Potential mentors:

Welcome / Tip-of-the-day / What's New dialog

With every new release developers implement new features and the design team improves the default configuration. But users are not informed what's new and in case of a user-defined configuration the updated default settings will not become effective. The new dialog should inform and allow users to decide what settings to override.

Required skills / knowledge
Potential mentors:

Keyboard customization

Customization of menus and toolbars was improved during GSoC'17. But beyond a search we still provide a strange way to customize the shortcut association. Plus, the internal representation of key codes need an update to not focus on American English.

Feature request:

  • Allow other keys than from US keyboard as shortcut keys tdf#115052
Required skills / knowledge
Potential mentors:

Application Themes

LibreOffice currently uses the OS's theme to color its menubar, toolbars, sidebar, statusbar, etc. but it would be useful for the user to be able to change this default feature. The Firefox Themes integration done in LO 4.0 by Jan Holesovsky and improved in LO 4.4 by GSoC 2014's Rachit Gupta were a step in the right direction but it wasn’t a complete theme (e.g. theme background doesn’t appear in toggled buttons, theme didnt change the color of the statusbar or scrollbars, theme didn’t change the document color scheme, theme didnt change icon set, etc).

Feature request:

Required skills / knowledge
Potential mentors:

Custom Shapes

Custom shapes are today mixed with clipart in the gallery and easy to confuse with grouped objects. There is no simple way to create custom shapes and existing shapes cannot be edited internally. Custom shapes also lack on multicolor capability. The features needed are: inbuilt editor, better/more predefined shapes (e.g. arrows, mockup controls etc.), and an updated gallery.

Feature request:

Required skills / knowledge
Potential mentors:

Revamp the Navigator

The navigator lacks on interaction features, right click, double click etc. The visualization is limited and the content cluttered with various information (Writer lists chapters, tables, comments, bookmarks etc.). The proposal is to have a familiar UI as known in file browsers. This may require to implement a new Navigator from scratch (and to keep the current solution in parallel), possibly in more than one GSoC sessions.

Feature request:

  • [META] Navigator sidebar deck and floating window tdf#103030
Required skills / knowledge
Potential mentors:

Extend SfxStyleFamily by Shapes

In order to have the drawing styles at menus and toolbars we need access to it. There exists the UNO command StyleApply with the attributes Style <string> (set to "Filled Blue", for example) and FamilyName <string> which needs to be added. However, there exists no special style family for frames but frame and shape styles both belong to the family 'graphic'. The distinction between frame and shape is done by the fact, that the automatic style which is referenced by the object has a parent style in case of a frame and does not have a parent style in case of a shape. The parent style is a custom style and visible in the UI. Another problem is, that using custom styles is not implemented for shapes in Writer. Meaning, if you directly refer a custom style in the draw:style-name attribute of an object, it will make the object to a Writer-object if possible and will be ignored otherwise.

Feature request:

Required skills / knowledge
Potential mentors:


Dockable Basic navigator & Dockable Dialog property editor

  • Dockable basic navigator needs some context menu support, e.g. to be able to add/delete modules/dialogs at least

General Docking behaviour

  • Allow dockable entries to be docked anywhere ( currently what can be docked where is fixed )
  • Allow not only an item to move to any docking area but allow arbitrary numbers of windows to be docked in an area,
  • Even when say a single instance of the basic navigator window is shared between the dialog and module view we should handle

that they could be docked in different positions etc when switching between dialog and module tabs.

Dialog Editor improvements - Make dialog editor less weird

  • Move dialog in design mode and the containees should move too.
  • Better interaction with controls in the editor ( e.g. allow a label field to be edited directly in design mode )
  • We have some hidden container controls from VBA interoperability work ( Frame, MultiPage ) Enable container controls

availability in Dialog object Toolbox ( even just the a box to place the container control would be better than nothing

  • Provide scrolling in newly enabled Frame control

code pointers Dialog Editor Module Window Layout Dialog Window Layout

Required skills / knowledge: C++, Reading other people's code
Difficulty: medium
Potential mentors:


Add Impress remote capabilities for simple ad-hoc fingerpainting ad-hoc sketches

Likely better suited to GSOC -- adding it here as we collect budget extensions. The idea is basically to allow to do simple ad-hoc sketches on a tablet with the impress remote, e.g. to answer an audience question on the spot. Allowing the tablet to use the projector as a modern chalkboard.

Make master pages copyable

Currently, when in master page edit mode, the slide sorter has cut/copy/paste disabled. The task would be to add this missing functionality, and correctly handle masterpage-attached styles.

Code pointers:

Required skills / knowledge: C++, Reading other's code.
Difficulty: easy
Potential mentors: Maxime de Roucy, IRC: mderoucy, mail: mderoucy @ linagora . com


Brushes are known in Inkscape as kind of modifications to lines/connectors making it appear like a brush stroke or a small pencil. Another use case is to allow scribbled lines for UI mockups. Ideally it will also cover the request for wavy lines as some kind of post-processing where the actual y value of x is modified by some formula. This flexibility would be newly introduced with LibO.

Feature request:

Required skills / knowledge
Potential mentors:


Make Calc/Base/Chart handle small set of geographic data

Allow Calc/Base/Chart to handle regional subsets of geographic data, e.g. import/edit/draw a small region of OpenStreetMap data.

see also:

Functions sidebar

Access to functions should become easier by providing them in an extra sidebar tab.

Feature request:

  • SIDEBAR: Functions pane improvements tdf#92416
Required skills / knowledge
Potential mentors:


"Styles and Formatting" cleanup

The "Style and Formatting" toolbox is a bit overcrowded by default and comes with styles that will most likely never used. This task consists in cleaning up this dialog in several steps:

  • Hide automatically added styles by default, and show them when the styles are actually used. Such styles are the Index level styles and similar ones that aren't used unless an index is inserted in the document.
  • Move the hard-coded styles definitions to a default template
  • Create and integrate nice default styles
  • Change it so that it fits the default layout of writer, and it is not necessary to have it as a separate dialog; or make the popping up of the dialog less annoying [needs input from the UX advise]

That task description is pretty big on purpose, but I may work on it too: so that would lower the student's work.

Some code pointers:

Required skills / knowledge: C++, Reading other's code
Difficulty: medium
Potential mentors: 

ODF Formulas in Writer

Did you know Writer documents could embed formulas in some fields? The obvious case is for tables computations but this is possible with variable fields as well. The weird thing there is that the formula syntax is specific to Writer and isn't standardized. Writer can compute formulas from doc/docx files which have a syntax very closed to ODF Formulas's one thanks to ixion library. The goal of this task is to push forward this started effort to allow users to type ODF Formulas instead of the old syntax. Of course the old syntax still needs to be parsed / written for backwards compatibility.

The project could be split into several parts:

  • Clean up the formula fields computation code to delegate computation to ixion and use ODF Formulas as the internal syntax.
  • Change the UI to input ODF formulas
  • Change the ODF import and export filter to load and save both syntax. A compatibility option will probably be needed to determine which syntax to save back.

Here are some code pointers to get started in the task:

Required skills / knowledge: C++, Reading other's code
Difficulty: medium
Potential mentors:

Improvements for Table Manipulation in Writer / Table handling like at iWorks

Tables are an important feature as well in Writer. Big step ahead would be when the manipulation of tables is supported by UI means.

Some mockups:

Feature request

Required skills / knowledge
Potential mentors:

UI to modify/create Table Styles (also relevant for Calc)

Table styles have been introduced for 5.3 with a GSoC project from 2016. But there is no UI to manipulate the table styles (clicking the menu items crashed LibO).

Blog post about Table Styles:

Feature request:

  • GSoC table template: Crash on Modify custom table style or creating New (in context menu)tdf#101648
Required skills / knowledge
Potential mentors:


Use PDF import's layout recognition for other vector formats (e.g. postscript, wmf/emf)

LibreOffice PDF import employs some amount of layout recognition techniques, to generate a layout-compatible document. Leveraging this framework for other vector formats will make LibreOffice an editor not only for PDF, but also for Post``Script, EMF, XPS - whatever the successful applicant for this task chooses to import.

Code pointers:

Required skills / knowledge: C++, Reading other's code
Difficulty: medium
Potential mentors:

Implement Quattro Pro Import filter

The (binary) Quattro Pro file format is reasonably well documented - which should make this task reasonably easy. There is also an existing filter for the .wb* file formats. We really want to provide support for the much more modern .qpw file format - to allow users to migrate away to ODF. For many years Dell (for example) have shipped Quattro Pro bundled on their PCs, and there are lots of files out there, it'd be great to help those guys out.

The existing legacy qpro filter code is here and is fairly simple. We should build on this, and share as much code as possible, with an initial focus on data rescue: getting the strings, numbers, and simple formulae across - before expanding to formatting: fonts, weights etc. It should be easy enough to get something visible, and a fun thing to hack on. Reasonable specifications for the binary format are available on request for interested students.

Required skills / knowledge: C++
Potential mentors:

Implement Xara X import filter

Xara X (later renamed to Xara Xtreme) was a vector drawing applicaton for MS Windows. There also was an open source version for Linux and macOS.

The task is to implement an import filter for its native file format (.xar). A specification of the format is available, so this should be relatively easy task (no reverse-engineering required).

The filter will be based on librevenge library.

Required skills / knowledge: C++, Reading other's C++ code (to reuse libwpg/libvisio/libcdr/libmspub importer code), Ability to write code to a specification, Readiness to become famous
Difficulty: easy to medium
Potential mentors: Fridrich Strba, IRC: fridrich, mail:, Valek Filippov, IRC: frob, frob_tea, mail:, David Tardon, IRC: dtardon, mail:

Improve legacy StarOffice binary formats import filter

StarOffice 1.x - 5.x produced a variety of binary formats. These had been handled in LibreOffice by the notorious binfilter, which was removed in 4.0 since it was completely unmaintainable. Some time later, a library named libstaroffice was created with the goal to implement import of these old formats from scratch. libstaroffice is already integrated in LibreOffice. Currently it supports text, spreadsheet and drawing documents of versions 3.1-5.x (some details regarding what's supported can be found on the project's homepage).

The goal is to either improve import of the supported format versions or to add support for older version(s).

Required skills / knowledge: C++, Reading other's C++ code (to understand the existing libstaroffice code and to extract file format details from binfilter),
Difficulty: medium
Potential mentors: Laurent Alonso, mail:, David Tardon, IRC: dtardon, mail:

Implement MathType 4+ import filter

LibreOffice contains an import filter for OLE objects created by MathType 1-3 (aka MS Equation). The goal of this task is to extend this filter to handle the newer format produced by MathType 4-6 (and possibly also to improve the existing filter). The format has been partially reverse-engineered, but a lot more work will be needed.

Required skills / knowledge: C++, Reading other's C++ code, Ability to understand hex dumps, Access to MS Office with MathType 4-6 installed
Difficulty: medium
Potential mentors: David Tardon, IRC: dtardon, mail:, Caolán McNamara, IRC: caolan, mail: