Development/Under-loved areas

From The Document Foundation Wiki
Jump to navigation Jump to search

This page is meant to build a list of under-loved areas of the LibreOffice codebase where the ESC recommends more attention and would benefit from investment of resources without duplicating existing investment. The intention is to list higher level areas, like RTL or CTL support, or Base (no micro-ideas, please).

See the ESC meeting minutes: 2022-05-26 for more context.

Areas have names of people who would be good contacts to discuss this area:

Use of Java in Base

Default embedded backend

The main goal is to replace the HSQLDB part with a non-java database that also allowed embedding, with a compatible license and with a not dead community, Firebird is the preferred solution.

  • Complete Firebird Support to make embedded Firebird the functional equivalent of embedded hsqldb (Caolán)
  • Complete auto migration of existing hsqldb databases to Firebird (Caolán)

Replace Java report generator code

The whole reports part is dependent on a set of old Java (Pentaho Reporting/JFreeReport) external components (Caolán)

  • Migrate the Java report generator code to C++

[META] Database related bugs

(Noel) There is exactly zero open source report designer in C++, and about 4 open-source Java solutions. IMNSHO we'd be best off either updating to the latest Pentaho release or switching to Eclipse BIRT. Building our own report designer in C++ is simply not feasible.

(Ilmari) There is at least one actively developed open source (LGPL) report designer and generator in C++ called LimeReport.

RTL/CTL

Right to left support and Complex text layout are areas that have a long history of bit-rotting, and the code is far from obvious. A combination of VCL having an underlying canvas mirroring implementation for some operations but not others, and various co-ordinate systems to get this right makes things a problem to maintain. The various problems. In addition there are fewer tests for RTL/CTL specific issues which makes bit-rot here very likely as the code is changed. In addition the UI is altered in CTL mode to show different widgets expanding the testing surface for this case cf. meta bug and some explanation of kashida issues (Eyal Rozenberg, Khaled Hosney, Martin Hosken, Justin Luth, Lior Kaplan)

CJK

Good Chinese, Japanese and Korean support brings a number of critical features, many of which are implemented in LibreOffice but some important pieces are missing. It is hard for the non-expert to notice regressions in this area and more work would be helpful here. There is a meta issue with a number of the tickets (Mark Hung, Shinji Enoki)

Accessibility

While LibreOffice has some great internal a11y support and bridges to native platform APIs, this is an area that can rapidly bit-rot. Furthermore, to get a good end-to-end result it is necessary to work with AT vendors/projects such as Orca, NVDA or JAWS in a sustained longer-term fashion to ensure that APIs turn into useful end-user functionality for people with disabilities, and that regressions are avoided. (Michael Weghorn)

There is a meta issue for a11y too.

Document Level Accessibility

Some parts of the document are not accessible through the keyboard, like e.g. embedded objects, images and such, which makes it nearly impossible to AT users to interact with them. (Colomban Wendling)

Some relations are missing, like for annotations and footnotes (s. e.g. tdf#96481). Also, there is a lack of semantics for change tracking leading to messy output from ATs (s. e.g. tdf#96487). These could be seen as smaller and simpler issues. (Colomban Wendling)

Only on-screen elements of the document are exposed to ATs. This is on purpose probably for performance so elements are lazy-loaded and destroyed, but it has non-trivial impact on various AT features. There are some things supposed to help mitigate the issues (like flows-from and flows-to relationships), but they present their own sets of issues. Related bug report: tdf#35652 (Colomban Wendling)

Widget Level Accessibility

Some specific dialog/sidebar/toolbar/notebook widgets may still lack accessibility. A lot of toolbar widgets in Writer don't seem to be accessible, like the ones to create forms and such. Custom widget are particularly prone to this, e.g. Extensions Dialog, NotebookBar (Caolán, Devin Prater)

File Format Support

a11y-related attributes not being properly set in docs, in particular when exported to other formats like OOXML, X)HTML and PDF. Note: Institutional consumers of LibreOffice are likely interested in PDF/UA support as a proxy for EU Web Accessibility Directive conformance. (Caolán, Christophe Strobbe, Michael Weghorn)

UIA support on Windows

For Windows, LibreOffice currently supports the IAccessible2 accessibility API based on MSAA (Microsoft Active Accessibility), but not UIA (User Interface Automation).

In MS Office, screen readers have largely switched to using UI Automation (UIA) for access to all things documents and UI. This is primarily because of Narrator, which doesn't support anything other than UIA (MSAA and IA2 are only supported by way of an IA2 to UIA bridge, which is slow and unreliable). As a consequence, Microsoft never got on the IAccessible2 bandwaggon, but has pushed the UIA implementation in the Chromium project so they can stop using the IAccessible2ToUIA Bridge for Narrator's access to web content. There were even plans and experiments to switch Firefox over to UIA. Qt has also switched its a11y implementation on Windows from MSAA and IAccessible2 to UIA (commit). JAWS does support IAccessible2, but only if it needs to, like in Firefox, and some parts of Chromium-based browsers. However, with the UI Automation implementation for the latter becoming stronger, there might be a time when JAWS moves to UIA for web content support in Chromium browsers. With Windows 11 having an even stronger UIA implementation than 10, more things are being done through that interface rather than traditional MSAA or IAccessible2 channels where possible. And as has been said elsewhere, UIA properties and events are even very accessible from within the JAWS scripting language, which makes this even more compelling because the end user experience can be customized further. As IAccessible2 is an extension of MSAA, and MSAA is largely deprecated by Microsoft, it will probably never get the same treatment.

So, in the long term, and as resources permit, the more future-proof way forward for LibreOffice on Windows might be to switch over to an UIA implementation as well.

Since current versions of AT may rely on IAccessible2 being used by LibreOffice (at least NVDA does in its "soffice" app module), coordination with AT providers may be needed in case of fundamental changes. (Double-check this, at least the Qt announcement when switching from MSAA/IAccessible2 to UIA mentions: "Since the accessibility changes in Qt 5.11 are internal, existing accessible applications are not expected to require any changes to utilize the improved functionality provided by UI Automation. Compatibility with MSAA-only assistive tools is maintained by bridge components built in the UI Automation framework itself." Whether that also works for AT having LibreOffice-specific app modules needs a closer look.) (Christophe Strobbe, Marco Zehe, Michael Weghorn)

Commits per LOC sheet

Some useful data can be found in: [1] which has a rough ranking of commits per LOC over the last year. (M. Meeks )

File:Liveness-2022-06-3.ods: Commits mentioning a Bugzilla ticket per LOC over the last year (Xisco)

File:Bugzilla-stats.ods: Bugs reported in 2021 and the percentage of open vs fixed issues (Xisco)

Writer/Web

This is the "HTML editor" mode of Writer with a single huge canvas, and there are many problems with this mode. An easy workaround is to force loading even HTML files into normal Writer and then forget that Writer/Web exists at all. At the same time, perhaps it's a useful piece of the office suite, but then it doesn't get the care it deserves. (Miklos)

XForms support

See here for more details about this feature. XForms is a W3C spec, so probably it's useful functionality, but almost no improvements were done to it in several years. (Miklos)


macOS support

Related commits in the last 2 years : 98 (git log --since '2 year ago' --oneline vcl/osx/ | wc -l)

List of open macOS bugs in Bugzilla: 358. (Xisco)

Screenshots

Command Make Screenshots to get screenshots at build time (for all languages) is currently broken as too many screenshots don't depict the full dialog. AFAIK, the feature was contracted by TDF.

Screenshots Meta bug (Ohallot)