GSoC Ideas

From The Document Foundation Wiki
Jump to: navigation, search

This page lists the project ideas for Google Summer of Code, see the general info about LibreOffice and GSoC. Feel free to pick any of the tasks listed in the Programming Tasks section of the EasyHacks page, but in that case you need to ask for mentors on the development mailing list if none is defined. 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.

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:


=== Title of the task ===

Some detailed description of the things to accomplish.
Don't hesitate to provide details if you have some like code pointers, links to specifications, etc.

;Required skills / knowledge: C++, Reading other's code, and any other useful skill required go here.

;Difficulty: Range among easy, medium, hard

;Potential mentors
:''Joe Devel'', IRC: jdevel, mail: joe@devel.org

Please move successfully completed projects to Development/GSoC/Successfully Implemented Ideas.

Contents

General

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
Khaled Hosny, IRC: KhaledHosny, mail: khaledhosny@eglug.org

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
Khaled Hosny, IRC: KhaledHosny, mail: khaledhosny@eglug.org


Add a DSL to the UI testing and improve the generated log file

The UI testing is one of our newest additions to our testing frameworks. The code is split between a C++ layer wrapping our GUI toolkit and a python test framework with the actual tests. Recently some work was done to start logging UI actions when they happen and generate log files that are close to the python test files. The next step is to define a domain specific language (DSL) that we can use to represent the UI testing actions and instead of generating log files generate these files. Additionally with a replay mode in the python framework it should be possible to replay the UI actions automatically. Such a feature would allow to easily add new tests and make bug reporting much easier.


As part of this GSoC project the DSL, the logging to the DSL format and the replay should be implemented. If there is enough time or the need for it the C++ layer should be extended to support more UI elements.


Most of the python part of the framework can be found in the uitest/ module.

Most of the commits related to the framework are prefixed with uitest: and can be found with this git search.

The file with most of the C++ wrappers can be found here.


Required skills / knowledge
Python, a bit of C++, an idea how to design a DSL
Difficulty
Medium
Potential mentors
Markus Mohrhard, IRC: moggi, mail: markus.mohrhard@googlemail.com

Improve touch screen experiences on Windows tdf#85677 tdf#104983

Since Windows 8, Windows introduced native support for touch screen, but on Windows touch screen LibreOffice does not well performanced, for example, when dragging a page on Writer does not scrolling a page, instead is highlighting texts.

Required skills / knowledge
C++, Reading other's code and some documentations related to relevant APIs.
Difficulty
Hard
Potential mentors
Joe Devel, IRC: jdevel, mail: joe@devel.org

Porting / platform / infrastructure specific topics

LibreOffice Online

LibreOffice online has developed significantly during the last year, but there is still a lot to do there. This task will include changes in the LibreOfficeKit, and in the web/JavaScript part too.

The main focus will be on making the features knows from the desktop version available in the Online version too; like the pivot tables, or other.

The online work takes place mostly in the online.git reporsitory: https://cgit.freedesktop.org/libreoffice/online/

Required skills / knowledge
C++, JavaScript optional.
Difficulty
Medium
Potential mentors
Jan Holesovsky, IRC: kendy mail: kendy @ collabora.com

LibreOffice for Android

LibreOffice works nicely on Android these days, but there are stil many things to improve and fix. This task will focus on the Android Most Annoying Bugs:

https://bugs.documentfoundation.org/showdependencytree.cgi?id=84726

and also on new features, like printing.

Required skills / knowledge
C++, Java.
Difficulty
Medium
Potential mentors
Miklos Vajna, IRC: vmiklos mail: vmiklos @ collabora.co.uk
Tomaž Vajngerl, IRC: quikee mail: tomaz.vajngerl @ collabora.co.uk

KDE4: use Qt4 widgets and abstraction layer for painting and event filtering

LibreOffices KDE4 VCL backend is just a shim layer around the X11 / Xlib VCL backend and next to TDE the only user. It provides a native file picker but otherwise just tryes to emulate the KDE look using low level paint methods. This results in multipe problems:

  • No platform abstraction; directly uses Xlib for drawing and event processing
  • No way to port to Qt5
    • Qt5 internally uses XCB, but the main problem is
      • QPixmap doesn't export the internal X11Pixmap anymore
      • No real way to do native X11 drawing - you want to use QPainter
    • You don't want to port an already dated X11 backend to XCB
    • The Cairo based Svp / headless VCL won't integrate well with Qt5, better use native QPainter
      • Cairo has a Qt / QImage based backend, but this can just use Qt4 or Qt5, as symbols clash and the backends are static and no loadable plugins
      • Would introduce a 2nd render path on Linux; you could probably start an implementing alternative Svp using QPainter?
    • No more native event filtering
    • No Wayland support
  • No modal native dialogs
    currently doesn't use QWidgets, so there is no way to implement the modal handling for the file picker. Gtk+ wraps the LO widgets in GtkWidgets, so modal native dialogs work.
  • No native widgets
    The KDE4 VCL plugin just uses some painting methods to render stuff, but there is some stuff we can't handle correctyl this way, like Oxygen menus. The Gtk+ plugin actually uses GtkWidgets to draw themself, giving a more native look and feel. Also it implements the SalMenu.
  • Slow painting,
    as all drawing operations are performed on a single image and copied using Xlib function. This image is always destroyed and there is basically no caching. Gtk+ keeps a caching widget per type around. This also isn't portable to Qt5
  • Use KIO internally
    Currently LO sets "X-KDE-Protocols=file,http,ftp,webdav". Even smb was included for some time. But actually this depends on the native load / save dialog settings, and even the VCL backend, because the KDE4 file picker / VCL backend doesn't support neither smb nor webdav without KIO.
TODOs
Documentation
see the next item KDE5: port KDE4 plugin to KF5
Code pointers
Required skills / knowledge
C++, Reading other's code
Difficulty
High
Potential mentors
Jan-Marek Glogowski, IRC: jmux, mail: glogow @ fbihome . de

KDE5: port KDE4 plugin to KF5

This work depends on the previous item KDE4: use Qt4 widgets and abstraction layer for painting and event filtering. After talking to KF5 developers, especially Martin Gräßlin, we concluded there wouldn't be much of a point to port KDE4 while it's based on X11 native Xlib calls.

Jmux comment: to get a better impression of the KF5 codebase and library layout I did an initial port, but this won't work, as it can't do any painting and the integration in the X11 event queue is also broken / commented out. If you really want to start this during a GSoC I would recommend you already know your way around KF5 + Qt5, or expect a steep learning curve.

TODO
Documentation
Code pointers
https://cgit.freedesktop.org/libreoffice/core/log/?h=private/jmux/kde5 (compiles but doesn't run)
Required skills / knowledge
C++, KF5 + Qt5, Reading other's code
Difficulty
Medium
Potential mentors
Jan-Marek Glogowski, IRC: jmux, mail: glogow @ fbihome . de

User Interface

The design team prepared a list with interesting topics 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.

Improvements to Notebookbar

Notebookbar reuses UI files definition known from Gtk+ (.ui files) as created by the Glade tool for upper part of the LibreOffice window, giving lots of freedom to the designers how to organize the UI. Current implementation has advanced during the last GSoC, but it is still incomplete: The content is cropped on resize, theming is not respected, and new functions such as style dropdown haven't been introduced yet. Beyond that, the customization via Glade is not suitable for normal users, and quick customization like toolbutton on/off is not possible.

Required skills / knowledge

  • C++, Reading other's code

Difficulty

  • Medium

Potential mentors

  • Jan Holesovsky, IRC: kendy mail: kendy @ collabora.co
  • UX team, IRC: channel #libreoffice-design, mail: design @ global.libreoffice . org

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

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.

Required skills / knowledge

  • (C++, Reading other's code)?

Difficulty

  • (Medium)?

Potential mentors

  • Bjoern Michaelsen, IRC: Sweet5hark mail:
  • UX team, IRC: channel #libreoffice-design, mail: design @ global.libreoffice . org

Blurry shadows

In LibreOffice the shadows are just a copy of the object. Blurring with some options is missing, and well known in competitive open-source tools like Calligra. This feature is also needed for SVG import/export.

Required skills / knowledge

  • (C++, Reading other's code)?

Difficulty

  • (Medium)?

Potential mentors

  • Tomaž Vajngerl, IRC: quikee mail:
  • UX team, IRC: channel #libreoffice-design, mail: design @ global.libreoffice . org

Revamp print dialog

Current print dialog has an unclear workflow where for instance the page format does not match printer settings. Rework is needed to align the document/page settings with the printer settings. There is also a proper feedback required for the various settings and what will applied when printing. Last but not least the print dialog is cluttered and needs a clean-up. Mockups

Required skills / knowledge

  • C++, UI, reading other's code

Difficulty

  • Medium

Potential mentors

  • Katarina Behrens, IRC: bubli mail:bubli @ bubli . org
  • 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 to 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

Revamp the Customization dialog

The Tools > Customization dialog lacks today on supporting means. For instance, it is not possible to search for a particular function. It also has an interface with focus on technical facts rather than the workflow. With a redesign the functionality should remain as it is but updated so that average users are able to customize their program. Mock-up

Required skills / knowledge

  • C++, UI, reading other's code

Difficulty

  • Easy to Medium

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

  • Armin Le-Grand, IRC: mail:
  • UX team, IRC: channel #libreoffice-design, mail: design @ global.libreoffice . org

Base

Listbox separate read values from input values

A listbox acts as a mapping between values and display strings. The database (in general the value of the control) is one thing (drawn from the list content property), but the string shown to the user is another thing (drawn from the list entries property).

But these are actually used for *two* roles: - values read from the database - values input by the user

Sometimes, it is possible that the database contains values that the user should not be allowed to input. For example, historic / deprecated values, or more to the point the valid values depend on the value of other fields (or controls). One would then wish that the drop-down list feature only those values that are allowed in these particular circumstances.

The idea is to duplicate the "list entries" and "list contents" properties: - once for the role of mapping values read from the database(find what to display given a database value) - once for the role of mapping an entry chosen by the user to a database value (find what to write to the database when the user selects a list entry by its display string)

The idea is that the second set would in general be a subset of the first set, thereby giving the user a more limited selection for data entry, but still keeping the possibility of providing a user-friendly display string for other values read from the database.

How to handle listbox with Drop Down set to False is an open question.

Required skills / knowledge
C++, capacity to work autonomously.
Difficulty
medium
Potential mentors
Lionel Elie Mamane, IRC: schoinobates, mail: lionel AT mamane DOT lu

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:

Required skills / knowledge
ODF, UX, possibly c++, possibly Python, possibly web frameworks
Potential mentors
Thorsten Behrens, IRC: thorsten, mail: thb @ documentfoundation . org

Add Impress shape animations that use a real physics engine

Impress already sports a number of shape animation effects, though they start to look a bit dated in this day and age. With powerful 2D and 3D physics simulation engines available as open source, it would be cool to plug them for having slide contents interact with each other, bouncing around stuff on the screen. This task would involve:

  • integrating a suitably-licensed physics engine with LibreOffice (Box2D or Bullet come to mind)
  • interact with LibreOffice User Experience people on how to best present this in the UI
  • wire things up in the slideshow / canvas component of LibreOffice
  • be able to load and save the new effects, at least to odf files
  • in the end, have at least three effects ready to be used

Code pointers:

Required skills / knowledge
C++, basic game/animation skills useful, reading other people's code
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. Also as part of the task we should implement at least one provider of such data (for example a website with dynamic data) and the UI to handle that feature.

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

Difficulty: Medium to Hard

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 for now 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.

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: erack@redhat.com

Writer

Improve VML import

The import of VML in our DOCX implementation is limited, and for example is unable to import rotation of ellipses, or shading of objects. Even though VML is not recommended by the OOXML specification as the format to use, MS Word 2007 uses that primarily, and as a consequence, there are many .docx files around using VML.

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

For sure there are missing rotations of shapes, or their shading. There will be a test document provided which is supposed to be imported perfectly after the end of the GSoC.

Required skills / knowledge C++, reading other's code

Difficulty: medium

Potential mentors:

  • Miklós Vajna, IRC: vmiklos, mail: vmiklos @ collabora . co . uk
  • Jan Holesovsky, IRC: kendy, mail: kendy @ collabora . com

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

Help system

Help display & indexing using JavaScript

Since the birth of OpenOffice.org, the help content has relied in a set of tools developed internally. In particular, the display of the help pages is done by a XSLT transform of XML files in a primitive own browser with very few graphic, multimedia and rendering resources.

The objective of this project is replace the local help application by displaying the local help directly in a web browser. To be able to do that, searching and indexing of the help pages has to be implemented in JavaScript.

Required skills / knowledge JavaScript, XML, reading other's code

Difficulty:

medium

Potential mentors:

  • Olivier Hallot, IRC: ohallot, mail: olivier.hallot@libreoffice.org
  • Jan Holesovsky, IRC: kendy, mail kendy@collabora.com

More information

https://wiki.documentfoundation.org/Help_Content_Modernization

Filters

Replace EditEngine binary clipboard with ODF filter

EditEngine still uses a legacy StarOffice format with SfxItemPool binary serialization for copy/paste. This is a maintainability problem and the only user of SfxItemPool serialization outside of the table auto-formats. This should be replaced by using the ODF filter (xmloff) for copy/paste instead. The legacy format is used if you edit inside some text in Draw/Impress/Calc and copy a selection to the clipboard.

Required skills / knowledge C++, Reading existing C++ code

Difficulty Medium

Potential mentors:

Michael Stahl, IRC: mst[_]*, mail: mstahl AT redhat DOT com

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: alonso@loria.fr
  • David Tardon, IRC: dtardon, mail: dtardon@redhat.com

Improve MS Publisher import filter

libmspub, a library for import of MS Publisher documents, was implemented as a GSoC 2011 project. In the current state, the library only supports documents created by Publisher 2000 or newer. That is because, while the file format is technically still the same, it has gone through several evolutions which changed the representation of page content, text, etc. As a result of that, libsmpub can handle a document created by Publisher 2.0, but it only produces empty pages. With a Publisher 98 document, the result is somewhat better, but still not good.

The goal is to add support for Publisher 95-98, possibly also for older versions.

Required skills / knowledge

  • C++, Reading other's C++ code (to understand the existing libmspub code)
  • Python (for OLEToy)

Difficulty: medium

Potential mentors:

  • David Tardon, IRC: dtardon, mail: dtardon@redhat.com
  • Fridrich Strba?, IRC: Fridrich, mail: fridrich.strba@bluewin.ch

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: dtardon@redhat.com

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: dtardon@redhat.com
  • Caolán McNamara?, IRC: caolan, mail: caolanm@redhat.com

Implement QuarkXPress import filter

QuarkXPress is a desktop publishing application that once dominated the DTP world, which means there are lots of existing documents. The goal of this task is to reverse-engineer the document format produced by QuarkXPress 4--which was, as I've been told, the last widely used version--and create an import filter for it. The filter will be a library based on librevenge.

Required skills / knowledge

  • C++, reading other's C++ code (to reuse code from existing libraries)
  • Python (for OLEToy)

Difficulty: medium

Potential mentors:

  • David Tardon, IRC: dtardon, mail: dtardon@redhat.com

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:

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: mstahl AT redhat DOT com
  • Bjoern Michaelsen, IRC: Sweetshark, mail: bjoern.michaelsen AT canonical DOT com

Extension integration

Add Python extension support to LOEclipse

LOEclipse is an Eclipse plugin which supports developing & debugging Java extensions/components for LibreOffice. It is built in such a way that it can be extended to support other languages than Java. The task is to add support for Python extensions to LOEclipse.

Required skills / knowledge Java (LOEclipse is written in Java), Python (to understand Python extensions), Basic understanding of the Eclipse IDE and Platform

Difficulty: medium

Prerequisite To be accepted for this project, you don't need to do an Easy Hack in LibreOffice itself. Instead you should work on one of the LOEclipse issues and submit a pull request for it.

Potential mentors:

  • Samuel Mehrbrodt, IRC: samuel_m, mail: samuel.mehrbrodt@cib.de


Tooling

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 pootle), 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: pootle as the platform where translation happens or opengrok where the source code is indexed)

Potential mentors:

  • Christian Lohmaier, IRC: cloph, mail: cloph@documentfoundation.org

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.