GSoC Ideas

From The Document Foundation Wiki
< Development‎ | GSoC‎ | Ideas
Jump to: navigation, search


En cours de traduction


Cette page liste les idées de projet pour le "Google Summer of Code", voir les info générales sur LibreOffice et le GSoC (en). Sentez-vous libre de prendre l'une des tâches listées dans la section des tâches de programmation facile (page des "Easy Hacks" en anglais), mais dans ce cas vous devez demander au chef de développement via la mailing list si non définie. Voir aussi la page "Genial Ideas" (en) qui contient des idées intéressantes pour un projet du GSoC, mais – contrairement à la page "EasyHacks" – vous devrez trouver un chef de projet pour votre projet GSoC en interrogeant la liste des développeurs de LibreOffice.

Toutes les tâches sur cette page ont déjà des chefs de projets qui leur sont attribués. Les nouvelles tâches de cette page ne devront être ajoutées que par les personnes prêtes à s'investir et à passer du temps et être encadrées en tant que nouveaux développeurs.

Notez que le projet LibreOffice sélectionne les projets du GSOC qui seront 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.

Quand vous créez un projet, veuillez utiliser le modèle suivant :

=== Titre de la tâche ===

Quelques détails décrivant les choses à accomplir.
N'hésitez pas à détailler si vous avez des pointeurs vers du code, tels que des liens vers des fonctionnalités, etc.

;Compétences / connaissances requises :
C++, Savoir relire le code écrit par d'autres, et toute autre compétence pouvant être requise ici.

;Difficulté :
Plage entre facile, médium et difficile.

;Chefs de projets potentiels :
:''Joe Devel'', IRC: jdevel, email: joe@devel.org

Veuillez déplacer les projets achevés avec succès vers Development/GSoC/Successfully Implemented Ideas.

Contents

Général

Autoriser le démarrage de LibreOffice sans configuration utilisateur

Quand LibreOffice démarre, il essaie de lire la configuration utilisateur persistante, et non pas dans la localisation par défaut, ou dans la localisation spécifié dans le paramètre d’amorçage de UserInstallation. LibreOffice also writes user configuration and cached information collected from the installation's shared configuration there, even if the user has not done any intentional user-visible modifications of settings.

Dans certains cas, il serait très utile de pouvoir démarrer LibreOffice (either when running it as a separate program, ou quand on utilise le code de LibreOffice à travers LibreOfficeKit) sans aucune configuration utilisateur. Par exemple, quand LibreOffice (ou LibreOfficeKit) est utilisé pour implémenter des services accessibles hors réseau, without there being any actual "user" that the instance would be running for, and no need to keep any persistent settings. Currently in such situations a dummy empty UserInstallation directory needs to be created before starting LibreOffice, and correspondingly the populated directory removed afterwards.

Compétences / connaissances requises 
C++, Savoir relire le code écrit par d'autres
Difficulté 
Medium
Chefs de projets potentiels 

Tor Lillqvist, IRC: tml_, email: tml @ collabora.com


Refactorisation des god objects

LibreOffice a de nombreux god objects⁠Wikipedia logo v3.svg, et il serait grandement utile de les refactoriser en de plus petites portions. sw/inc/doc.hxx était one included by half of sw and includes a huge loads of other headers. Cela avait été refactorisé avec succès par Valentin Kettner lors du GSOC 2014. À part les indésirables couplages étroits, cela a causé un grand nombre d'inutiles (re-)constructions. Il faudra identifier les autres god objects dans SwDoc et décrire comment et pourquoi LibreOffice y gagnera en les refactorisant. Notez les chefs de projets disponibles par zone de code ci-dessous.

Compétences / connaissances requises 
C++, Savoir relire le code écrit par d'autres
Difficulté 
Médium
Chefs de projets potentiels 

writer:Bjoern Michaelsen, IRC: Sweetshark, email: bjoern.michaelsen @ canonical.com

Analyse et optimisation de SfxItemSet, lui faire utiliser un conteneur STL interne

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

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

And then, depending on the results de cette analyse, make the implementation a wrapper around an suitable STL container.

Compétences / connaissances requises 
C++, callgrind, débogage
Difficulté 
Difficile
Chefs de projets potentiels 
Michael Stahl, IRC: mst[_]*, mail: mstahl AT redhat DOT com

Tester plus et mieux

Bien qu’il y ait déjà quelques tests automatisés pour LibreOffice, il n'y en a pas suffisamment. Le but ici est de faire en sorte que les développeurs qui travaillent sur le code soient plus productifs en étant capables de retrouver les régressions potentielles.

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. Actuellement les tests peuvent être écrits en C++, Java, ou Python. Various new automated tests should be developed to improve the test coverage.

Les tests écrits exclusivement en Java (ex. le framework JUnit) devront être portés en C++ pour qu'ils puissent être exécutés plus rapidement. De même, les tests qui that do remote control of an existing LibreOffice instance, devra être refactoriser to run inside that instance to make debugging much easier.

Compétences / connaissances requises 
soit C++, Java, ou Python ; pour l'uniformisation des tests savoir relire le code écrit par d'autres
Difficulté 
Médium
Chefs de projets potentiels 
Michael Stahl, IRC: mst[_]*, email: mstahl AT redhat DOT com

Réutiliser le mécanisme de mise à jour continue de Mozilla pour LibreOffice

Mozilla est capable de télécharger de nouvelles installations en arrière-plan, se patcher lui-même, et redémarrer. LibreOffice a son propre mécanisme de mise à jour qui ne permet pas cela, malheureusement. La tâche est de réutiliser le code de Mozilla pour fournir un mécanisme de mise à jour continue pour LibreOffice également.

tdf#68274

Une alternative serait Sparkle / WinSparkle - d'après les commentaires, Sparkle fonctionnerait mieux que les mises à jour de Firefox sur OS X.

Voir aussi tdf#74934

Compétences / connaissances requises 
C++, Savoir relire le code écrit par d'autres
Difficulté 
Médium
Chefs de projets potentiels 
Jan Holesovsky, IRC: kendy, email: kendy @ collabora . com

Sujets sur des portage vers des plateformes spécifiques

Intégrer gtktiledviewer dans GNOME-Documents

Aujourd'hui GNOME Documents spawns LibreOffice via a rather unreliable unoconv command-line that converts documents to PDF. Instead it would be awesome to substantially improve and re-use libreoffice via our existing LibreOfficeKit based gtk tiled renderer.

Ce projet a plusieurs étapes :

  • Improving tiled rendering in gtktiledrender.
    • re-use the MPLv2 Mozilla tiled rendering code in C++ and integrate that into the LibreOffice core checkout Off Main Thread Compositing
    • adapt the front-end to render gtk+ tiles.
Compétences / connaissances requises 
C++, GTK+ optionnel.
Difficulté 
Médium
Chefs de projets potentiels 
Michael Meeks, IRC: mmeeks email: michael . meeks @ collabora.com
Jan Holesovsky, IRC: kendy email: kendy @ collabora.com

LibreOffice Online

Il a un prototype pour LibreOffice online qui a plusieurs années. Cette tâche inclura des changements dans LibreOfficeKit, et dans la partie web/JavaScript également.

Compétences / connaissances requises 
C++, JavaScript optionnel.
Difficulté 
Médium
Chefs de projets potentiels 
Tor Lillqvist, IRC: tml_ email: tml @ collabora.com
Jan Holesovsky, IRC: kendy email: kendy @ collabora.com

LibreOffice pour Android

LibreOffice fonctionne bien sur Android ces derniers jours, mais il reste beaucoup de choses à améliorer et réparer. Cette tâche se focalisera sur les bogues les plus ennuyeux sur Android :

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

et aussi sur les nouveautés, comme imprimer.

Compétences / connaissances requises 
C++, Java.
Difficulté 
Médium
Chefs de projets potentiels 
Miklos Vajna, IRC: vmiklos email: vmiklos @ collabora.co.uk
Tomaž Vajngerl, IRC: quikee email: tomaz.vajngerl @ collabora.co.uk

Interface utilisateur

Finir le portage vers Gtk+3

LibreOffice a été largement porté sur GTK+3, mais le travail n'est pas encore terminé - certains des widgets ne sont pas encore portés, certains have redrawing problems, etc. This work is supposed to finish this work, and provide shiny usable Gtk+3 version.

Pointeur de code : https://cgit.freedesktop.org/libreoffice/core/tree/vcl/unx/gtk3 , mostly https://cgit.freedesktop.org/libreoffice/core/tree/vcl/unx/gtk3/gdi/gtk3salnativewidgets-gtk.cxx

Compétences / connaissances requises 
C++, Savoir relire le code écrit par d'autres
Difficulté 
Médium
Chefs de projets potentiels 
Caolan McNamara', IRC: caolanm, email: caolanm @ redhat . com

Add Gtk3 gesture support to impress slideshows

Gtk3 has a gesture api https://developer.gnome.org/gtk3/stable/Gestures.html, the project is to expose that gtk3 support via vcl and add swipe, scroll, pinch etc support to LibreOffice, especially focusing on slideshow mode of impress, e.g. these things https://support.apple.com/kb/PH3501?locale=en_US&viewlocale=en_US

Compétences / connaissances requises 
C++, Savoir relire le code écrit par d'autres
Difficulté 
Médium
Chefs de projets potentiels 
Caolan McNamara', IRC: caolanm, mail: caolanm @ redhat . com

Rework the Expert Configuration dialog

The "Expert Configuration" dialog is too slow to appear with accessibility enabled. This is because the amount of configuration entries is just too large for practical use in a single list. The list should be reworked to be a tree of options and progressively show/hide branches of the options tree to work with blocks of smaller segments of options.

tdf#72125

Compétences / connaissances requises 
C++, Savoir relire le code écrit par d'autres
Difficulté 
Médium
Chefs de projets potentiels 
Caolan McNamara', IRC: caolanm, mail: caolanm @ redhat . com

Améliorer l’expérience utilisateur pour l'installation de CMIS / Gdocs / OneDrive …

The current UI to connection to a remote repository is not too straight-forward, so instead, an easy way should be implemented to integrate the access to these cloud services. This would entail the addition of an 'Open Online' button into the start center and toolbars which would provide a simple dialog to easily select a cloud service and type in their username and password and then a user would be sent to file select dialog to open the file they need. tdf#86703 The simple dialog should remember the last cloud service selected. For users of LibreOffice's custom dialog, they will be provided will exist entries in its places section of these popular services. tdf#86699 Part of this might be also improving the local file access, like providing document preview in the system file dialogs etc. tdf#87748

Compétences / connaissances requises 
C++, Savoir relire le code écrit par d'autres
Difficulté 
Médium
Chefs de projets potentiels 
Jan Holesovsky, IRC: kendy, mail: kendy @ collabora . com
Cedric Bosdonnat, IRC: cbosdonnat, mail: cedric @ bosdonnat . fr

Revoir la sidebar & ses fonctionnalités

Many things in the sidebar are not finished yet, and also some of the modeless dialogs might provide much more value if they were sidebars; eg. the Insert -> Cross-reference... feels like a functionality that would fit to the sidebar; and for sure there are more.

Compétences / connaissances requises 
C++, Savoir relire le code écrit par d'autres
Difficulté 
Médium
Chefs de projets potentiels 
Jan Holesovsky, IRC: kendy, email: kendy @ collabora . com
Katarina Behrens, IRC: bubli, email: bubli @ bubli . org
Yousuf Philips, IRC: jphilipz, email: ypharis @ gmail . com

Intégration du dépôt de modèles

More work around templates repository / online templates / integration into the start screen / ... tdf#85420 https://bug-attachments.documentfoundation.org/attachment.cgi?id=108377

Compétences / connaissances requises 
C++, Savoir relire le code écrit par d'autres
Difficulté 
Médium
Chefs de projets potentiels 
Jan Holesovsky, IRC: kendy, mail: kendy @ collabora . com

Rework of the Tools -> Customization... dialog

The current Customization... dialog could be much better organized, and could be have better. An extensive description is in http://user-prompt.com/how-to-make-libreoffice-customization-usable/, tdf#88896

Compétences / connaissances requises 
C++, Savoir relire le code écrit par d'autres
Difficulty 
Médium
Chefs de projets potentiels 
Jan Holesovsky, IRC: kendy, mail: kendy @ collabora . com
Katarina Behrens, IRC: bubli, mail: bubli @ bubli . org

Revamp the gallery tool

The LibreOffice Gallery tool would need to be enhanced to support features like sorting using tags, search, connection to online galleries like OpenClipart. This project aims at changing the gallery tool in this way. A previous GSoC project ended up with code for fetching and displaying pictures from OpenClipart. This code would need to be used as a basis for this project. As a later target, this new Gallery would be the base for an objects libraries dialog (eg network, UML...). Even though this would probably not fit in the time frame of a GSoC, this target may influence UI and code design choices.

The display of the galleries should be done as a side-bar, re-using the widget from Impress that has headings 'Master Pages' / 'Layouts' / 'Slide Design' etc. - but with each of these being a separate category of clipart - and presenting a selectable sub-set of these. This would make much better use of screen real-estate that the current horizontal gallery.

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

Compétences / connaissances requises 
C++, Savoir relire le code écrit par d'autres
Difficulté 
Médium
Chefs de projets potentiels 
Jan Holesovsky, IRC: kendy, mail: kendy @ collabora . com
Tomaž Vajngerl, IRC: quikee, mail: tomaz.vajngerl @ collabora . com

Thèmes pour l'application

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 wasnt a complete theme (e.g. theme background doesnt appear in toggled buttons, theme didnt change the color of the statusbar or scrollbars, theme didnt change the document color scheme, theme didnt change icon set, etc).

Proposal Info
https://docs.google.com/document/d/1J_aogLuQThqhvT0R2em27Vpew-SLAQgpH5TbNTgXPZM/edit?usp=sharing
Compétences / connaissances requises 
C++, Savoir relire le code écrit par d'autres
Difficulté 
Médium
Chefs de projets potentiels 
Jan Holesovsky, IRC: kendy, mail: kendy @ collabora . com

Base

Finir le pilote d'intégration Firebird

Base's embedded database is currently an outdated copy/fork of HSQLDB 1.8, which holds us back because of data corruption issues (arising mainly from how the integration is done) and lack of features (because old copy that did not follow the progress of HSQLDB).

Rather than upgrade to a newer HSQLDB, it has been decided to switch to FireBird, mainly because of issues around depending on Java and performance issues with interfacing with Java in general.

The Firebird driver for LibreOffice was started, and is mostly functional, in a previous GSoC, but it needs finishing and polishing. The main remaining issue is that the firebird data format embedded in the .odb file is endianess-dependent. The idea is to switch to Firebird's "archive" format that is not.

Compétences / connaissances requises 
C++, SQL, Reading other's code, capacity to work autonomously.
Difficulté 
Médium
Chefs de projets potentiels 
Lionel Elie Mamane, IRC: schoinobates, mail: lionel AT mamane DOT lu

Basic

Draw

Impress

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

Compétences / connaissances requises 
C++, Savoir relire le code écrit par d'autres.
Difficulté 
Difficile
Chefs de projets potentiels 
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.

Compétences / connaissances requises 
C++, Savoir relire le code écrit par d'autres.
Difficulté 
Difficile
Chefs de projets potentiels 
Thorsten Behrens, IRC: thorsten, mail: thb @ documentfoundation . org

SmartArt editing in Impress

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)

Compétences / connaissances requises 
C++, Savoir relire le code écrit par d'autres
Difficulté 
Difficile
Chefs de projets potentiels 
Muthu Subramanian, IRC: muthusuba, mail: muthu . subramanian . karunanidhi @ ericsson . com
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:

Compétences / connaissances requises 
ODF, UX, possibly c++, possibly Python, possibly web frameworks
Chefs de projets potentiels 
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:

Compétences / connaissances requises 
C++, basic game/animation skills useful, Savoir relire le code écrit par d'autres
Chefs de projets potentiels 
Thorsten Behrens, IRC: thorsten, mail: thb @ documentfoundation . org

Calc

Chart sheets in Calc

Currently Calc only supports table sheets ut for interoperability we should at least support chart sheets. For this task one needs to abstract the sheet handling in calc and adapt all places that unconditionally assume that every sheet is a table sheet.

Here are a few code pointers to this task:

Compétences / connaissances requises 
C++, Savoir relire le code écrit par d'autres, débogage
Difficulté 
Médium à difficile
Chefs de projets potentiels 
Markus Mohrhard, IRC: moggi, mail: markus.mohrhard@googlemail.com

Improve automated error checking

Handling of large spreadsheets is complex and it is nearly impossible to discover errors that have been introduced into the document. This task is about adding some tools and checks to find and prevent errors in spreadsheet documents. This task can be split into several tasks and the list below with possible ideas is just a collection for further brain storming. Managing the risk of dealing with huge spreadsheets is an open research topic and provides many ways to incorporate your own ideas.

A few ideas that might be used as a starting point:

  • Improve the current validation feature (This feature allows to provide requirements for cells but is currently very limited)
  • Detect broken formula groups -- A formula group is a continuous range in a column that contains the same token sequence. Detecting when a single cell breaks such a group and splits it into two might indicate an error.
  • There is currently a project to add units to cells (meter, seconds, ...) and detect when calculations don't match, like adding meters to seconds. This feature could be improved and integrated with the validation feature.
  • Better handling for currency formats. One of the most error prone tasks in accounting is the handling of different currencies and making sure that you only add the same currency together.
Compétences / connaissances requises 
C++, Savoir relire le code écrit par d'autres, débogage, avoir des idées folles
Difficulté 
Médium
Chefs de projets potentiels 
Markus Mohrhard, IRC: moggi, mail: markus.mohrhard@googlemail.com
Katarina Behrens, IRC: bubli, mail: bubli @ bubli . org

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.

Compétences / connaissances requises : C++, Savoir relire le code écrit par d'autres

Difficulté : Médium

Chefs de projets potentiels :

  • 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

Compétences / connaissances requises 
C++, Savoir relire le code écrit par d'autres, Lire des spécifications :-)
Difficulté 
Difficle
Chefs de projets potentiels 
Jan Holesovsky, IRC: kendy, mail: kendy @ collabora . com
Miklos Vajna, IRC: vmiklos, mail: vmiklos @ collabora . com

Filters

Create a standalone WMF/EMF/EMF+ import filter

WMF is a vector graphic format by Microsoft, which has been further extended as EMF (and later EMF+).

The task is to write an independent (from LibreOffice) import filter for these formats. Specifications of all three formats are available.

The library will be based on librevenge.

Compétences / connaissances requises : C++, Reading other's code

Difficulté : Médium à difficile

Chefs de projets potentiels :

  • Fridrich Strba, IRC: fridrich, mail: fridrich.strba@bluewin.ch
  • Valek Filippov, IRC: frob, frob_tea, mail: frob@gnome.org
  • David Tardon, IRC: dtardon, mail: dtardon@redhat.com

Implement legacy StarOffice binary formats import filter

StarOffice 1.x - 5.x had a variety of binary formats which used to be supported by the notorious binfilter, which was removed in LO 4.0 since it was unmaintainable.

It should be possible to implement a much simpler import filter for the legacy StarOffice binary formats based on the librevenge import filter API. In the absence of file format documentation the source code for the binfilter can be used as a reference, but likely some reverse engineering and experimentation will also be required.

Compétences / connaissances requises : C++, Reading other's C++ code (to reuse libwpd importer code and extract file format details from binfilter),

Difficulté : Médium

Chefs de projets potentiels :

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

Implement Apple Numbers import filter

The goal is to implement a filter for versions 2 and 3 of the Apple Numbers format (iWorks '09 and '13). The version 2 format is XML based: the output is saved as single zip file, containing index.xml, which is XML specification of the document, and other data files (images used in the document, generated preview and thumbnail, etc.) There is no documentation for the format (known to me), but the XML is reasonably readable. The version 3 format is binary and is currently being reverse engineered.

The new filter will be added to libetonyek, which is an existing library for parsing Apple Keynote format, rather than being in a separate library, as there is a large overlap between the two format's capabilities, which makes it possible to reuse a lot of basic stuff. This also makes me confident that we can implement parsers for both file format versions.

Compétences / connaissances requises :

  • C++
  • Savoir relire le code C++ écrit par d'autres (to reuse libetonyek importer code)
  • Ability to read XML and some kind of schema
  • Ability to understand hexadecimal dump of data
  • Ability to read (better yet, write) Python (for OLEToy)
  • Readiness to become famous

Difficulté : Difficile

Chefs de projets potentiels :

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

Implement Zoner Draw import filter

Zoner Callisto (known as Draw outside of the Czech Republic) is a very good vector graphics editor. After the development stopped, the last version (5) has been released free of charge (not open source, regrettably). This makes it a good choice for students etc. and increases the likelihood of appearance of files with .zmf extension. Therefore it would be great if LibreOffice could import it :-)

The goal is to implement a filter for (at least) version 5 of the format (there appear to be 2 variants of the format: one, based on OLE2, was used by versions 2 and 3; the other, which can be either zip or a single binary, by versions 4 and 5). No specification is available, but the most important parts of the file format have already been reverse engineered. Additional efforts to reveal details will be required.

The filter will be based on librevenge library.

Compétences / connaissances requises :

  • C++
  • Savoir relire le code C++ écrit par d'autres (to reuse libwpg/libvisio/libcdr/libmspub importer code)
  • Ability to understand hexadecimal dump of data
  • Ability to read (better yet, write) Python (for OLEToy)
  • Readiness to become famous

Difficulté : Médium

Chefs de projets potentiels :

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

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 Mac OS X.

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.

Compétences / connaissances requises :

  • C++
  • Savoir relire le code C++ écrit par d'autres (to reuse libwpg/libvisio/libcdr/libmspub importer code)
  • Ability to write code to a specification
  • Readiness to become famous

Difficulté : Facile à médium

Chefs de projets potentiels :

  • Fridrich Strba, IRC: fridrich, mail: fridrich.strba@bluewin.ch
  • Valek Filippov, IRC: frob, frob_tea, mail: frob@gnome.org
  • David Tardon, IRC: dtardon, mail: dtardon@redhat.com

Implement EPUB export filter

EPUB is a widely-used open format for e-books. There are several extensions for OpenOffice.org (which presumably still work in recent LibreOffice) that can export it, but they appear to be mostly orphaned, with no update for years. Also, the output quality varies widely.

The goal of this task is to write an export filter for EPUB using the libepubgen library. The main part of the task will be conversion of text document model from UNO to librevenge API, but improvements to libepubgen are likely to be needed as well. The UNO->librevenge conversion will be generic, so it will be possible to reuse it for other export formats (e.g., to AbiWord format using librvngabw).

Compétences / connaissances requises :

  • C++
  • at least basic knowledge of EPUB / HTML / CSS
  • Readiness to become famous

Difficulté : Médium

Chefs de projets potentiels :

  • David Tardon, IRC: dtardon, mail: dtardon@redhat.com
  • Michael Stahl, IRC: mst_, mail: mstahl@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.


Haskell 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 Haskell.

One aspect is to use Haskell FFI to interface with the binary UNO C API. Another is to design the Haskell 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 Haskell. A third aspect could be to create a pure Haskell implementation of the UNO remote bridge protocol.

Some documentation pointers are:

Some code pointers are:

Compétences / connaissances requises : Haskell, interfacing to low-level C/C++, working against formal specifications

Difficulté : Médium à difficile

Chefs de projets potentiels :

  • Stephan Bergmann, IRC: sberg, mail: sbergman @ redhat . com

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:

Compétences / connaissances requises : Rust, interfacing to low-level C/C++, working against formal specifications

Difficulté : Médium à difficile

Chefs de projets potentiels :

  • Stephan Bergmann, IRC: sberg, mail: sbergman @ redhat . com
  • Michael Stahl, IRC: mst[_]*, mail: mstahl AT redhat DOT com

Tooling

Crash reporter service

There is a crash reporting tool in the LibreOffice code base, which is currently not used because there is no service it could report to. Such a service should be developed, receiving incoming crash reports and storing them in a database. The reports come with a call stack, and the tool should do some correlation to match new reports against those existing in the database, to find duplicates. Nice to have would be if the service could automatically resolve the addresses in the stack to exact source location by scripting debugging tools.

There already exist tools a lot of this for Linux distributions, such as Red Hat's ABRT, looking at how that is implemented would be useful. Currently there is not such a great need for a working crash reporter for Linux, because most Linux users use LibreOffice from their distribution, but for Windows and MacOS X it would be very useful.

Compétences / connaissances requises : Server side development, Database, etc.

Difficulté : medium

Chefs de projets potentiels :

  • Christian Lohmaier, IRC: cloph, mail: cloph@documentfoundation.org
  • Jesús Corrius, IRC: jcorrius, mail: jcorrius AT gmail DOT com

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.

Compétences / connaissances requises : 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

Difficulté : 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)

Chefs de projets potentiels :

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