Tenders for budget 2020
TDF LibreOffice Document Liberation Project Community Blogs Weblate Nextcloud Redmine Ask LibreOffice Donate
Proposal for tenders in budget 2020
Below are proposal for tenders, to be discussed on the ESC.
See what was on a similar page 2 years ago.
Traditionally we have prioritized tasks that there is no probability that will be delivered for free by someone else, in order to conserve TDF's budget. As such larger, less glamorous structural things are interesting, alongside put features.
==== My idea ==== '''CostEstimate: 1 week''' '''Contact: John''' '''Reviewers: Hannah, Josphine''' Short description
Requirements:
- costs are stated in rough guestimate person weeks, so that it is possible to rank the proposals against each other.
- costings should be created by or signed-off by a certified LibreOffice developer.
- reviewers: these are people willing to oversee the project, help review the tender, sign off on its completion and help adminster this task for TDF.
QA and Automated Testing
Cleanup & further improve ODF conformance
CostEstimate: 8 weeks
Contact: Thorsten Behrens
- address annoying issues highlighted by http://autotests.opendocumentformat.org/
- cleanup https://bugs.documentfoundation.org/buglist.cgi?list_id=582656&query_format=advanced&resolution=---&status_whiteboard=odf_validation&status_whiteboard_type=allwordssubstr
- perhaps also cleanup https://bugs.documentfoundation.org/buglist.cgi?list_id=582655&query_format=advanced&resolution=---&status_whiteboard=odf&status_whiteboard_type=allwordssubstr
- note: these are almost all pre-existing bugs, unrelated to ODF 1.3 support
Automated ODF filter regression testing
CostEstimate: 3 weeks
Contact: Michael Stahl
There are sometimes dataloss regression bugs with the filters for LO's default file format, ODF; the unit tests have nowhere near sufficient coverage to prevent this. The proposal is to install an early-warning system for such problems. The idea is to use the ODFunDiff tool, which was developed specifically with relevant (functional and performance) requirements in mind; for details see https://conference.libreoffice.org/assets/Conference/Brno/stahl-functional-document-testing.pdf
- It may be necessary to do a few tweaks and updates to the tool, as it was originally developed in the LO 5.2/5.3 time.
- It may be necessary to fix some hypothetical additional non-determinism in LO that may have crept in since LO 5.3.
- Some scripting needs to be developed to extend the weekly crash-report run with an additional report about detected ODF differences on the ~27k ODF round-trips
- The test should use last run's ODF files as reference to compare against
- Possibly, resource problems will need to be dealt with: crashtesting VM didn't have enough disk space for 2 full sets of result documents in 2018
Tests for the VCL graphic backends
CostEstimate: ~2-3 weeks (depends on how far we want to go with the tests)
Contact: Tomaž Vajngerl
As it is quite important that our graphic backends draw as we expect them to draw (off-by-one problems) it would make our life much easier if we can automatically test them. Currently there are already a bunch of tests written in vcl/backendtest/ which test the writing to a VirtualDevice get the bitmap and check, if what get is what we expect. However these test aren't complete yet. More test cases need to be added to cover more of the graphic backend interfaces and fall-back drawing inside OutputDevice. Another issue is that currently only skia backend is enabled for the tests, because all the other backends have some issues and either the tests or backends need fixing. To get all the backends working with the automated tests is the second goal of this task. Another idea with this test is that they can be executed the first time the user starts LibreOffice to decide which backend is safe use. We know that at some instances the driver bugs cause various issues with OpenGL or Skia Vulcan backends. In such cases we can detect the issues with the backend and fall-back without the need to bother the user with it.
Tests for drawinglayer and basegfx
CostEstimate: ~3 weeks
Contact: Tomaž Vajngerl
Drawinglayer currently has almost no test, which is really sad considering it is the core of graphic drawing in LibreOffice. The important is to get the tests for basic primitives, visitors and the decompositions of primitives and the basic tools. Another very important part is basegfx, which contains some test, but the coverage is very limited.
MSO compatibility test framework using Win API
CostEstimate: 6 weeks + VMs
Contact: Tamás Zolnai
- Microsoft published some API to work with Office applications.
- It can be a good idea to create a test framework which tests MSO file format compatibility by opening files both with LibreOffice and Microsoft Office and checking document properties (e.g. number of pages, shapes, tables) using LO API and Windows API.
- Of course this test framework would be Windows only.
- First test can be for example a check for the number of tables in the imported document compared to the table number produced by Microsoft Office import.
- After this simple test is implemented, we can run this on thousands of documents (this also means we can guarantee a specific level of compatibility by adding these tests and running them on lots of documents (also good for regression testing)).
- Later the compatibility level can be increased.
- Another good starting point can be some validation test of LO exported documents.
- Just open saved documents in MS office automatically and check whether MSO can open them without a problem (e.g. tdf#104787)
- Validation tools (like Open XML SDK) often shows false positives and also can happen they don't show a problem which actually makes MSO to fail opening a document. So better to test compatibility directly using MSO.
A reasonably future-proof automated testing plan
Regular scan-build reports like we do with CppCheck
CostEstimate: 1 week
Contact: Luke
Regular scan-build reports like we do with CppCheck. See also: https://wiki.documentfoundation.org/Development/Clang_Code_Analysis
Core Code Refactorings and Cleanups
Separate GDIMetafile from serialization to SVM file + Tests
CostEstimate: ~3 weeks
Contact: Tomaž Vajngerl
Currently the GDIMetaFile is more or less defines 1 to 1 the serialized format (SVM). To make it easier to refactor the VCL it is needed to separate them, so that we can freely change the GDIMetaFile (for example change to floating point types) without the fear to accidentally break the SVM file format (which can't be changed because the documents have it). The first step is to finish the SVM tests to cover more of the functionality. The tests already have a good code coverage, but the "complicated" cases aren't covered yet. The second step is the to write a importer and exporter for the SVM format. The most complex task here would be to put all the type (Rectangle, Point, Color,....) serialization into the importer/exporter.
Bridge the gap between drawinglayer and VCL
CostEstimate: ~2 weeks
Contact: Tomaž Vajngerl
In VCL, we can't currently use drawinglayer primitives because drawinglayer depends on VCL for the VCL pixel processor. The idea is to integrate the VCL processor into VCL itself and change the drawinglayer in such a way that the primitives are separated from the processors, so that they become independent of any "backend". After that is done, we can use primitives in VCL and can process a PrimitiveContainer directly in OutputDevice. This is important because we can, depending on the backend, do optimisations with the primitives directly and can bind resources to the life-cycle of a primitives.
Implement font subsetter for font embedding
CostEstimate: 4 weeks
Contact: Thorsten Behrens
While font embedding is implemented for LibreOffice since many years, it's an under-used and under-developed feature due to the fact that unicode-capable fonts are massive, thus blowing up documents beyond useful sizes. Other applications therefore simply subset the fonts embedded, to either exactly the set of glyphs used, or to the code pages / script areas touched by existing document content. This would also help a lot for making our in-tree and out-of-tree bug document collection invariant to installed system fonts.
Cleanup GraphicFilter
CostEstimate: ~1 weeks
Contact: Tomaž Vajngerl
GraphicFilter is currently a mess with all those dynamic and static library loading. We should make that very simple and move all graphic filters into VCL itself, like we already do for PNG and JPEG. Then all those dynamic and static library loading is completely unnecessary.
Curl based HTTP/WebDAV UCP
CostEstimate: 8 weeks
Contact: Michael S
- Problem #1: TDF releases bundle both OpenSSL and NSS, both libraries have high number of security issues
- On macOS and Windows, neither OpenSSL nor NSS integrate with the OS supplied crytographic APIs, so they will use a bundled hard-coded set of trusted CAs that is different from what the OS itself would trust and not user-modifiable
- OpenSSL cannot ever be used from the system because it has no ABI
- Problem #2: There are 2 different HTTP/WebDAV UCPs:
- one (which is used by everybody including TDF releases) using a bundled Neon WebDAV library
- requires OpenSSL
- cannot be used on a hypothetical Apple iOS port
- another (for a hypothetical Apple iOS port) using a bundled Serf library
- requires OpenSSL
- Serf does not actually support WebDAV directly, only HTTP, so the UCP itself impleements the additional WebDAV protocol features
- complicated to build, drags in 2 other bundled external libraries
- cannot be upgraded to current version without introducing a new build dependency on "scons" tool
- one (which is used by everybody including TDF releases) using a bundled Neon WebDAV library
- TDF releases also bundle the Curl library
- can do HTTP, likely similar to Serf
- can use native OS cryptographic APIs and trusted CAs on Windows, macOS and Linux
- can be used on Apple iOS without problems
=> implementing a HTTP/WebDAV UCP with Curl, possibly based on code from the Serf UCP, would solve these issues, get rid of 4 bundled external libraries and 1 hard OpenSSL dependency
Fix macOS 10.15 notarization
CostEstimate: -
Contact: -
Proposed by: Xisco
Bug: https://bugs.documentfoundation.org/show_bug.cgi?id=126409
The issue has been in the most pressing bugs section in the ESC minutes for some months now. Cloph investigated it, everything seems ok but gatekeeper fails ( see https://bugs.documentfoundation.org/show_bug.cgi?id=126409#c24 )
Refactor font handling on Mac
CostEstimate: -
Contact: -
Proposed by: Xisco
Font handling on Mac has been problematic since LibreOffice 4.1, see #tdf69254.
Besides, since macOS build baseline was bumped to xcode 10, fonts are blurred on retina displays, see #tdf122218 #tdf122218 was fixed with a workaround from Stephan, see b7fd89100d8653dc73955780358fe31d38b68ebf, but the underline problem still remains, see this comment
The idea behind this task is to refactor font handling on mac and fix both bugs mentioned above
Migrate from Carbon to Cocoa framework on Mac
CostEstimate: -
Contact: -
Proposed by: Julien
LibreOffice contains Carbon and Cocoa parts. The goal is to migrate Carbon parts into Cocoa since the first one is obsolete. (see https://bugs.documentfoundation.org/show_bug.cgi?id=130453)
Use floating point for glyph positioning in VCL
CostEstimate: -
Contact: Khaled?
Proposed by: Xisco
See tdf#103322 Currently we use integers and do lots of calculations and recalculations resulting in rounding errors which mess up with text spacing specially at low resolution screens.
We should switch to using floats to store glyph positions instead, which would make the rounding errors less visible. It would also allow us to benefit from sub-pixel positioning support in the graphics libraries we use.
Replace the binary format for drawing shapes in Gallery themes with a human readable XML format
CostEstimate: no idea
Contact: -
Proposed by: Regina
Currently drawing shapes are stored in binary format in the Gallery. That makes it impossible to maintain them. For example some "Fontwork" shapes (a hidden Gallery theme) use bitmap fillings, which do not exist any more, because those shape were originally from StarOffice. Or the dummy text "Fontwork" cannot be replaced with a localized one.
Similar happens with shapes created in Draw. If someone creates a Gallery theme from a set of his shapes, and this theme is then deployed (extension or included), it is not possible to maintain the set afterwards, because the Gallery theme contains only the binary format.
Making Gallery themes from draw objects for other users is currently very hard.
That prevents community members from contributing. Gallery themes would be a wonderful opportunity for community members to make LibreOffice better usable in special areas (garden planing, engineering, education, interior design, for example).
So my suggestion is to make a tender, that replaces the current format and internal treating with a version, that makes it possible to easily
- generate a set of drawing shapes as theme
- deploy Gallery themes
- maintain themes
- adapt foreign themes to personal or localizing needs
AW080 Paradigm changes: SdrObject Homogen Transformations (cc'ed from 2018 suggestions)
CostEstimate: 8 weeks
Contact: Armin
For general information of "AW080 paradigm changes" see [1]. This single Paradigm change is about using Homogen Transformations (Linear Algebra) throughout the DrawingLayer Model definitions (mainly but not only SdrObjects). I was doing this once for AW080 and know how this can work and what is doable. For a discussion about advantages of doing this, see the text following the link.
AW080: Removal of NBC Methods, Improve DrawingLayer Broadcasting (cc'ed from 2018 suggestions)
CostEstimate: 2 weeks
Contact: Armin
For general information of "AW080 paradigm changes" see [2]. This Paradigm change is about getting rid of the old NBC-Methods (which stands for NonBroadCast BTW) in DrawingLayer and cleanup of the Broadcasting/Messaging part of DrawingLayer involved with that. I was doing this once for AW080 and know how this can work and what is doable. Motivation: The original idea probably was that multiple changes at SdrObjects would trigger multiple change-messages which are sent as broadcasts to multiple listeners, currently over multiple channels. This has some problems:
- It is not safe in the sense that sending an initial and terminating message is guaranteed since doing changes calls helper methods which do not really know if their change will be the last change in the task to perform
- Some changes seem to not have been aware that not only a terminating message is needed, but also an initial one. To successfully invalidate visualization regions it is necessary to invalidate *both*, the covered part at start and end. If this is missed initially, the change will potentially modify the initial area covered and it will no longer be available. These broadcasts are not only used for invalidates, but for multiple purposes
- This has led to quite some problems in the past and needs check/cleanup to find remaining places. It is not that dramatic anymore due to also using VOC information nowadays for these purposes, but only consequently for everything in Draw/Impress. If that was not clear yet, these mechanisms have to also work in the other apps (Writer/Calc/Chart/Math)
- The broadcasting can be unified and secured, done something in that direction in AW080 already, but this is too old now, can be used as roadmap but needs new development. The current state is that the broadcasting has grown over the years and no one knows which ones are still needed and which not, neither if these are complete. All this needs check/rework to make more reliable and more performant - e.g. there will be superfluous things that may be removed completely or replaced my more efficient methods (not registering at general broadcast when needing only specific infos about specific changes of specific objects)
For a discussion about advantages of doing this, see the text following the link.
AW080 Precision changes: Enhance DrawingLayer Precision (cc'ed from 2018 suggestions)
CostEstimate: 4 weeks
Contact: Armin
For general information of "AW080 precision changes" see [3]. There are quite some Precision Changes which should be done, not all of these will be doable in the mentioned time frame. This is a more general entry to suggest spending some time on this and do as much as possible of the points mentioned in the Wiki page. For a discussion of possibilities see the text following the link.
AW080 Other Changes: Various DrawingLayer enhancements (cc'ed from 2018 suggestions)
CostEstimate: 4 weeks
Contact: Armin
For general information of "AW080 Other changes" see [4]. There are many Other Changes/enhancements possible (called so because not fitting to the other categories), not all of these will be doable in the mentioned time frame. This is a more general point to suggest spending some time on this and do as much as possible of the mentioned points. For a discussion off possibilities see the text following the link.
Add Winding-Rule support for PolyPolygon Handling (cc'ed from 2018 suggestions)
CostEstimate: 2 weeks
Contact: Armin
This task suggests to use the Winding-Rule for PolyPolygons inside and throughout the Office. The Winding-Rule defines how a PolyPolygon is to be graphically represented (see [5]. We currently have no parameter associated with our PolyPolygons to represent that and imply these to follow the Nonzero-Rule. This gets problematic with various external Formats supporting both Winding Rules. In the best cases we try to 'Convert' imported PolyPolygons which are not of type Nonzero-Rule to this. This is very runtime-expensive (see some very slow loading imports) and requires fully cut and touch free PolyPolygons, including the whole clipping steps (related to clipping refactor below). For export, we always assume Nonzero-Rule because we know no other. This change is about supporting both Winding Rules at Imports, in the Core, in the graphic stacks (most support it anyways) and at export time (also supported by quite some formats). It is not needed or planned to offer at the UI (from my POV - the diffs what you can do with the different interpretations of topology are subtile and only usable for experts).
Support Multi-Step-Gradients and 'SVG-Gradients' in LO (cc'ed from 2018 suggestions)
CostEstimate: 10 weeks
Contact: Armin
One highly missing feature are Multi-Step-Gradients. This shows in quite some places, e.g. at import of external formats which support these. We have to reduce to Two-Color-Gradients which are as 'similar' as possible. This is also true for the gradient geometry we have to use one of our old internal formats that comes as close as possible to more modern formats. This is also true for SVG-Gradients currently. We should be able to support these directly and add these to our internal gradients. These changes have quite some aspects of which not all will be solvable in one step. It should include:
- Support in core (model/rendering)
- Support in FileFormats (ODF for MultiColorSteps, SVG-Gradients, partial adaption of external format im/export filters)
- Support in UI (MultiColorSteps for existing and SVG-Gradients - (not sure how lean this can be, probably no initial support for interactive Gradients - yes we have something like this already)
Direct Conversion from Primitives to SdrObjects (cc'ed from 2018 suggestions)
CostEstimate: 2 weeks
Contact: Armin
We currently have no conversion step to create our own internal Graphic formats using SdrObjects when the source are Primitives. This is e.g. the case with SVG or GDI+ imports and other vector formats. These are currently converted to SdrObjects using an indirection step: First convert Primitives to Metafile (with all known internal limitations and errors of that old format) and then using pretty old code to convert that to SdrObjects. This indirection loses quality (integer), information and costs performance. Solution would be to have one single internal direct converter that is capable of creating SdrObjects directly from Primitives which will be used in all importers of vector formats (existing and future ones). This would e.g. be the precondition to have/support SVG-Gradients one day directly in LO (see above).
Direct Creation of CustomShapeGeometry using Primitives (cc'ed from 2018 suggestions)
CostEstimate: 4 weeks
Contact: Armin
Currently the CustomShapes (also known as AutoShapes) internally create their visualization using 'hidden' SdrObjects from the DrawingLayer, being e.g. non 'real' members of the SdrModel/SdrPage, expressing this with NULLPTRs. This always leads to problems in many areas, including many 'hacks' avoiding nullptr accesses and more. The usage of these 'hidden' SdrObjects is to create the needed Primitives from these. This indirection step costs runtime and resources, loses quality (by being on 100thmm integer) and is partially problematic - this is especially true for complex CustomShapes that have many Faces (which still is not error-free nowadays due to limits in what SdrObjects can graphically represent). This would also fix runtime/quality problems with extruded CustomShapes which use the MS-like 3D visualizations. These do very special 'tricks' to represent all this using 3D SdrObjects. Using and creating 3D Primitive representations directly would make things much faster and more reliable. Also will fix quite some bugs (e.g. tdf#118795).
PolyPolygon clipping refactor/improvement
CostEstimate: 1 1/2 to 2 weeks
Contact: Armin
We already have an implementation of this in a working manner, but precision errors have shown up (bugtracker) and speed is not very good, esp. when reorganization of partial Polygons is needed - that is the last step. This may get as bad as O^3 AFAIK (IsInside for each point of PolyA against PolyB). I have started working on a better approach, that
- increases precision, e.g. adding bezier-against-bezier clipping
- increases reliability numerically
- highly enhances runtime for the last sorting/organizing/result-extracting step
This functionality is used in edit views with drawing objects to allow geometrical construction using logical compositions (merge/substract/interesct). Also used in Region/Clipping code when rectangles and integer functionality reach their limits, and also when FillRule NonZero comes in (e.g. from SVG) and needs to be converted to be used in office. That one week will be needed to finish this - an estimation of course, but already spent some time on this and have stuff prepared (1-2 weeks in).
Remove/Replace usages of XOR-Paint
CostEstimate: 3 weeks
Contact: Armin
XOR paint is an old relict of the office and was used intensely in the older days for selection, text and objects. This has changed to better methods (e.g. text selection visualization, selection frames around objects, etc.), but we still have some places where this is used (also for text selection in EditEngine, Cursor, some more). The problem with this are that it looks ugly and is hard to support on modern graphic backends - these often do not offer this or it is complicated/unperformant due to needing read access to the target surface (in principle to execute the XOR). Thus the current and future graphic backends could be simplified by getting rid of the last usages of this. Also our internal stack could be simplified. I already started some (see [6]), but more effort would be needed. Main effort would be EditEngine, but another outcome of this would be to have better/standard text selection visualization after that and no longer the still used XOR.
Unify Styles - add DrawingLayer Styles to all apps which use DrawObjects
CostEstimate: ?? weeks
Contact: Armin
Currently only Draw/Impress knows Styles for DrawObjects. If these DrawObjects get copied to Writer or Calc (or Chart), the Styles are lost and get 'stamped' to the SdrObjects using a method called 'BurnInStyleSheetAttributes()' - the name is program, make all attributes hard attributes... Goal would be to also have DrawObject Styles in all Apps and to maintain them on Load/Save/Copy/Paste - Styles are mighty and useful nonetheless. This would be a multi-stage approach, so probably needs to be refined in finer granularity and broken to smaller ideas:
- Unify Styles in the core to allow easier integration to all apps (currently all apps use similar but different impls - same same but different...)
- Adapt this in Draw/Impress - currently using some wild string patterns like <name>~LT<family>, look for SD_LT_SEPARATOR definition and how/where this is used
- Probably adapt Styles in other apps to a unified method to deal with them
- Add handling/UI/Load/Save/Copy/Paste to all apps, adapt Draw/Impress to support that
Time is very hard to estimate, I would propose better to do something like spending some amount of weeks and try to get as far as possible.
Refactor Writer repaint to Primtives and VOC usage
CostEstimate: ??? weeks
Contact: Armin
Draw/Impress is still the only app that is completely converted to use Primitives. To get better precision, buffering/re-usage and speed in repaints this step would be needed. It is also a precondition to - one day - write/create backend-specific primitive processors (aka renderers). There is still some stuff done in Writer, e.g. all Draw-Objects and the Writer Graphic objects internally already use Primitives during repaint (tricks), but there is also a lot missing. One possible in-between step would e.g. be to have one DrawPage per WriterPage which is currently not the case. This would allow better internal handling of draw shapes in Writer and allow to have a Grid not only for the first Writer page (due to currently only having one single huge draw page for all writer pages), but fitting for all Pages for supporting better interactive object positioning. Time is very hard to estimate, I would propose better to do something like spending some amount of weeks and try to get as far as possible.
Refactor Calc repaint to Primtives and VOC usage
CostEstimate: ??? weeks
Contact: Armin
Similar to above, but with very different problem areas. Main problem in Calc still is the mix of pixel and logic coordinates in EditView paint, aka NonLinearViewTransformation. This leads to many problems, but I have some idea how to solve this in an acceptable manner which preserves lines painted non-AAed and with the pixel-based requirements, but at the same time getting to some *linear* ViewTransform in that process. Similar as for Writer, quite some stuff in-between the repaints already uses Primitives, but also a lot of stuff is open and missing. Time is very hard to estimate, I would propose better to do something like spending some amount of weeks and try to get as far as possible.
Chart creation speed
CostEstimate: ??? weeks
Contact: Armin
We have a massive speed problem with the Chart module. It has the high claim of using UNO API in a very fine-grained manner, but comes with the cost for that - low speed. The basic idea is to 'convert' the construction process to more raw steps to avoid that complexity for some degree. Unfortunately this has to be done for each chart type separately. Time is very hard to estimate, I would propose better to do something like spending some amount of weeks and try to get as far as possible.
UNO API at SdrObjects
CostEstimate: ??? weeks
Contact: Armin
Currently SdrObjects and their UNO API implementation(s) are separated and reference each other vice-versa (which already caused/causes some lifetime problems). This seemed to be a decent method to do this when it was initially done, but also causes some runtime problems. Directly implementing at SdrObject level with modern methods (e.g. registering slots/calls using lambdas, no longer using endless if/else steps, ...) has the potential to greatly speed up and enhance the UNO API in that areas. Thus, all areas where this is used would profit - Chart, Load/Save, you name it. Time is very hard to estimate, I would propose better to do something like spending some amount of weeks and try to get as far as possible.
SfxItem/SfxItemPool/SfxItemSet rework
CostEstimate: ??? weeks
Contact: Armin
I am already experimenting with this, just adding here for completeness of ideas. This would lead to a much simpler, modern attribute/property system:
- no int-slots, no WhichID-matching mayhem
- just type-based
- no global/per-app ItemPools
- no need to define at each SfxItemSet what Items are allowed
- on-par or better speed and mem usage (hard to get - do not underestimate the speed of the current ItemSet stuff :-))
- easier to use for newbies :)
No concrete time/weeks to be given, this will be a long-time project, but could nontheless need support...
Migrating to single modern 2D graphics library
CostEstimate: 20 weeks
Contact: Michael M
Migrating to a single modern 2D graphics library in the non-welded case, Skia, and sorting out our graphics and text drawing inconsistencies.
Windows already defaults to Skia, but macOS, Linux (gen) and headless could also use Skia
Convert Impress slideshow to drawinglayer primitives
CostEstimate: 4 weeks
Contact: Thorsten
This is a copy from Development/GSoC/Ideas#Rework_Impress_slideshow_to_use_DrawingLayer_primitives, which has not happend in 6 years.
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.
Bring "Chart" to ODF 1.3
CostEstimate: 8 weeks
Contact: -
Proposed by: Regina
Adapt all chart relevant parts of LibreOffice to read and write ODF 1.3 formats. "Chart" related parts were not included in the corresponding tender from last year. It is essential on the way to become a published standard, that LibreOffice has a working implementation of it.
Finish transition of LibreOffice to ODF1.3
CostEstimate: 8 weeks
Contact: -
Proposed by: Regina
The tender from 2019 and the proposed tender "Chart" do not cover all changes made in ODF 1.3. ODF 1.3 introduces features, which are not or only partly implemented in LibreOffice. Those should be added. New features: Extended number-formats: Implemented, but UI is missing New Calc print option: Not implemented Hyperlinks in each kind of index: Hyperlinks are only implemented for TOC.
And there are still some maintains needed: Remaining, in ODF 1.3 not needed own namespaces have to be removed Some errors with writing own namespaces in ODF strict have to be solved for ODF 1.2 and ODF 1.3. Some cases, where it is not clear, whether the implementation in LibreOffice follows the ODF 1.3. standard, have to be verified and fixed if needed.
Development Infrastructure
Blocking features
Floating multi-page tables in Writer
CostEstimate: 24 weeks
Contact: Tamás Zolnai
See e.g. https://bugs.documentfoundation.org/show_bug.cgi?id=61594, Word can have tables which are wrapped around by body text and they still split across multiple pages. Writer can't do this. The idea would be to have SwTabFrame not only inherit from SwFlowFrame, but also from SwFlyFrame to reach this. Cost is large because table layout is complex.
Look-ahead styleref field for Writer
CostEstimate: 1.5 weeks
Contact: Miklos Vajna
Fix https://bugs.documentfoundation.org/show_bug.cgi?id=86790. Forward-look version of the chapter field, \l in Word. ECMA-376 part 4, 2.16.5.66 STYLEREF has the Word behavior.
Go through the doc model, UNO API, layout, filters, UI process and add support for this.
Improved built-in, XRay-like profiler & script debug
CostEstimate: 12 weeks
Contact: Michael M
XRay-alike, to be built-in as native code, with better core hooks and usability etc. Modern browsers come with significant, helpful built-in JS developer tools, and we are far behind this in terms of ease-of-use for development of extensions and (more critically) unit tests using the UNO APIs.
It should be possible to press F12 (or whatever) - and get access to the rich object model, browse it, and see how both scripts, and the app is performing - to help both scripters, and also those interested in improving LibreOffice performance & responsiveness.
Porting the XRay functionality from StarBasic to C++, and including it - along with providing a cleaner, browser-like UI at the bottom of the screen would be ideal.
In particular - the ability to select an item in an arbitrary document eg. an image, or a shape - and get its UNO peer, and be able to inspect attributes on it would be excessively helpful.
Similarly logging UNO events emitted by the core, and allowing inspection of their details in a console-alike.
Improve the experience of the SDK
CostEstimate: 4 weeks
Contact: Bjoern
- see https://studiofreya.com/2016/10/11/integrating-libreoffice-into-cpp/ https://studiofreya.com/2016/10/19/errors-connecting-to-libreoffice-with-cpp-errors-part-2/ https://studiofreya.com/2016/10/21/open-libreoffice-calc-with-cpp-part-3/ as reference of the pain this currently is
- undo hugely painful gnumake-ness etc.
- make it much more usable, and ideally from IDEs
- provide a 10 minutes "Hello World extension for LibreOffice from scratch" video as proof how simple stuff is after this is fixed.
UNO API changes subscription/feedback channel
CostEstimate: 1 week
Contact: Bjoern
The simplest solution (KISS for a start) would be e.g.:
- an archived mailing list (uno-changes@ ...)
- an bot that puts every API change on that list, cc'ing the author of the change,
- someone replying to the API change also reaches the author of the change
- bot that filters for the API change discussions and put notifications and RSS feeds on api.libreoffice.org
Optimize Text layout performance for Print and PDF export
CostEstimate: 6 weeks
Contact: Khaled?
Proposed by: Telesto
The text layout performance is abysmal, all over the code base it is assumed that shaping text is cheap and we can do it over and over again. Want to measure the text? Shape it and discard the output afterwards. Want to measure part of the same text? Shape again. Want to find line breaks? Shape again. Want to finally draw it? Shape again. This might have been cheap for Latin script in the olden days when all we did is query font cmap table and put glyphs next to each other, which is not the case anymore and never been the case for more involved scripts. We need to work on this, and there are many possibilities; retaining shaping results much longer, improving the wasteful OutputDevice API, caching etc.
Especially in the area of PDF export & printing. The time to Export PDF/Print a Latin text has doubled since Harfbuzz implementation. An exception amount of energy, computation power, and user time has been wasted this way.
PDF Export: tdf#116400 and also tdf#112989) Printing: tdf#116399
Flamegraphs PDF export: [7] Printing Job: [8]
Optimize performance showing and saving comments in Calc
CostEstimate: no idea
Contact: -
Proposed by: Telesto
Calc and comments don't go well together. The main issue high CPU load when scrolling a document with many comments. A small assessment of issue can be found here: tdf#76324. There's probably also a performance issues in the area of opening/saving a file with lots of comments. Some technical info here tdf#119650
Optimize performance showing comments in Writer
CostEstimate: no idea
Contact: -
Proposed by: Telesto
Writer and comments don't go well together. The main issue a high CPU when scrolling a document with many comments. A small assessment of issue can be found here: tdf#61558
Optimize footnote parsing in Writer
CostEstimate: no idea
Contact: -
Proposed by: Telesto
Opening a file with lots of footnotes is rather slow. The same rather expensive XML parsing is done repeatedly. See for some developer wisdom: tdf#76260 and some more at c46/c47
Stabilize cross-page table lay-outing
CostEstimate: no idea
Contact: Michael Stahl?
Proposed by: Telesto
Table rendering is still an issue. Especially splitting tables over multiple page with embedded split tables in it. It causes layout changes entering at table. Pages going out of range. Edits can cause layout-loops. Crashes. Footnotes start jumping around. Different page counts on file-opening.
Finish MAR-based autoupdater
CostEstimate: ?
Contact: ?
Reviewers: ?
Fix Google Drive two-factor authentication
CostEstimate: ?
Contact: ?
Reviewers: ?
Rotated Writer TextFrames
CostEstimate: 24 weeks
Contact: Miklos Vajna
https://bugs.documentfoundation.org/show_bug.cgi?id=82627 Text from DOCX shapes is always mapped to Writer TextFrames so complex content can be represented (tables, etc). Writer TextFrame content can't be rotated, so the task is to add rotation support to TextFrames.
Writer tables: support cell margins (next to cell padding)
CostEstimate: 12 weeks
Contact: Miklos Vajna
https://bugs.documentfoundation.org/show_bug.cgi?id=128203 Writer supports spacing between the table cell border and its contents, but not between adjacent cells. Word supports this, so we don't render such documents nicely. The task is to add doc model, layout, filters, UI, etc. to support this feature nicely.
Fix problems from the DOCX: Aggressive Competitors tracker
CostEstimate: 8 weeks
Contact: Miklos Vajna
https://bugs.documentfoundation.org/show_bug.cgi?id=128194 Fix the following bugs from this tracker: tdf#128195, tdf#128197, tdf#128198 and tdf#128205. All of these are layout problems, so they are not trivial, but they are not huge missing features, either.
XLSX Aggressive Competitors tracker: add support for sparklelines
CostEstimate: 3.5 weeks
Contact: Dennis Francis
https://bugs.documentfoundation.org/show_bug.cgi?id=91476
Filters, implementing the cell graph drawing (consider reuse from chart2) and write cppunit tests.
XLSX Aggressive Competitors tracker: table styles
CostEstimate: 24 weeks
Contact: Dennis Francis
https://bugs.documentfoundation.org/show_bug.cgi?id=122472
Fixing this depends on the table styles project: https://wiki.documentfoundation.org/Development/GSoC/Ideas#Implement_table_styles
This needs table styles import/export and core implementation, which is highly non-trivial. Once this is done, table styles for pivot table can be implemented much easily.
XLSX Aggressive Competitors tracker: gridlines for 3d line charts
CostEstimate: 2 weeks
Contact: Dennis Francis
https://bugs.documentfoundation.org/show_bug.cgi?id=128384
Make sure that the feature works nicely, including correct anti-aliasing.
XLSX Aggressive Competitors tracker: support math equations in Calc shapes
CostEstimate: 5 weeks
Contact: Dennis Francis
https://bugs.documentfoundation.org/show_bug.cgi?id=128385
Allow importing math markup from XLSX shape markup into Calc, similar to what already works for Impress.
Finish Firebird implementation
CostEstimate: ?
Contact: ?
Reviewers: ?
tdf#116968 The goal is to reduce dependency with Java.
Accessibility
Implement scrollto, scrolltopoint, scrollsubstringto, scrollsubstringtopoint
CostEstimate: 10 weeks Contact: Alex Arnaud
https://bugs.documentfoundation.org/show_bug.cgi?id=118418
For better accessibility, we should implement the scroll*to* accessibility calls, which allow the screen reader to fix what is shown, so that a blind user and a sighted user can understand each other when they are working together on a document.
C++ accessibility tests
CostEstimate: 4 weeks Contact: Alex Arnaud
The current accessibility tests are rather incomplete and nobody wants to touch them. Part of the problem is that they are out of process, written in Java, so it's not easy to modify them. The task is to convert them to in-process cppunit-based tests and extend the coverage.
UX problem areas
Document Themes
CostEstimate: ~6 weeks
Contact: Tomaž Vajngerl
Document themes are a simple way to allow users to quickly & consistently restyle the entire document. This however needs changes to everywhere we use font attributes, colors attribute and shape attributes as they need to be changed by a theme identifier. When designing with a theme support, instead of defining the attribute value (for example the text color #00FF00), you define a variable identifier instead (color "accent1"), which is then dependent on what the current theme uses. When the whole document is defined like this, the user can easily change the appearance of the whole document with just changing themes. This is also quite important for the OOXML support as MSO has this feature for a long time.
Currently there is a start of this at feature/themesupport, but it is just a POC, however it lays a bit of the groundwork for the UI and core. What is still needed to complete this is:
- add support for ODF
- use the theme support in ooxml
- change all the UNO API where color and font is used to allow for definition of the theme variables
- UI to change themes
- UI to create new themes
Keyboard customization
- CostEstimate: -
- Contact: Thorsten?
- Proposed by: Heiko
Rework the internal handling of keybinding and allow non-English shortcuts
https://bugs.documentfoundation.org/show_bug.cgi?id=115052
SmartArt
- CostEstimate: 16 weeks
- Contact: Thorsten
Our existing smart-art import uses the fallback-stream in OOX files, and gives us only the draw shapes that are imported - thus loosing the original layout. In older file versions we don't have the cached shapes - so can render nothing. We really would like schema driven diagram layout as a core feature as well. This should be interoperable with OOX, and have suitable extensions for ODF. It should layout interoperably, and allow editing of the underlying data, and selection of a schema.
Note: There was recent effort on the layouting side. Much work is still needed, but better than 2-3 years ago. The editing also needs a lot of love, current state is just a proof of concept.
https://bugs.documentfoundation.org/show_bug.cgi?id=37932 (Heiko)
Table Styles Serialization
- CostEstimate: -
- Contact: Eike?
- Proposed by: Heiko
Replace binary format by XML
https://bugs.documentfoundation.org/show_bug.cgi?id=49437
see also "Replace the binary format for drawing shapes in Gallery themes with a human readable XML format"
Table Style UI
- CostEstimate: -
- Contact: -
- Proposed by: Heiko
UI missing from GSoC
https://bugs.documentfoundation.org/show_bug.cgi?id=105933
Multi-color gradient
- CostEstimate: -
- Contact: Armin
- Proposed by: Heiko
see also "Support Multi-Step-Gradients and 'SVG-Gradients' in LO"
Better support for multi-language documents
CostEstimate: 5 weeks
Contact: Martin Hosken
Better support for documents with multiple languages:
- language at cursor -> keyboard changes accordingly
- change keyboard -> language switches accordingly
I.e. when a user changes keyboard, the text language changes. Likewise when a user moves their cursor into text of a different language, the keyboard switches. No bug raised on this yet.
- UI-level: per-language styling (only in the UI)
E.g. font would change automatically based on if I edit a piece of English or Thai text.
Language Extensions
CostEstimate: 4 weeks
Contact: Martin Hosken
Tim Eves has been doing good work on allowing dynamic loading of locale information as part of an extension. We have already added the capability for a language to be added to Libo via an extension. This takes it a step further and allows the locale information to be loaded as part of the language extension. Thus you would be able to have language specific sorting, dates, etc. But he has too much on his plate and would value help in getting the project finished. It's almost to the point of testing. The project would mean that a user can add support for a language to libo without having to rebuild libo. This may not sound much to libo developers, but it's huge in minority language communities. After all do you really want to ship libo with support for 2000 languages and the length of language selector UIs that would be needed, the increased size, etc. People are only interested in adding local support for a couple of languages at most. But everyone wants a different set of 'a couple of languages'.
Normalized spell checking
CostEstimate: 1.5 weeks
Contact: Martin Hosken
Spell checking should be done in either Normalization Form Canonical Composition (NFC) or Normalization Form Canonical Decomposition (NFD) and the dictionary encoded appropriately. Currently one has to produce a spelling dictionary with both in and that's no fun. It's a matter to normalize the copy of the string being spell checked.
See https://www.wikiwand.com/en/Unicode_equivalence#/Normal_forms for details on these concepts.
Redesign of chart wizard UI
CostEstimate: 6 weeks
Contact: Bubli
Redesign of chart wizard UI, pretty sexy mockups from Heiko Tietze here: http://user-prompt.com/libreoffice-design-session-inserting-a-chart/ Related to that - chart styles. Was a part of this OSBA thingit, but never found funding: http://osb-alliance.de/fileadmin/Working_Groups/OfficeInteroperability/Project2/SpecificationMajorFeatureImprovements_final.pdf
Improving printing UI
CostEstimate: 20 weeks
Contact: Bubli
Much improving printing UI, more sexy mockup from Heiko here: http://pad.documentfoundation.org/p/UX-PrintDialog
Documentation team
Master document fixes
CostEstimate: 5K
Contact: Olivier Hallot
Reviewers: Ilmari Lauhakangas
The guide books publishing workflow requires that the master document feature of Writer functions adequately. High priority issues: