Development/GSoC/Ideas without a mentor

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.

UNO
UNO is the LibreOffice component model, cross-language and intra- as well as inter-process. It is somewhat similar to Corba and COM. It is used to extend LibreOffice via document-related scripts and more general extension packages, as well as to use LibreOffice functionality remotely from another process.

Move Beanshell and Rhino to extension
Currently 2 scripting language implementations that run on the JVM and depend on the Java Scripting Framework are bundled with LO: Beanshell and Rhino (JavaScript)

These have few users, so it would make sense to un-bundle them into an extension (or several?), which hopefully should require little maintenance once it exists.

This is in core.git in these directories: external/rhino, external/beanshell, scripting/java, scripting/Jar*.mk

There is also a "ScriptProviderForJava.jar".

An important part of un-bundling is that the LO build system is not available for building the extension so some new build system has to be added; currently patched Beanshell and Rhino are built with Ant.

For inspiration, see the XSLT 2 transformer extension that was created some 10 years ago: https://github.com/dtardon/xslt2-transformer

TODO: it's not clear whether to unbundle ScriptProvider.jar as there may be an "oorexx" extension using it.

Documentation pointers: scripting module readme DevGuide Extensions chapter


 * Required skills/knowledge: Java, Extensions


 * Size: 175 hours


 * Difficulty: Easy


 * Potential mentors

Improve UX for deaf people
This idea/solution aims at a better experience of using LibreOffice for people with hearing impairments (deaf). Offering the option of tooltips in a sign language format (like LIBRAS, ASL, LSF ..) instead of texts. Example: When the mouse is over the "save" option, a tooltip sign will be displayed instead of the tooltip "Save (Ctrl + S)" in text format.

This idea/solution potentially reaches around 500 million of people (OMS data) worldwide with hearing impairment (deaf people), helping a community that faces numerous difficulties in the process of adaptation to a world totally driven towards written/spoken. Brazillian example: Although LIBRAS (Brazillian Sign Language) is the second official Brazilian language, cell phones and computers do not have LIBRAS support, whereas for a hearing impaired person the first - and almost always the only language - is LIBRAS.

There are other sign languages ​​besides that used in the Brazilian example, like ASL (American Sign Language) and LSF (French Sign Language), others.

There is currently a fork of LibreOffice (https://gitlab.com/LabIS-UFRJ/LIBRASOffice) that captures 'rHelpText' which is passed to the 'void ImplShowHelpWindow (...)' function in 'vcl/source/app/help.cxx' (https://gitlab.com/LabIS-UFRJ/LIBRASOffice/LASOBack/-/blob/master/vcl/source/app/help.cxx#L494) and save to a LOG for an external program to display the signals as tooltips. The signals are displayed exactly like tooltips, but appear in the lower right corner of the screen instead of immediately under a button.

This functionality can be offered for all sign languages ​​around the world, and could be distributed through translation packages


 * Required skills / knowledge: C++, UNO API (?), Reading other's code


 * Size: Large


 * Difficulty: Hard (?)

(?)
 * Potential mentors

In-app rating / un-structured feedback
Some of our users want to provide feedback - but are too busy to create UI accounts. We should create something like Mozilla's input - https://wiki.mozilla.org/Firefox/Input/Feedback_Strategy that allows a user to provide a * rating, some un-strutured text input, and optional E-mail for a reply and the ability to attach a file if they want to. That way we can correlate *'s against versions and find problems more quickly - and depending on volume can triage that to see if anything jumps out: as well as auto-harvesting documents for our systematic crash-testing.


 * Required skills / knowledge: C++, Reading other's code


 * Size: Large


 * Difficulty: Varying


 * Potential mentors

Improve usability and visibility of AutoText feature
AutoText  in LibreOffice Writer is a fantastic and powerful feature, which hasn't received much developer attention for many years. The usability of the features has tremendous problems and the feature is not sufficiently visible for the user. Also, the way how saved AutoText snippets are presented to the user, how they can be found and selected could be substantially improved. The GSOC project is about improving usability of the feature and bringing it up to par to the year 2022. There are also a number of outstanding bugs (meta-bug ) concerning AutoText that need to be fixed along this project.

For more details on UX issues with AutoText, see bug and.


 * Required skills / knowledge: C++, Reading other's code


 * Size: Medium


 * Difficulty: Medium


 * Potential mentors

Subpixel and stable glyph positioning
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
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
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

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 @ collabora.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.


 * Blog post: Dealing with Missing Fonts https://design.blog.documentfoundation.org/2016/10/21/dealing-with-missing-fonts/

Feature request:
 * [META] Font bugs and enhancements


 * Font subsitution
 * Bundled fonts
 * Options (hide unused)
 * Smart fonts; ODF 1.3

Required skills / knowledge Difficulty: 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

Required skills / knowledge Difficulty: 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:
 * https://wiki.documentfoundation.org/Development/GSoC/Ideas#Application_Themes
 * https://docs.google.com/document/d/1J_aogLuQThqhvT0R2em27Vpew-SLAQgpH5TbNTgXPZM/edit

Required skills / knowledge Difficulty: 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.


 * New gallery https://wiki.documentfoundation.org/Development/GSoC/Ideas#Revamp_the_gallery_tool
 * Blog post on Shapes sidebar: https://design.blog.documentfoundation.org/2015/04/02/libreoffice-design-session-shapes/

Feature request:
 * Multi color:
 * Shape creation:
 * More shapes:

Required skills / knowledge Difficulty: 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.


 * Blog post: https://design.blog.documentfoundation.org/2016/07/31/how-the-navigator-may-support-object-handling-in-libreoffice-draw/

Feature request:
 * [META] Navigator sidebar deck and floating window

Required skills / knowledge Difficulty: 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 (set to "Filled Blue", for example) and FamilyName 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:
 * Extend SfxStyleFamily by Shapes

Required skills / knowledge Difficulty: Potential mentors:

Basic
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 that they could be docked in different positions etc when switching between dialog and module tabs.
 * 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

Dialog Editor improvements - Make dialog editor less weird availability in Dialog object Toolbox ( even just the a box to place the container control would be better than nothing
 * 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
 * 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:
 * InsertBookmarkAsPage is a good starting point.

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

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


 * Brush tool:
 * Wavy lines:

Required skills / knowledge Difficulty: Potential mentors:

Support charts in orcus
Orcus is an external library for importing spreadsheet formats that is already used for a few features in Calc. However for now we are limited to spreadsheet support and we should extend support to charts. Orcus works by providing an interface of virtual methods that must be implemented on the client side. We try to keep the interface format independent and try to always support at least OOXML and ODF.

If the time permits we should also work on some experimental integration of the chart import code into LibreOffice.

The spreadsheet interface is mostly in include/orcus/spreadsheet. The chart interface should be similar.


 * Required skills / knowledge: C++, Reading other's code, debugging, Reading specifications


 * Size: 350 hours


 * Difficulty: Medium


 * Potential mentors
 * Markus Mohrhard, IRC: moggi, mail: markus.mohrhard@googlemail.com

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: https://blog.documentfoundation.org/blog/2016/09/19/prototypefund-an-opportunity-for-german-freelance-developers/

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

Feature request:
 * SIDEBAR: Functions pane improvements

Required skills / knowledge Difficulty: 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:
 * Popup menu handler of the tree list box in the dialog: https://opengrok.libreoffice.org/xref/core/sfx2/source/dialog/templdlg.cxx#2177
 * Popup menu creation: https://opengrok.libreoffice.org/xref/core/sfx2/source/dialog/templdlg.cxx#2236
 * Writer default styles hard-coded attributes: https://opengrok.libreoffice.org/xref/core/sw/source/core/doc/poolfmt.cxx#1079

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:
 * SwTableFormula is the class handling the table formulas computation: https://opengrok.libreoffice.org/search?refs=SwTableFormula
 * SwInputWindow is the class for the formulas input bar: https://opengrok.libreoffice.org/xref/core/sw/source/ui/inc/inputwin.hxx#58

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: https://docs.google.com/document/d/1D212Ihf8BYVOa1VjSPifq4sO_Cq4CZPhC0vya68zk3c

Feature request
 * UI for table manipulation:
 * Permanent auto size:
 * Better col width adjustment

Required skills / knowledge Difficulty: 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.

Blog post about Table Styles: https://design.blog.documentfoundation.org/2015/12/13/style-your-tables/

Feature request:
 * GSoC table template: Crash on Modify custom table style or creating New (in context menu)

Required skills / knowledge Difficulty: 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:
 * current pdf import layout handling: https://cgit.freedesktop.org/libreoffice/core/tree/sdext/source/pdfimport/tree/drawtreevisiting.cxx

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++ Difficulty:easy 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, 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: