- → Open Issues
- Specifies the user information and server settings for when you send form letters as e-mail messages. Open a text document, choose Tools - Options - LibreOffice Writer - Mail Merge E-mail.
- Debian Mail Merge with LibreOffice The presentation shows using LibreOffice to create a simple mail merge. Preuss 2/15/2021 Debian 10.8. Cscil 110-debian - VMware Workstation 16 Player (Non-commercial use only) Player. Activities Terminal File Edit View Search Terminal Help.
- Thorsten Behrens, IRC: thorsten mail: UX team, IRC: channel #libreoffice-design, mail: design @ global.libreoffice. Org Chart wizard. For experienced people, the current wizard distracts from the workflow and steps are not naturally implemented, for instance the range is selected first and then the type of chart.
This page lists the project ideas for Google Summer of Code, see the general info about LibreOffice and GSoC. All applicants are required to complete at least one easy hack.
All tasks on this page already indicate mentors for the task. New tasks on this page should be added only by those with the experience and time to invest in mentoring new developers.
LibreOffice / ˈ l iː b r ə / is a free and open-source office productivity software suite, a project of The Document Foundation (TDF). It was forked in 2010 from OpenOffice.org, which was an open-sourced version of the earlier StarOffice.
Note that the LibreOffice project selects GSOC projects that are well researched and show a good understanding of the scope of the problem. It is also possible to create a project proposal not based on the ideas given below, if the application of the student shows good understanding of the problem. In fact, if you apply with one of the prepared ideas below, we expect you to show you did research beyond the abstracts given below even more.
When doing that please use this template:
Please move successfully completed projects to Development/GSoC/Successfully Implemented Ideas.
Tooling
Feasibility study: building LibreOffice using meson
Currently the LibreOffice build system uses autoconf and make. Most of the complex stuff is organized in the LibreOffice-internal, high-level build system written in make, called gbuild. It offers a lot of functionality to make it easy for developers to build LibreOffice or external libraries on various platforms with a multitude of configuration options. Generally this works well for LibreOffice, until you need to either extend gbuild or even fix a bug. gbuild itself is ~18,000 lines of code and lives in solenv/gbuild/. Additionally the configure.ac file adds ~13,000 lines of mainly shell code and m4 macro calls. And since the whole make code is ~150,000 lines, it takes a lot of time to start a new build. On a first impression a lot of the gbuild functionality can be mapped to meson functionality in a straight-forward way, but as always the first 80% are the easiest.
There is already some kind of playground branch as private/jmux/meson, based on the initial work done by the meson author Jussi Pakkanen in https://github.com/jpakkane/core/commits/master. It currently builds ~80 of the ~200 internal LibreOffice libraries and completely depends on a Linux system to provide the external libraries. The branch currently builds inside a Ubuntu 20.04 / focal chroot (schroot setup can be provided). There is a rebased and fixed version available as private/jmux/meson-gsoc-2021. It's a rebase of the old branch to current master (as in 2021-04-05) and it still builds with Ubuntu 20.04.
This is currently a Linux-only idea. It seems it's a realistic goal to get LibreOffice build and running in the GSoC timeframe on Linux without depending of the possibility to build all the external libraries too.
One of the subtasks is to make Help content build independently from core.
It's possible to work with three students in parallel. The tasks are:
- Develop some meson code to build external projects (configure and MSbuild based) and start migrating externals (evaluate https://conan.io)
- Continue migrating LO libraries to Meson, especially converting still missing code generation bits
- Develop an individual target to build the LO help tools and help files
For some more information:
- Required skills / knowledge
- Python, reading makefiles, reading shell code, some C / C++ to understand compiler errors.
- Difficulty
- Medium
- Potential mentors
- Jan-Marek Glogowski, IRC: jmux, mail: glogow AT fbihome.de
- Jussi Pakkanen, IRC: jpakkane
- Olivier Hallot, IRC: ohallot, mail: olivier.hallot@libreoffice.org
- Luboš Luňák, IRC: llunak
Integrate .ui dialogs with translation tooling/string search webservice to help translators
Translators often have a hard time determining the context of a string to translate. It would be great if translators would be able to search for a string and have it presented in the context of the UI, a picture of a dialog for example.
- Required skills / knowledge
- Python (when integrating into Weblate), Java (when integrating into opengrok) or php or other suitable framework for the user-facing part, reading c++ code to identify where strings come from (not all strings are in dialogs) and GTK/glade ui definitions as the basis for the rendered dialog, scripting/makefile stuff to automate updating of the data
- Difficulty
- easy (when only limiting yourself to the glade dialogs) to medium (depending on the level of integration with the current tools: weblate as the platform where translation happens or opengrok where the source code is indexed)
- Potential mentors
- Christian Lohmaier, IRC: cloph, mail: cloph@documentfoundation.org
Select tests (or flag patches with missing tests) to run on gerrit patches based on machine learning
Inspired by Mozilla's work in this area (https://hacks.mozilla.org/2020/07/testing-firefox-more-efficiently-with-machine-learning/), it would be great to:
- extract a training set out of git, gerrit, CI and bugzilla (might need some _very early_ preparations to perhaps retain CI failure logs) by finding regressions that could have been caught by running a proper test on the respective platform, in the right configuration
- extract a training set out of git, gerrit, CI and bugzilla by finding regressions that later added a test for a feature - thus correlating code areas, and the locus for needed tests
- and training a suitable AI algorithm with the above, such that:
- CI can smartly choose the right tests to run, based on the gerrit patch (instead of running _all_ tests on _all_ configurations, which is prohibitive)
- CI can -1 patches that don't come with test loci touched, if the gerrit patch suggests it
- Required skills / knowledge
- data science/machine learning/AI active, basic & hands-on knowledge. Ability to read and write C++ code, scripting languages, and some basic knowledge of the tools used in our CI chain (Jenkins, gerrit, cppunit, ASAN/UBSAN) - many, but not all of the before might be acquired before GSoC, while joining the community prior to the application phase
- Difficulty
- Medium - provided the applicant has good machine learning/data science skills
- Potential mentors
- Thorsten Behrens, IRC: thorsten, mail: thb@documentfoundation.org
General
Tests for the VCL graphic backends
We currently have some graphic tests located here, but they are incomplete and aren't being checked. The purpose of the tests is to identify if a graphic backend works correctly, which is especially important if the backend depends on the client hardware or drivers (like for example the Skia/Vulkan backend).
Each test draws to a small surface (VirtualDevice) and evaluates if what was drawn is correct or not by looking at the pixels. As backends don't draw equally (especially when using AA), it is needed to allow for a bit of discrepancy of the values (for example sometimes a backend won't draw one pixel). In this case the test is marked as 'quirky' (acceptable result, but not what is expected).
First part of this task is to write additional tests that cover more graphic functions in VCL, then make this tests run when building a backend as well as when the user uses the backend for the first time (Skia/Vulkan for example). Also allow the user to run the tests and view the results for himself (add the UI for this).
- Required skills / knowledge
- C++, reading other's code
- Difficulty
- Medium
- Potential mentors
- Tomaž Vajngerl, IRC: quikee, mail: quikee@gmail.com
Make SVM (StarView Metafile) format independent of the VCL Metafile + tests of the format
The SVM file is a 1 to 1 dump of the content of VCL Metafile. This makes the VCL Metafile hard to modify as the SVM shouldn't change (for example to change away from the old geometry primitives in 'tools' module - PolyPolyon, Polygon, Point, Rectangle,...) so to make this possible we need to separate the two. This is also very important to allow further refactoring of VCL to make it more modern (for example native 32-bit bitmaps and surfaces and to use alpha transparency and blending of the backends and not do its own thing).
This task would include to first complete the (import/export) test of the SVM format which are located here. The second part is then separate file writing/reading of the VCL Metafile to its own classes, to make them independent.
- Required skills / knowledge
- C++, reading other's code
- Difficulty
- Medium
- Potential mentors
- Tomaž Vajngerl, IRC: quikee, mail: quikee@gmail.com
Write missing unit tests
This task is about writing missing unit tests for fixes done in the past years.
Currently we have a list of missing unit tests in here which is generated by this script, based on the LibreOffice's git log. Some of these might require writing a Python UI test instead of a cppunit test. The priority of writing the tests should roughly follow the original bug priority, which is displayed in the list.
The student taking this task will have to write as many missing tests as possible, always making sure the test fails if the fix is reverted. The student will have to evaluate what kind of tests are needed for each fix depending on similar tests already written.
- Required skills / knowledge
- C++, Python, reading other's code
- Difficulty
- Medium
- Potential mentors
- Xisco Fauli, IRC: x1sc0, mail: xiscofauli@libreoffice.org
- Ilmari Lauhakangas, IRC: buovjaga, mail: ilmari.lauhakangas@libreoffice.org
Porting / platform / infrastructure specific topics
Implement qt5 / kf5 theming using native Qt widgets (Weld interface)
Since a few years, LibreOffice has slowly created a new theming API (include/vcl/weld.hxx) while implementing it in the gtk3 backend to use native Gtk widgets. Qt5, like all other backends, just implements the drawing of QStyle themed LO widgets, which mostly look like Qt widgets, but their behavior is completely controlled / implemented by LO. This results in some bugs, which simply aren't fixable in any way inside LO. Some Qt style engines implement animation and color handling, which isn't even exposed by the QStyle API, like the default button text color in Breeze (black in LibreOffice, instead if white in KDE). The current state is documented in some kind of 'meta bug' (tdf#130857), which has some closed duplicates of backend specific problems, mainly based on some KDE settings, which change the specific behavior of a widget.
The current Weld API is Gtk specific, so some things might need some more abstraction, but otherwise it should be some straight forward job to implement the needed interfaces. This task isn't very creative, but might be interesting for people, who like to work on lower level platform code, which never fails to surprise with unexpected behavior. That can become a bit tedious to implement correctly.
For some more information:
- Qt5 Weld bug: https://bugs.documentfoundation.org/show_bug.cgi?id=130857
- Latest post on Caolans blog about Weld progress: https://caolanm.blogspot.com/2019/10/native-gtk-dialogs-in-libreoffice.html
- Required skills / knowledge
- C++, knowledge of one of the involved toolkit APIs, either Gtk or Qt will help, but this probably goes for any non-ancient API used to build GUI applications.
- Difficulty
- Medium
- Potential mentors
- Jan-Marek Glogowski, IRC: jmux, mail: glogow AT fbihome.de
- Michael Weghorn, IRC: michaelweghorn, mail: m.weghorn AT posteo.de
User Experience
The design team collected a number of ideas in in the pad http://pad.documentfoundation.org/p/UX-GSoC_Ideas. Not for all ideas mentors have committed so far. If you are interested in a task that has no mentor you would need to find someone. If the topic needs further refinement feel free to contact the UX team in order to prioritize the usability engineering. Some examples for full-featured topics:
Styles Highlighter
Styles are the essence of a text processor. And while experts love to unleash the power of LibreOffice Writer, it's at the same time a major source of nuisance. In particular when you receive documents from other people, it can be quite difficult to understand the applied formatting and to fix issues around. This project aims to improve the situation by showing in the document what styles are applied.https://design.blog.documentfoundation.org/2019/11/05/proposal-to-conveniently-highlight-and-inspect-styles-in-libreoffice-writer/
- Required skills / knowledge
- C++, Reading other's code
- Difficulty
- Varying
- Potential mentors
- Tomaž Vajngerl, Mike Kaganski
100 paper cuts
The student will solve a number of most-annoying issues and enhancement requests during the GSoC time. Issues are collected in https://nextcloud.documentfoundation.org/s/zraEHZxyCKBTNY7 with a rough estimation on effort.
If you want to apply for this, you should first solve one of the papercuts (pick an easy one) in advance.
- Required skills / knowledge
- C++, Reading other's code
- Difficulty
- Varying
- Potential mentors
- Muhammet Kara, IRC: mkara, mail: muhammet.kara AT collabora.com
Block diagrams
Most expect feature in Draw is the better implementation of block diagrams. That includes the compatibility with Visio but also simplified workflows where entered data get formatted automatically. A couple of predefined styles/presets should allow to quickly switch from one diagram style to another.
- Required skills / knowledge
- (C++, Reading other's code)?
- Difficulty
- (Medium)?
- Potential mentors
- Thorsten Behrens, IRC: thorsten mail:
- UX team, IRC: channel #libreoffice-design, mail: design @ global.libreoffice . org
Chart wizard
It's possible to work with three students in parallel. The tasks are:
- Develop some meson code to build external projects (configure and MSbuild based) and start migrating externals (evaluate https://conan.io)
- Continue migrating LO libraries to Meson, especially converting still missing code generation bits
- Develop an individual target to build the LO help tools and help files
For some more information:
- Required skills / knowledge
- Python, reading makefiles, reading shell code, some C / C++ to understand compiler errors.
- Difficulty
- Medium
- Potential mentors
- Jan-Marek Glogowski, IRC: jmux, mail: glogow AT fbihome.de
- Jussi Pakkanen, IRC: jpakkane
- Olivier Hallot, IRC: ohallot, mail: olivier.hallot@libreoffice.org
- Luboš Luňák, IRC: llunak
Integrate .ui dialogs with translation tooling/string search webservice to help translators
Translators often have a hard time determining the context of a string to translate. It would be great if translators would be able to search for a string and have it presented in the context of the UI, a picture of a dialog for example.
- Required skills / knowledge
- Python (when integrating into Weblate), Java (when integrating into opengrok) or php or other suitable framework for the user-facing part, reading c++ code to identify where strings come from (not all strings are in dialogs) and GTK/glade ui definitions as the basis for the rendered dialog, scripting/makefile stuff to automate updating of the data
- Difficulty
- easy (when only limiting yourself to the glade dialogs) to medium (depending on the level of integration with the current tools: weblate as the platform where translation happens or opengrok where the source code is indexed)
- Potential mentors
- Christian Lohmaier, IRC: cloph, mail: cloph@documentfoundation.org
Select tests (or flag patches with missing tests) to run on gerrit patches based on machine learning
Inspired by Mozilla's work in this area (https://hacks.mozilla.org/2020/07/testing-firefox-more-efficiently-with-machine-learning/), it would be great to:
- extract a training set out of git, gerrit, CI and bugzilla (might need some _very early_ preparations to perhaps retain CI failure logs) by finding regressions that could have been caught by running a proper test on the respective platform, in the right configuration
- extract a training set out of git, gerrit, CI and bugzilla by finding regressions that later added a test for a feature - thus correlating code areas, and the locus for needed tests
- and training a suitable AI algorithm with the above, such that:
- CI can smartly choose the right tests to run, based on the gerrit patch (instead of running _all_ tests on _all_ configurations, which is prohibitive)
- CI can -1 patches that don't come with test loci touched, if the gerrit patch suggests it
- Required skills / knowledge
- data science/machine learning/AI active, basic & hands-on knowledge. Ability to read and write C++ code, scripting languages, and some basic knowledge of the tools used in our CI chain (Jenkins, gerrit, cppunit, ASAN/UBSAN) - many, but not all of the before might be acquired before GSoC, while joining the community prior to the application phase
- Difficulty
- Medium - provided the applicant has good machine learning/data science skills
- Potential mentors
- Thorsten Behrens, IRC: thorsten, mail: thb@documentfoundation.org
General
Tests for the VCL graphic backends
We currently have some graphic tests located here, but they are incomplete and aren't being checked. The purpose of the tests is to identify if a graphic backend works correctly, which is especially important if the backend depends on the client hardware or drivers (like for example the Skia/Vulkan backend).
Each test draws to a small surface (VirtualDevice) and evaluates if what was drawn is correct or not by looking at the pixels. As backends don't draw equally (especially when using AA), it is needed to allow for a bit of discrepancy of the values (for example sometimes a backend won't draw one pixel). In this case the test is marked as 'quirky' (acceptable result, but not what is expected).
First part of this task is to write additional tests that cover more graphic functions in VCL, then make this tests run when building a backend as well as when the user uses the backend for the first time (Skia/Vulkan for example). Also allow the user to run the tests and view the results for himself (add the UI for this).
- Required skills / knowledge
- C++, reading other's code
- Difficulty
- Medium
- Potential mentors
- Tomaž Vajngerl, IRC: quikee, mail: quikee@gmail.com
Make SVM (StarView Metafile) format independent of the VCL Metafile + tests of the format
The SVM file is a 1 to 1 dump of the content of VCL Metafile. This makes the VCL Metafile hard to modify as the SVM shouldn't change (for example to change away from the old geometry primitives in 'tools' module - PolyPolyon, Polygon, Point, Rectangle,...) so to make this possible we need to separate the two. This is also very important to allow further refactoring of VCL to make it more modern (for example native 32-bit bitmaps and surfaces and to use alpha transparency and blending of the backends and not do its own thing).
This task would include to first complete the (import/export) test of the SVM format which are located here. The second part is then separate file writing/reading of the VCL Metafile to its own classes, to make them independent.
- Required skills / knowledge
- C++, reading other's code
- Difficulty
- Medium
- Potential mentors
- Tomaž Vajngerl, IRC: quikee, mail: quikee@gmail.com
Write missing unit tests
This task is about writing missing unit tests for fixes done in the past years.
Currently we have a list of missing unit tests in here which is generated by this script, based on the LibreOffice's git log. Some of these might require writing a Python UI test instead of a cppunit test. The priority of writing the tests should roughly follow the original bug priority, which is displayed in the list.
The student taking this task will have to write as many missing tests as possible, always making sure the test fails if the fix is reverted. The student will have to evaluate what kind of tests are needed for each fix depending on similar tests already written.
- Required skills / knowledge
- C++, Python, reading other's code
- Difficulty
- Medium
- Potential mentors
- Xisco Fauli, IRC: x1sc0, mail: xiscofauli@libreoffice.org
- Ilmari Lauhakangas, IRC: buovjaga, mail: ilmari.lauhakangas@libreoffice.org
Porting / platform / infrastructure specific topics
Implement qt5 / kf5 theming using native Qt widgets (Weld interface)
Since a few years, LibreOffice has slowly created a new theming API (include/vcl/weld.hxx) while implementing it in the gtk3 backend to use native Gtk widgets. Qt5, like all other backends, just implements the drawing of QStyle themed LO widgets, which mostly look like Qt widgets, but their behavior is completely controlled / implemented by LO. This results in some bugs, which simply aren't fixable in any way inside LO. Some Qt style engines implement animation and color handling, which isn't even exposed by the QStyle API, like the default button text color in Breeze (black in LibreOffice, instead if white in KDE). The current state is documented in some kind of 'meta bug' (tdf#130857), which has some closed duplicates of backend specific problems, mainly based on some KDE settings, which change the specific behavior of a widget.
The current Weld API is Gtk specific, so some things might need some more abstraction, but otherwise it should be some straight forward job to implement the needed interfaces. This task isn't very creative, but might be interesting for people, who like to work on lower level platform code, which never fails to surprise with unexpected behavior. That can become a bit tedious to implement correctly.
For some more information:
- Qt5 Weld bug: https://bugs.documentfoundation.org/show_bug.cgi?id=130857
- Latest post on Caolans blog about Weld progress: https://caolanm.blogspot.com/2019/10/native-gtk-dialogs-in-libreoffice.html
- Required skills / knowledge
- C++, knowledge of one of the involved toolkit APIs, either Gtk or Qt will help, but this probably goes for any non-ancient API used to build GUI applications.
- Difficulty
- Medium
- Potential mentors
- Jan-Marek Glogowski, IRC: jmux, mail: glogow AT fbihome.de
- Michael Weghorn, IRC: michaelweghorn, mail: m.weghorn AT posteo.de
User Experience
The design team collected a number of ideas in in the pad http://pad.documentfoundation.org/p/UX-GSoC_Ideas. Not for all ideas mentors have committed so far. If you are interested in a task that has no mentor you would need to find someone. If the topic needs further refinement feel free to contact the UX team in order to prioritize the usability engineering. Some examples for full-featured topics:
Styles Highlighter
Styles are the essence of a text processor. And while experts love to unleash the power of LibreOffice Writer, it's at the same time a major source of nuisance. In particular when you receive documents from other people, it can be quite difficult to understand the applied formatting and to fix issues around. This project aims to improve the situation by showing in the document what styles are applied.https://design.blog.documentfoundation.org/2019/11/05/proposal-to-conveniently-highlight-and-inspect-styles-in-libreoffice-writer/
- Required skills / knowledge
- C++, Reading other's code
- Difficulty
- Varying
- Potential mentors
- Tomaž Vajngerl, Mike Kaganski
100 paper cuts
The student will solve a number of most-annoying issues and enhancement requests during the GSoC time. Issues are collected in https://nextcloud.documentfoundation.org/s/zraEHZxyCKBTNY7 with a rough estimation on effort.
If you want to apply for this, you should first solve one of the papercuts (pick an easy one) in advance.
- Required skills / knowledge
- C++, Reading other's code
- Difficulty
- Varying
- Potential mentors
- Muhammet Kara, IRC: mkara, mail: muhammet.kara AT collabora.com
Block diagrams
Most expect feature in Draw is the better implementation of block diagrams. That includes the compatibility with Visio but also simplified workflows where entered data get formatted automatically. A couple of predefined styles/presets should allow to quickly switch from one diagram style to another.
- Required skills / knowledge
- (C++, Reading other's code)?
- Difficulty
- (Medium)?
- Potential mentors
- Thorsten Behrens, IRC: thorsten mail:
- UX team, IRC: channel #libreoffice-design, mail: design @ global.libreoffice . org
Chart wizard
For experienced people, the current wizard distracts from the workflow and steps are not naturally implemented, for instance the range is selected first and then the type of chart. Over the modules we have different ways to insert charts plus the wizard design is inconsistent with other dialogs which are tabbed. Mockups
- Required skills / knowledge
- C++, UI, UNO, reading other's code
- Difficulty
- Hard
- Potential mentors
- Katarina Behrens, IRC: bubli mail: bubli @ bubli . org
- UX team, IRC: channel #libreoffice-design, mail: design @ global.libreoffice . org
Multi-color gradient
While the area fill style dialog has been reworked nicely the ability to deal with more than two steps for gradients is missing. Furthermore, gallery items with gradients that consists of more than two colors or non-linear gradients are interpreted as a collection of lines when ungrouped making a modification impossible. First analysis showed that multi-stop gradients are loaded well but not visualized as it. The project would need to implement the draw routines as well as the UI control in the area dialog as suggested.
- Required skills / knowledge
- (C++, Reading other's code)?
- Difficulty
- (Medium)?
- Potential mentors
- Tomaž Vajngerl, IRC: quikee, mail: quikee @ gmail.com
- UX team, IRC: channel #libreoffice-design, mail: design @ global.libreoffice . org
Improve OpenPGP encryption experience
With LibreOffice 6.0, there's experimental PGP/GPG encryption support. A number of shortcomings are there still, that make using this cool feature unnecessarily hard, e.g. selecting recipients anew for every safe, or finding the right keys. Keyrings can get potentially infinitely large, so smart searching / traversing / filtering is needed. Additionally, some asynchronous querying would be great, as currently it takes several minutes to retrieve all keys for large keyrings.
- Required skills / knowledge
- C++, Reading other's code, some idea about public key crypto
- Difficulty
- Varying
- Potential mentors
- Thorsten Behrens, IRC: thorsten mail: thb@libreoffice.org
- UX team, IRC: channel #libreoffice-design, mail: design@global.libreoffice.org
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.
Libreoffice Mail Merge Tutorial
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
- 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
- Difficulty
- Varying
- Potential mentors
- (?)
Base
Basic
Draw
Impress
SmartArt editing in Impress
SmartArt is a nice feature that allows users to quickly add charts / diagrams to presentations. We have a partial implementation as an experimental feature; the task of this GSoC would be to finish it.
At the moment, we are able to import SmartArt as a stream of shapes that is available in the pptx presentations generated by MSO 2010. We are also able to create the shapes when the stream is not available in case you enable the Experimental features Tools ▸ Options. Unfortunately:
- The rendering of such shapes is much worse than if we use the pre-rendered stream
- We are unable to edit the imported SmartArt
This task should first focus on improving the rendering of the shapes themselves, and then, when the student gets more familiar with the code, should add user interface for SmartArt editing.
The current experimental SmartArt import lives in oox/source/drawingml/diagram/*. The commit that introduced the functionality is Import SmartArt graphics to Impress.
Further information: The related bug in the LibreOffice bug tracker is: tdf#37932. An external extension (not nicely integrated) trying to implement at least some SmartArt functionality: SmART (Extensions/SmART Gallery)
- Required skills / knowledge
- C++, Reading other's code.
- Difficulty
- Difficult
- Potential mentors
- Thorsten Behrens, IRC: thorsten, mail: thb@documentfoundation.org
- Jan Holesovsky, IRC: kendy, mail: kendy@collabora.com
Attach animations to styles
Currently, Impress styles control most of the visual shape appearance, but not the slideshow animation effect. Which is a pity, as the styles concept is pretty powerful inside LibreOffice, and provides a nice way to change animation settings and type for a great number of objects simultaneously. For a slightly different view onto the same problem, see this bug report, and this one from the LibreOffice side.
Original patch from GSoC 2010: https://cgit.freedesktop.org/libreoffice/build/tree/patches/dev300/sd_effects_styles.diff?h=master-backup
- Required skills / knowledge
- C++, Reading other's code
- Difficulty
- Hard
- Potential mentors
- Thorsten Behrens, IRC: thorsten, mail: thb @ documentfoundation . org
- Katarina Behrens, IRC: bubli, mail: bubli @ bubli . org
Rework Impress slideshow to use DrawingLayer primitives
The Impress slideshow, while being designed to only interact with Impress via interfaces, had to resort to an ugly hack to be able to render all Impress content. That was ok back in the day, but is becoming a liability these days. Nowadays, what one want to use is the DrawingLayer Primitives (https://wiki.openoffice.org/wiki/DrawingPrimitives), which means porting over slideshow/source/engine/shapes/* to use this kind of abstraction, instead of the StarView Metafile previously in use.
- Required skills / knowledge
- C++, Reading other's code.
- Difficulty
- Difficult
- Potential mentors
- Thorsten Behrens, IRC: thorsten, mail: thb @ documentfoundation . org
Mix and Merge Impress presentations
For the professional slide jockey, mixing a new presentation out of existing slide decks is a common task, that unfortunately Impress does not support very well. This task is about providing, possibly stand-alone, functionality to:
- display lots of presentation files conveniently, possibly with tagging/searching functionality
- out of existing slides, quickly create a new presentation
- provide functionality to conveniently exchange / homogenize slide layouts and/or master pages, such that new presentation has consistent look
- as a bonus task, be able to create virtual slide decks, by referencing other files, and have the resulting presentation automatically update, once the referenced slides are
- can be built-in to Impress, stand-alone (but then portable across all our platforms), or web-based.
Code pointers:
- this needs some ODF processing when being stand-alone or web-based, e.g. via https://github.com/lpod/lpod-python
- or you make it built-in, then the copying-slides-around functionality is here: https://opengrok.libreoffice.org/search?refs=InsertBookmarkAsPage
- Required skills / knowledge
- ODF, UX, possibly c++, possibly Python, possibly web frameworks
- Potential mentors
- Thorsten Behrens, IRC: thorsten, mail: thb @ documentfoundation . org
Calc
Implement interface for external data source import into Calc
With more and more data in different forms it becomes more and more challenging to visualize and evaluate them. Calc could be an amazing tool to allow inspecting existing data. To allow that we would need an interface to import and more importantly update data from external data sources. The interface should be modelled similar to how the orcus interface is currently implemented and the data should be stored inside of a ScDBData (a database range). The interface would then be used together with either an existing document where you mark a range for the external data or a template document that is automatically filled. The initial work on providing some structure has already been done in sc/source/ui/dataprovider/ and in sc/source/ui/miscdlg/dataproviderdlg.cxx
This task is about extending the existing data providers and data transformations, implementing an usable UI for the feature and start working on storing the information in a file.
- Required skills / knowledge
- C++, Reading other's code, debugging
- Difficulty
- Medium
- Potential mentors
- Markus Mohrhard, IRC: moggi, mail: markus.mohrhard@googlemail.com
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
- Difficulty
- Medium
- Potential mentors
- Markus Mohrhard, IRC: moggi, mail: markus.mohrhard@googlemail.com
Implement table styles
Calc so far lacks real table styles, which for example can be seen in Impress tables, with formatting of header row, header column, banded rows and columns, total row, rightmost column, ...
The existing old technology Format → AutoFormat Styles are visually similar, but very inefficient in that they apply individual attributes to individual cells, which a) is slow, and b) bloats the document size, and also can't cope with hidden rows or columns to keep a visually stable table style layout.
See also tdf#132780
- Required skills / knowledge
- C++, Reading other's code, Debugging, Understanding the concept of different layers of cell attribution, Having an idea of how a single attribute with one value could be used for this
- Difficulty
- Hard
- Potential mentors
- Eike Rathke, IRC: erAck, mail: erackredhat.com
Writer
Document Themes
Document themes are a simple way to allow users to quickly & consistently restyle the entire document. There is an implementation of this in MSO, and also Calligra plans to something in this regard, so this task actually consists of 2 parts:
- Implementing user interface for the feature
- Implement the ODF support for that
More ideas about the feature you can get by reading http://blogs.msdn.com/b/jensenh/archive/2006/02/22/537054.aspx and https://blogs.kde.org/2011/12/14/fruits-css2-shared-themes .
The import code for DOCX is here: https://cgit.freedesktop.org/libreoffice/core/tree/writerfilter/source/ooxml, you might need to change also https://cgit.freedesktop.org/libreoffice/core/tree/writerfilter/source/dmapper
For XLSX and PPTX, it resides in https://cgit.freedesktop.org/libreoffice/core/tree/oox/source
- Required skills / knowledge
- C++, Reading other's code, reading specifications :-)
- Difficulty
- Hard
- Potential mentors
- Jan Holesovsky, IRC: kendy, mail: kendy @ collabora . com
- Tomaž Vajngerl, IRC: quikee mail: tomaz.vajngerl @ collabora.co.uk
Implement table styles DOCX support
Writer currently supports the use of table styles and saving them to ODF format.On the other hand table styles found in DOCX files are imported as direct table cell formatting.This is only a temporary solution and causes loss of formatting (dynamic banding) upon editing the table. Another downside of converting formatting defined in table styles is that it significantly reduces the file opening performance of Writer.Bug report: https://bugs.documentfoundation.org/show_bug.cgi?id=101757
This task aims to build on the results of the earlier GSoC project that brought the functionality and ODF support.
- Major steps of the project
- Implement DOCX import
- Remove existing style-based formatting conversion to direct formatting
- Extend the existing table style feature as necessary. For example an important, not yet supported property is style inheritance.
- Code pointers
- Current table style import: https://opengrok.libreoffice.org/xref/core/writerfilter/source/dmapper/StyleSheetTable.cxx
- Documentation of the OOXML specification for table styles: http://www.officeopenxml.com/WPstyleTableStylesCond.php
- ODF specification for table styles: https://docs.oasis-open.org/office/OpenDocument/v1.3/csd03/part3-schema/OpenDocument-v1.3-csd03-part3-schema.html#element-table_table-template
- There is a comprehensive example document attached to https://bugs.documentfoundation.org/show_bug.cgi?id=118812
- Required skills / knowledge
- C++, Reading other's code
- Difficulty
- Hard
- Potential mentors
- Laszlo Nemeth mail: nemeth at numbertext dot org
Filters
Improve Zoner Draw import filter
libzmf, a library for import of Zoner Draw documents, was implemented as a GSoC 2016 project. Currently the library only supports documents created by versions 4-5. There are two goals in this task:
- handle some of the missing features (blending, warping of the bounding rectangle);
- add support for the file format produced by versions 2-3.
Both formats have been almost completely reverse-engineered.
- Required skills / knowledge
- C++, Reading other's C++ code (to understand the existing libzmf code). Python (for OLEToy) is welcome, but probably won't be needed
- Difficulty
- Medium
- Potential mentors
- David Tardon, IRC: dtardon, mail: dtardonredhat.com
Improve Adobe Pagemaker import filter
libpagemaker, a library for import of Adobe Pagemaker documents, was implemented as a GSoC 2013 project. In the current state, the library only supports documents created by versions 6.5-7.0 on Windows. Documents of version 6.0 should be opened more-or-less correctly, but the support has never been specifically tested. Documents created on Mac are never opened correctly because of many oversights in the code.
The goals of this taks are to fix import of Mac 6.5-7.0 files, implement some missing features and add support for older versions, both Mac and Windows (starting at 6.0 and proceeding to older ones until we run out of time :-)
We will use OLEToy for any necessary reverse-engineering. We will also create documents for regression testing for all versions we add support for.
- Required skills / knowledge
- C++, Reading other's C++ code (to understand the existing libpagemaker code). Python (for OLEToy)
Libreoffice Mail Merge Custom Fields
- Difficulty
- Medium
- Potential mentors
- David Tardon, IRC: dtardon, mail: dtardonredhat.com
- Fridrich Strba?, IRC: Fridrich, mail: fridrich.strbabluewin.ch
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.
Rust UNO Language Binding
UNO's cross-language abilities are implemented by bridging between various language-specific environments and a binary runtime representation (with a C API). Next to C++, Java, and Python, it would be great to have such a bridge also for a great language like Rust.
One aspect is to use Rust FFI to interface with the binary UNO C API. Another is to design the Rust representations of the various UNO constructs (its data types; objects with their multiple interfaces and methods; services and singletons), so that this language binding can not only be used to interact with existing LibreOffice services written in other languages, but also to create new services in Rust. A third aspect could be to create a pure Rust implementation of the UNO remote bridge protocol.
Some documentation pointers are:
Some code pointers are:
bridges/source/jni_unoas an example of an in-process UNO bridge (for Java, via JNI)binaryurpas an example of a remote UNO bridge (in C++)
- Required skills/knowldege
- Rust, interfacing to low-level C/C++, working against formal specifications
- Difficulty
- Medium to hard
- Potential mentors
- Stephan Bergmann, IRC: sberg, mail: sbergman @ redhat . com
- Michael Stahl, IRC: mst___, mail: mst AT libreoffice DOT org
- Bjoern Michaelsen, IRC: Sweetshark, mail: bjoern.michaelsen AT canonical DOT com
LUA UNO Language Binding
UNO's cross-language abilities are implemented by bridging between various language-specific environments and a binary runtime representation (with a C API). Next to C++, Java, and Python, it would be great to have such a bridge also for a small, lightweight scripting language like LUA.
LUA is small (few K lines of C), and written with the goal of embedding in mind:
Besides hooking LUA up with LibreOffice's UNO subsystem, a taker for this project would need to map the various UNO constructs (its data types; objects with their multiple interfaces and methods; services and singletons) to suitable LUA types, so that this language binding can not only be used to interact with existing LibreOffice services written in other languages, but also to create new services. LUA should be expressive enough to permit that (its dynamic typing helps a lot there), just for exceptions and error handling, some extra thoughts might be needed:
- Basic might be a good starting point: https://wiki.openoffice.org/wiki/Documentation/DevGuide/ProUNO/Basic/Exception_Handling
- but see this article for LUA error handling concepts: http://lua-users.org/wiki/ErrorHandling
Some code pointers are:
bridges/source/jni_unoas an example of an in-process UNO bridge (for Java, via JNI)binaryurpas an example of a remote UNO bridge (in C++)
- Required skills/knowldege
- LUA, interfacing to low-level C/C++, working against formal specifications
- Difficulty
- Medium to hard
- Potential mentors
- Michael Stahl, IRC: mst[_]*, mail: mst AT libreoffice DOT org
- Thorsten Behrens, IRC: thorsten, mail: thb AT libreoffice DOT org
- (Bjoern Michaelsen, IRC: Sweetshark)
Ideas without a mentor
A number of ideas from previous years can be found at the Development/GSoC/Ideas without a mentor page. Please note that you need to find a mentor willing to mentor the task. There is no guarantee that anyone in the community is going to mentor one of these tasks this year.
Welcome to this article here we will discuss the mail merge option in LibreOffice. Here we provide a detailed guide about how to perform the mail merge in LibreOffice.
At first, we will discuss what is the mail merge – actually mail merge is a kind of feature through which we can send the same letters to multiple persons.
Now we will discuss about how to set the mail merge in libreoffice step by step.
Step 1:
In the first step just write the letter properly. Mention the recipient's name, mention address, subject, and the body of the document.
After the completion of writing the letter then open the mail merge option. And in LibreOffice, the mail merge option is given under the tools menu.
Just click on the tools menu and click on mail merge wizard option.
Step 2:
In this step, a dialogue box will appear in front of us. You have to select the option from there such as – use the current document, create a new document, and start from exiting document. Or otherwise, you can also start from the template.
For most of the cases we starts from use from the current document .
Step 3 :
Libreoffice Mail Merge Steps
In this step, we have to select the document type. Two options are provided here one is a letter and another is an email message. Here we will select a letter for our option.
Step 4 :
In this step we have to insert the address block. From here we have to select the recipient address format.
Just click on the select different address list and click on the add option to create a new address list. After the creation of the list then presses the ok button.
Step 5:
Now in this step, we have to select the salutation part, by default it is checked into dear Mr name, but we can also change this salutation format according to our requirements. And now click on the next option.
Step 6 :
In this part, we have to adjust the layout option, and we have to select the format, from here we can also move or down the layout or also can align the layout. And now just click on the finish option.
Step 7 :
This is actually the final step and in this step, we have to just click on the edit individual document option. This will automatically appear as the mail merges into our document.
Conclusion:
This article is all about how to do mail merge in LibreOffice, I hope you have liked this article and if you have any kind of query then please ask me at pmitra459@gmail.com.
And please subscribe our website by clicking on the notification icon for this kind of informational article.
Also read
