Tenders for budget 2022

TDF LibreOffice Document Liberation Project Community Blogs Weblate Nextcloud Redmine Ask LibreOffice Donate

Below are proposal for tenders, to be discussed in the ESC.

See what was on a similar page a year 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.

Blocking features

Finish Firebird implementation

CostEstimate: ?

Contact: ?

Reviewers: ?

tdf#51780 [META] Default to Firebird not HSQLDB in Base (for _new_ files)
tdf#116968 [META] Migrating existing embedded HSQLDB databases to Firebird

The goal is to reduce dependency with Java.

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.

Relevant meta bug showing it's a widely used feature: https://bugs.documentfoundation.org/show_bug.cgi?id=139532

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.

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.

Continuous Section Breaks

CostEstimate: 9 weeks

Contact: Michael Stahl

Main bug: https://bugs.documentfoundation.org/show_bug.cgi?id=89297 (+9 duplicates)

In Word the continuous section break can generate a section with section-level headers&footers, which only take effect if the section extends to the next page. Writer does not have a similar feature, so it is necessary to implement & standardize a new kind of break attribute that changes the page style without an immediate page break, so the Word feature can be mapped to it. Also it is necessary to add ODF & OOXML import+export support.

Interdependant change tracking

Main bug: https://bugs.documentfoundation.org/show_bug.cgi?id=56266

Currently it is not possible to record interdependant changes in change tracking and to save them as ODF, such as:

Deleting text from other users tracked insertion
Formatting text in tracked insertion of text and tables
Moving deleted/inserted text in a numbered list up/down with toolbar commands

While it is possible to import and export such changes in DOCX files made with Word to some degree.

For improved feature-parity with Word it would be useful to extend the ODF standard with support of interdependant revision marks support, as well as extending Writer to record such changes affecting text and tables during editing.

Add more combo chart types

CostEstimate: ???

Contact: ???

Main bug: https://bugs.documentfoundation.org/show_bug.cgi?id=142046 (meta)

MS Office has a wide variety of combo charts: charts with different representations of individual data series. LibreOffice only supports the combination of column and line charts. To improve interoperability it would be necessary to support more types of combination charts in LO in accordance with MSO such as Column, Bar, Line, Area, XY (Scatter). Also improve UI to support selecting any number of these combinations for the available data series. Also improve OOXML import-export support.

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=60469

Allow importing math markup from XLSX shape markup into Calc, similar to what already works for Impress.

XLSX Aggressive Competitors tracker: table styles

CostEstimate: 24 weeks

Contact: Dennis Francis

Main bug: https://bugs.documentfoundation.org/show_bug.cgi?id=66377 - Feature request: Format As Table (+8 duplicates) Format as table is a widely used Excel feature which has no equivalent table-style formatting feature in Calc (only cell and page level styles are supported), although the database-like features are supported as Database range.

Fixing this problem would require bringing the core functionality of formatting a part of the sheet with a style (also binding to a database range for interoperability), ODF import-export + XLSX import-export.

Fixing this depends on the table styles project: https://wiki.documentfoundation.org/Development/GSoC/Ideas#Implement_table_styles

Chart: data table rendered below chart

CostEstimate: 7 weeks

Contact: Dennis Francis

https://bugs.documentfoundation.org/show_bug.cgi?id=72304

Commit ba76bf5c7b705d3f5e8d807346a34d9da34127d3 (fdo#72304 Added properties to store Chart data table information, during import., 2013-12-12) already tokenizes the majority of the OOXML markup (added for roundtrip/grab-bag purposes), but then the real layout is missing.

Pivot Table – Compact view

CostEstimate: 9 weeks

Contact: Lubos Lunak

Compact view of pivot tables is currently the default for new Excel pivots – a big interoperability problem for XLSX. The task is to implement a compatible layout in Calc that matches the compact view of Excel.

Missing ODF Features (general collection)

CostEstimate: see items below, 2+4+6+0.5+4 = 16.5 weeks minimally

Contact: Regina, Michael Stahl

Lots of features that were already in ODF 1.2 are not implemented:

SVG Gradients: already tracked under its own item "Multi-color gradient"
persistent xml:id on lots of elements in all applications - 02-20 weeks depending on scope
- sw: most important would be the ones that create noise in diffs
  - <text:list>
  - <text:changed-region>
  - these don't have xml:id, only text:id, so noise is the only problem:
    - <text:toc-mark-start>, <text:user-index-mark-start>, <text:alphabetical-index-mark-start>
- sw:
  - <draw:frame>
  - <office:annotation>
  - <draw:object>
  - <draw:object-ole>
  - <draw:text-box>
  - <text:list-header>
  - <text:list-item>
  - <text:numbered-paragraph>
  - <table:table>
  - <table:table-cell> - these can be split and merged which complicates implementation
  - <table:table-column>
  - <table:table-row>
- svx:
  - <draw:page-thumbnail>
  - <draw:caption>, <draw:circle>, <draw:connector>, <draw:control>, <draw:custom-shape>, <draw:ellipse>, <draw:frame>, <draw:line>, <draw:measure>, <draw:path>, <draw:polygon>, <draw:polyline>, <draw:rect>, <draw:regular-polygon>
  - <office:annotation>
  - <draw:a>
  - <draw:applet>
  - <draw:floating-frame>
  - <draw:image>
  - <draw:object>
  - <draw:object-ole>
  - <draw:page>
  - <draw:plugin>
  - <draw:text-box>
- chart2:
  - <chart:chart>
  - <chart:data-point>
  - <chart:plot-area>
  - <chart:series>
- sd:
  - <anim:par>, <anim:seq>, <anim:iterate>, <anim:audio>, <anim:command>
  - <presentation:sound>
  - <table:table>
  - <table:table-cell>
  - <table:table-column>
  - <table:table-row>
- forms:
  - <form:number>, <form:date>, <form:time>
  - <form:password>, <form:file>, <form:fixed-text>, <form:button>, <form:image>, <form:radio>, <form:frame>, <form:image-frame>, <form:hidden>, <form:grid>, <form:value-range>, <form:generic-control>
  - <form:text>, <form:textarea>, <form:formatted-text>, <form:combobox>, <form:listbox>, <form:checkbox>
- editeng:
  - <text:p> - these can be split and merged which complicates implementation
  - <text:list>
  - <text:list-header>
  - <text:list-item>
  - <text:numbered-paragraph>
- sc:
  - <table:table>
  - <table:table-cell>
  - <table:table-column>
  - <table:table-row>
  - <text:changed-region>
(own item below) <draw:regular-polygon> missing completely -> moved to own item, see below
<draw:page-thumbnail> usage other than as Notes in Impress
<text:page-sequence> missing completely

What does this do? is it a way to set a sequence of page styles that is completely independent of the properties of the content of a text document? why was this added to the standard?

It is way to layout documents as it is down in desktop publishing applications like Scribus.

<office:image> is missing completely but nobody wants it anyway
Attribute draw:copy-of of a <draw:frame> element
- this is similar to virtual SdrObject in header/footer in sw? except that each of them has its own position and needs to be exported - 4 weeks?
(own item below) attribute svg:d of <draw:path> some of the possible commands are missing
(own item below) concentric gradient fill of custom-shapes tdf#144925
draw:wrap-influence-on-position
- "iterative" is effectively unimplemented since 2004, but it's not obvious why we would want to add it now as it's obviously the option most likely to introduce new layout performance problems
(own item below) draw:shadow-offset-x/y only partially implemented
style:overflow-behavior for text box
- "auto-create-new-frame" only makes sense for sw, 6 weeks
HSL color animation
fo:hyphenate tdf#106733: in sw, 3 days
text:footnotes-position value 'text' not implemented tdf#90921
- this is unlike any other footnote mode and could cause tricky oscillations, 4 weeks
(own item below) The attribute draw:text-rotate-angle is interpreted, but there exists no user interface to change it.

Missing ODF Features: Attribute svg:d of <draw:path> some of the possible commands are missing

CostEstimate: 2 weeks

Contact: Regina, Michael Stahl, Armin

Attribute svg:d of <draw:path>: some of the possible commands are missing.

Some of the more complex svg:d statements are missing, that may influence imports from various sources (odf, svg). This mainly concerns import, since for export we define what we want to use in LO. Adaption should contain:

Create/construct examples
Extend svg:d to PolyPolygon Importer/Reader
Ensure functionality through all levels (DrawView, exports, PDF, Print, ...)

Missing ODF Features: Concentric gradient fill of custom-shapes

CostEstimate: 2 weeks

Contact: Regina, Michael Stahl, Armin

Concentric gradient fill of custom-shapes is missing. See https://bugs.documentfoundation.org/show_bug.cgi?id=144925. That task contains examples/definitions of the missing gradient option(s) in question thanks to Regina. Based on that and internal knowledge, needed steps include (but may not be complete):

Identify these cases at Import, may need extension/tweak of UNO API load/save
Add possibility to Graphics Core to hold that data/new mode for this new Gradient Mode
Add possibility in Graphics Core to Load/Save this (at least) in ODF
Add visualization (EditView/PDF/Print/Slideshow/processing...)

Nice-to have, but initially not (urgently) needed:

Identify these cases at Export, too (may need extension/tweak of UNO API load/save) This ay be avoided initially by using an equivalent replacement.
Add possibility to allow the User to change Gradient Mode (Possibilities are Interactive/UI/Dialogs/Sidebar,...)

The CostEstimate above is for the minimal needed steps. Further enhancements may be handled in other/later tasks, but would need another estimated 2-3 weeks AFAIK.

Missing ODF Features: Draw:shadow-offset-x/y only partially implemented

CostEstimate: 3 weeks

Contact: Regina, Michael Stahl, Armin

Draw:shadow-offset-x/y is only partially implemented. Task should extend this by:

Define examples showing missing cases
Extend missing cases systematically for Import/Export (both may be needed)
Extend interpretations of attributes (UNO API, model)
Adapt/Check visualizations

UI for shadow offset x/y is there (DrawObject attributes), but will need to be checked, too.

Missing ODF Features: The attribute draw:text-rotate-angle is interpreted, but there exists no user interface to change it.

CostEstimate: TODO

Contact: Regina, Michael Stahl, Armin

The attribute draw:text-rotate-angle is interpreted, but there exists no user interface to change it.

Missing ODF Feature: <draw:regular-polygon> missing completely

CostEstimate: 2 weeks

Contact: Regina, Michael Stahl, Armin

https://bugs.documentfoundation.org/show_bug.cgi?id=94584 contains examples of the shape object in question.

This is currently missing completely, so I took a look. Thankfully the task contains example documents and a PDF documenting the how-it-should look-alike. Based on that and internal knowledge, needed steps include (but may not be complete):

Add needed ShapeType to allow creation of geometrical representation/interactions
Import/Export *at least* in ODF (maybe also other formats)
Check/test functionality (Exports, e.g. PDF&Print, interactions, logical op's with other shapes, ...) - this list may grow

The task would be to add that shape to import/export, handling in running office (UI) and ensuring it's correct handling in back-end usages (export PDF/Print, Slideshow, ...).

Avoid ODF roundtrip for embedded objects in Impress and elsewhere

CostEstimate: ?

Contact: Noel Grandin

Currently the PPT and other MSO import filters convert embedded objects to ODF, then load them back as the MSO file is opened.

https://bugs.documentfoundation.org/show_bug.cgi?id=54857 is an example of the embedded object problem.

The task would be to improve handling of embedded objects, so they would only require a single import from the opened file, not "original import + ODF save + ODF open".

Decouple master slide and layouts

CostEstimate: 8 weeks

Contact: Thorsten Behrens

Main bugs: https://bugs.documentfoundation.org/show_bug.cgi?id=62332

https://bugs.documentfoundation.org/show_bug.cgi?id=78156

Currently the set of slide layouts is predefined in Impress, the user can not create custom ones. The predefined ones are independent of the master slides: one can assign a predefined layout to a slide, and each slide has a master slide assigned. This is less flexible than the model PowerPoint uses, and consequently creates lots of interoperability issues when opening and saving files in PPTX format.

In PowerPoint one can create custom slide layouts, and one can also assign layouts to master slides without using them on any actual slides but this master slide+layout is saved in the files. This is a great feature for template documents. Opening such files in Impress causes the loss of „unused” slide layouts, since Impress only supports one layout per master slide. Another useful feature is that it's possible to override certain properties of the master slide in the slide layouts belonging to it, such as background. This is imported, but on saving it propagates back to the master slide since that is how Impress can represent it.

To improve OOXML interoperability the relationship of the layouts and master slides needs to be significantly changed as a prerequisite.

It's also necessary to modify the Impress UI to be able to create custom layouts attached to master slides, plus ODF import-export support. Together with these the OOXML import-export can be improved too.

3D rotation of Impress shapes

CostEstimate: 12 weeks

Contact: Tomaž Vajngerl, Miklos Vajna

Bugreports: https://bugs.documentfoundation.org/show_bug.cgi?id=143863, https://bugs.documentfoundation.org/show_bug.cgi?id=45495 and https://bugs.documentfoundation.org/show_bug.cgi?id=139808.

Support 3D rotation of shapes, especially custom shapes, including their editable text. This is a feature that PowerPoint has in its drawingML markup. At an UNO API level, this is meant to be a set of new properties on the existing 2D shape objects. If possible, it’s a good idea to share code with the existing 3D objects render code, but that is limited to polygons, i.e. the text is no longer editable. Editable text is important, to be able to save the information back to editable ODP and PPTX.

Regina (talk):

I support this suggestion. The associated bug is "(PPTX-3D) - [META] PPTX 3D model issues" tdf#120388. I had already started to work on the problem in https://gerrit.libreoffice.org/c/core/+/113445 with the idea to use the extrusion of custom shapes. I had abandoned it, because I have noticed, that there exists errors outside import/export filter, which need be solved beforehand. Still not solved from those are tdf#145700 and problems with property "RotationCenter" tdf#145904 and wrong calculation of "Origin" tdf#145956.

The custom shape extrusion (including Fontwork) is already implemented to use the 3D objects render code.

3D-rotation other than z-rotation and 3D-projection of text in custom shapes need extension to the ODF format. Other not directly on custom shapes in ODF representable features are light rigs with three lights and light rigs with colored light.

To get better compatibility with the UI of MS Office, the dialog "3D-Settings" would need to be extended in case of a solution with custom shapes.

For perspective projection of images an implementation similar to command .uno:Shear is currently missing, we have only simple shear, which would only fit to parallel projection.

Core Code Refactorings and Cleanups

AW080 Paradigm changes: SdrObject Homogen Transformations

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

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)

SfxItem/SfxItemPool/SfxItemSet rework

CostEstimate: 10 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...

Unify Styles - add DrawingLayer Styles to all apps which use DrawObjects

CostEstimate: 8 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.

UNO API at SdrObjects

CostEstimate: 6 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.

Winding-Rule support for PolyPolygon Handling

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 [6]. 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).

Unify Writer and Draw Images

CostEstimate: 8 weeks Contact: Thorsten

long-standing annoyance
several attempts, current status (90-degree rotations) is a half-house. Rotation issue properly fixed by Armin in 6.0.
extract Writer border rendering & frame special code, move to drawing layer & make accessible from SdrGrafObj
Relevant meta bug: Regressions from rotated images support in 6.0 (has 8 open bugs, having 12 duplicates total --Kelemeng (talk) 2022-03-07T16:58:16 (UTC) )

The topic 'Unify Writer and Draw Images' is much too wide. Please have look at File:Comparison WriterDraw image.odt. I have collected a lot of differences between Writer-images and Draw-image, not from developer but from user and file format view. A possible tender needs a very clear description what is expected. Regina (talk) 2022-05-06T19:46:14 (UTC)

Enhancement requests with high importance

Cherry-picked topics from enhancement requests with a large number of duplicates and/or people on CC. Full list is here.

Dark mode

All major desktop environments provide a so-called dark mode that switches from bright background colors to dark colors during night. Applications should follow this color scheme and users expect LibreOffice to update window/dialog background, sidebar, menus, tool- and Notebookbars, and perhaps optionally also the application colors (eg. the document canvas).

References

tdf#118320 Add support for Windows 10 dark mode
tdf#118017 support macOS dark mode
tdf#124480 Support Android system theme
tdf#124969 Dark theme option to read/view/write in LO
tdf#48733 App themes to change LibreOffice appearance
https://bugzilla.mozilla.org/show_bug.cgi?id=1368808 Respect Windows 10 Dark / Light color settings
https://ask.libreoffice.org/en/question/180423/is-there-a-dark-mode-for-libre-office/

CostEstimate

Contact

(Mike K)

Document Comparison bugs and enhancements

Writer has useful document comparison feature, except it often fails to spot just changed parts of documents and it cannot detect tables, headers, footnotes/endnotes, fields, formatting, work with passwords etc. Calc also needs improvement to it's comparison.

References

tdf#41544 Compare spreadsheet with password protected file does not work
tdf#54068 The "Edit>Compare Documents" command does not detect changes in tables properly
tdf#71152 Compare Document in Writer should not ignore footnotes, endnotes, fields, header/footer etc
tdf#102616 Compare documents on near-identical files flags 99.9% of the contents as different
tdf#119605 Document comparison is missing an option not to take into account (or show) style (or formatting) changes
tdf#135725 Chapter numbering cannot be compared
tdf#97326 UI: Improve Calc Compare Document (Spreadsheet Compare) List
tdf#125674 (Document-Comparison) - [META] Document Comparison bugs and enhancements

CostEstimate

Contact

(Timur)

Split-pane documents

Users ask frequently to have multiple documents in tabs. While MDI/TDI interfaces have drawbacks on usability [7] (and provides ground to resolve the request as WONTFIX), the use case of proof reading two documents side-by-side is clear. Similar request might be to split the current document, as known from MS Office [8].

References

tdf#33173 Tabbed UI (Writer): Division/section-per-tab (similar to Lotus WordPro)
tdf#37134 Tabbed UI: Document-per-tab (similar to Firefox, Opera, gedit) MDI
tdf#31481 [RFE] Split pane in same window for side-by-side proof reading/ translating of 2 different files
tdf#42428 Split panes in same window for side-by-side or above-and-below editing of two (or more) parts a single document/file

CostEstimate

12 weeks

Contact

Miklos

Styles Highlighter

The Styles Inspector has been successfully implemented during GSoC'20. This inspector allows to analyze the attributes of the currently selected style with all its inheritance. What's missing to learn how the whole document is styled is the second part of the proposal, the Styles Highlighter.

References

tdf#34002 Add Reveal Codes feature like there is in WordPerfect
tdf#38194 Style indicator in document margin
tdf#106556 Add functionality that highlights all directly formatted text
https://design.blog.documentfoundation.org/2019/11/05/proposal-to-conveniently-highlight-and-inspect-styles-in-libreoffice-writer/

CostEstimate

Contact

(Mike K)

SVG rendering improvements

With the increasing number of HiDPI displays users request high quality icons. We ship SVG versions but use by default PNG. To improve the situation, we need: a) SVG test suite (format and rendering tests), b) inspect the rendering pipeline (svgio, drawinglayer, vcl, backends) for bugs caused by SVG files and fix them, c) add extensive rendering tests, d) implement most common used missing SVG features: filters (for example feGaussian), and e) HiDPI scaling awareness for VCL

References

tdf#115439 High DPI mode: SVG icons should be preferred over PNG versions when available
tdf#88278 [META] SVG import image filter (all modules)
tdf#111450 [META] SVG fileSave filter (Draw)
tdf#124940 [META] SVG Icon theme issues

CostEstimate

6 weeks

Contact

Tomaz

Table Styles improvements

Table Styles use a binary format. Current set of styles are created by taking the user-defined autotbl.fmt including all attributes. Once the binary format is exchanged into XML we can skip attributes and, for example, do not override the font name. Second major topic is the varying interaction. While Impress provides a WYSIWYG preview, Writer doesn't. And Calc not even has the option in the sidebar. Last but not least we also need to improve the compatibility.

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.

The above paragraph does not belong to tables, but would be a separate item "Replace the binary format for drawing shapes in Gallery themes with a human readable XML format" as in tender proposals 2020. Regina (talk)

How reasonable it is to improve some bits in existing table styles, when the whole implementation needs deep reconsideration? Current table styles are implemented lnot as styles (layer of formatting, which can be overridden by higher layer, has some corresponding direct formatting specific to the layer, controls look and feel of all objects using the style, does not use direct formatting itself), but rather as some kind of template, applying direct formatting dynamically, non-editable? (Mike Kaganski)

References

tdf#49437 Use XML for serializing table autoformats instead of the current brittle binary format
tdf#34391 Implementing Table Styles
tdf#94076 FILEOPEN: ODT - <style:style> Table styles not imported and not preserved after Roundtrip
tdf#101757 Import and export OOXML table styles
tdf#113208 [META] Table AutoFormat bugs and enhancements
https://design.blog.documentfoundation.org/2017/05/08/results-table-styles-survey/
https://design.blog.documentfoundation.org/2015/12/13/style-your-tables/

CostEstimate

8 weeks

Contact

Miklos

UNO API / SDK Improvements

Improve the experience for extension authors. Changes in this area should encourage/simplify extension writing and in turn grow the extension ecosystem.

Dialog Designer improvements

Dialog designer is a tool used by LibreOffice extension authors to create dialogs for their extensions. Fix the most annoying bugs in that area. Issues are sorted by importance (list can be reduced)

References

tdf#99545 Dialog Designer: List of used widgets
tdf#97062 Dialog Designer: Provide undo/redo capability
tdf#97061 Dialog Designer: Provide reasonable default sizes for widgets
tdf#97237 Dialog Designer: Changes are always saved
tdf#97059 Dialog Designer: Mouse click should not close dropdown list
tdf#97052 Dialog Designer: Scrolling object properties container also scrolls the preview area
tdf#97135 Dialog Designer: Changing properties should have immediate effect
tdf#99548 Dialog Designer: Import button missing
tdf#99408 Dialog Designer doesn't remember Window state
tdf#97268 Dialog Designer: Missing properties for Dialog

CostEstimate: 6 weeks

Contact: Samuel Mehrbrodt

Improve the experience of the CPP 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

Localization and linguistic

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

Localization support for templates

CostEstimate: ??? weeks Contact: Miklos Vajna

https://wiki.documentfoundation.org/Documentation/HowTo/Impress/Make_template_language_independent currently recommends not having any strings in templates to avoid l10n problems. The idea is to allow some kind of placeholder strings in templates, then translations for those placeholders, so that people can define style names or titles like 'Sales Ledger' and have that localized based on the user's language, at the time a document instance is created from a template.

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.

Miscellaneous

In-app rating / un-structured feedback

CostEstimate: 4 weeks Contact: Miklos Vajna

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

Power optimization research

CostEstimate: 6 weeks

Contact: Luboš Luňák

The goal is getting involved with the EU power initiative, and improve LibreOffice in the benchmarks there, see https://www.gtd-gmbh.de/pceet/.

Stabilize cross-page table layouting

CostEstimate: 1 week per bug (13 weeks)

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.

References

Improve visual appearance of tracked changes

Main bugs:

https://bugs.documentfoundation.org/show_bug.cgi?id=140157

https://bugs.documentfoundation.org/show_bug.cgi?id=143922

CostEstimate: 24 weeks

Contact: László Németh

Visual presentation of tracked changes in Writer is significantly different from that in Word. A similar UX is sought after by users switching from Word (see the older linked bug reports).

Missing part of the us experience is to use the Annotations bar more:

To have an option to display text/object deletions in the Annotations bar (140157).
To have text formatting changes spelled out textually in the Annotations bar (143922).

ODT export nondeterminism

CostEstimate: 1 week

Contact: Michael Stahl

Storing unpacked ODT files in git has the problem that on every export all automatic styles, list ids, etc, are in a random order. The problem got worse recently as font-face elements are also in a random order. In 2013 an environment variable LIBO_ONEWAY_STABLE_ODF_EXPORT was added which helps a bit, but there are still issues: list ids use a global counter, table-row formats aren't handled. It would be good to fix enough of that so that the ODF specification document can be versioned in git without such noise in diffs.

Fix accessibility issues

CostEstimate: 4 weeks

Contact: Michael Weghorn

LibreOffice currently has various accessibility issues which prevent users with acessibility needs from using LibreOffice in the best way. This is about fixing some of those to make LibreOffice more accessible by tendering a subset of the issues listed in the accessibility metabug tdf#101912 (exact tickets to be determined).

Most annoying bugs

Picked from the list of most-annoying bugs.

Allow inline graphics, formulas in impress (and draw), open equation with inline formulas from PPT, PPS, PPTX, PPSX

See also Support embedded objects in editeng text

References

tdf#35033, tdf#129061

CostEstimate

12 weeks

Contact

Miklos

Text runs of RTL scripts (e.g. Arabic, Hebrew, Persian) from imported PDF are reversed, PDFIProcessor::mirrorString not behaving

Note:
This was fixed before tendering

References

tdf#104597

CostEstimate

2 weeks

Contact

Thorsten, Xisco, (Khaled)

Writer document with tables that use style loses formatting on adding or deleting a row

References

tdf#126008

CostEstimate

?

Contact

Maxim

Performance

Showing and saving comments in Calc

CostEstimate: 2 weeks

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

Showing comments in Writer

CostEstimate: 3 weeks

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

QA and Automated Testing

MSO compatibility test framework using Win API

CostEstimate: 6 weeks + VMs

Contact: Tamás Zolnai

Microsoft published some API to work with Office applications.
- https://support.microsoft.com/en-us/kb/196776
- https://msdn.microsoft.com/en-us/library/microsoft.office.interop.word._document_properties.aspx
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

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.

Fix unreliable unit tests

CostEstimate: 3 weeks

Contact: Michael Stahl

Jenkins builds are plagued by spurious test failures. These are usually hard to reproduce. On WNT and macOS builders, a substantial part of the tests are not even executed due to reliability problems in the tested code. Then there are some randomized tests that crash if the random numbers turn out unlucky. Somebody should spend some time on fixing such problems.

UX wish list

Some potential GSoC projects could also be tendered.

Application Themes (formerly known as Mozilla Persona)

Mozilla repeatedly changed the Persona format always ending up in a mess for LibreOffice. We should introduce an own format a "LibreOffice Application Theme" and allow users to share as extension. The theme should apply to menu/titlebar, toolbar/Notebookbar, and sidebar.

References

tdf#125217 Replace Mozilla themes with a proprietary tool reusing the existing
tdf#120406 Allow personalization > themes to be loaded from extension
tdf#125823 [META] Personalization (LibreOffice Themes) bugs and Improvements

CostEstimate

Contact

(Muhammet)

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

The customization the shortcuts is not intuitive, cumbersome, and does not follow the interaction from menus and toolbars. The internal representation of key codes needs an update to not restrict on American English. A shortcut like shift+<semicolon> is possible with English keyboards but wont work on other locales since the semicolon itself requires shift being pressed. And last but not least we use hard-coded shortcuts (css::awt::Key) with all possible modifier combinations, which blocks other keys than A..Z.

References

tdf#52335 Usability issue: The GUI for assigning keyboard shortcuts to functions is not intuitive
tdf#115052 Allow other keys than from US keyboard as shortcut keys
tdf#71176 Key combinations to easily insert accented Latin characters
tdf#123656 Ctrl+Plus keyboard shortcut unavailable on laptop keyboards
tdf#41560 [META] Keyboard shortcuts tab of Customization dialog
https://design.blog.documentfoundation.org/2015/01/22/how-to-make-libreoffice-customization-usable/

CostEstimate

6 weeks

Contact

Muhammet

Multi-color gradient

One highly missing feature are Multi-Step-Gradients. This shows in quite some places, e.g. at import of external formats which support these - as such, it is also a MSO interop problem. 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: a) Support in core (model/rendering), b) Support in FileFormats (ODF for MultiColorSteps, SVG-Gradients, partial adaption of external format im/export filters), c) 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)

References

tdf#44731 PDF import problems with gradients and patterns
tdf#48392 ODF: Implementation for svg:linearGradient and svg:radialGradient is missing
tdf#76682 Gradients in LO are limited only to two colors
https://design.blog.documentfoundation.org/2015/12/22/area-fill-options-made-consistent/

CostEstimate

10 weeks

Contact

Armin

Redesign of chart wizard UI

CostEstimate: 6 weeks

Contact: Bubli

Redesign of chart wizard UI, pretty sexy mockups from the design team here. Related to that - chart styles. Was a part of this OSBA thingit, but never found funding.

Unit in numerical inputs

Numerical data are managed per general settings. You get either use inches or centimeter or points etc. But sometimes it's useful to switch to another unit, ideally directly at the input control. Having this variable input could also solve the request for high precision input (decimal places).

References

tdf#72662 Use Different Measurement Units for Line vs Page Properties (e.g. point vs inch)
tdf#44267 Two decimal digits are insufficient for specifying object position and size
tdf#105176 SIDEBAR: Line width preset drop down control only shows size in points

CostEstimate

3 weeks

Contact

Miklos

RTL/CTL

One area that needs more attention is the text rendering for RTL/CTL languages. Right now, there are some long-lasting bugs in LibreOffice that have not been fixed, or got fixed some time in the past, but came back later.

There are many RTL languages[1], and Having a tender for some of these bugs can help users from multiple languages like Arabic, Hebrew, Pashto, Persian, Urdu, and Sindhi which cover more than half a billion people. A recent estimate shows that "There are over 600 million right-to-left (RTL) language speakers worldwide" [2].

Other than being written from right-to-left (RTL), some of these scripts like Arabic (which is used for many other languages like Persian, Pashto, Urdu, etc.) use context-sensitive shaping and ligatures, and they are called scripts with complex text layout (CTL) [3]. There are also many bugs in LibreOffice text rendering in this area.

Also, some of the CTL script like Devanagari, Khmer or the Thai are written from left-to-right, so the number of users that affected by RTL/CTL bugs are more than the above number. Adding the 600 million people who use Devanagari [4], the total number can estimated to be more than 1.2 billion people.

Some of the non-fixed bugs related to RTL/CTL are severe, because they actually prevent users from having simple documents in their language without text rendering defects, and is a blocker to use the LibreOffice with the content of those specific languages.

These are the meta bugs that list many of the currently known bugs:

~80 direct bugs and several meta bugs inside:

tdf#43808 (RTL-CTL) - [META] Right-To-Left and Complex Text Layout language issues (RTL/CTL)

~35 direct bugs

tdf#129661 (RTL-UI) - [META] Right-To-Left (RTL) user interface issues

References

Fix diacritics rendering defects

CostEstimate: ?

Contact: Khaled

There are several problems with diacritics rendering for Arabic/Hebrew. Some of these problems are listed here:

Please note that some of these issues are related to the problems in justified text rendering.

Automated test tools for finding text rendering defects

CostEstimate: ?

Contact: Khaled

As the text rendering for LibreOffice is done via HarfBuzz, it is possible to compare the output from HarfBuzz/Pango. Some of the rendering defects happen when styling is used, for example this is rendered with problems in LibreOffice.

pango-view --font="Amiri Quran 256" --markup --text '<span color="green">ٱ</span><span color="yellow">ل</span><span color="orange">ل</span><span color="red">ّ</span><span color="lightblue">ٰ</span><span color="red">ه</span>'

This is an effort to find similar problems through automated tests that work with HarfBuzz/Pango and also LibreOffice. Several situations can be tested; for example different colors and styles, font sizes, different fonts for the characters, and different diacritics.

Finding effect of character styles would be easier, because the reference rendering is available, but for the paragraph styles including the full justifying of the paragraphs, it would be harder to find defects because there is no reference available. In such a situation, analyzing the connectivity of the characters can be a solution, at least for Arabic script languages.

Arabic writing of Allah
Vector version of the previous file)
Rendering Allah in LibreOffice
Allah rendered with pango-view