Tenders for budget 2021

    From The Document Foundation Wiki

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


    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.

    Support dark mode

    Darkmode.jpg

    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

    CostEstimate

    Contact

    • (Mike K)

    Finish MAR-based autoupdater

    Updater.png

    Many users complain about the update information that requires to download the installer somewhere else. And if we want to publish updates more frequently it makes sense to finish the MAR based updater ideally with partial capabilities. Other requests ask to include RC's in the updater tdf#48369 and to make font installation optional tdf#91886 (this blocks the inclusion of Luciole font, see tdf#136646). This proposal was on the 2020 list as #1.4.11

    References

    CostEstimate

    • 12 weeks

    Contact

    • Kendy, (Moggi)

    Improvements to SVG rendering

    Svgrender.png

    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

    Styles Highlighter

    Styleshighlighter.png

    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

    CostEstimate

    Contact

    • (Mike K)

    Split-pane documents

    Splitpane.png

    Users ask frequently to have multiple documents in tabs. While MDI/TDI interfaces have drawbacks on usability [1] (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 [2].

    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

    Improvements to Table Styles

    Tablestyles.png

    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.

    From the proposal 1.2.10 of the 2020 tenders: 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.

    References

    CostEstimate

    • 8 weeks

    Contact

    • Miklos

    Support for Editing and Creation of SmartArt

    Smartartimg.png

    From proposal 1.6.3 of the 2020 tenders: 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.

    References

    CostEstimate

    • 16 weeks

    Contact

    • Thorsten

    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)

    Most annoying bugs

    Picked from the list of most-annoying bugs.

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

    References

    CostEstimate

    • 2 weeks

    Contact

    • Thorsten, (Khaled)

    Writer document with tables lost data in cells (apparently) replacing with 0

    References

    CostEstimate

    • ?

    Contact

    • Mike

    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

    CostEstimate

    • 12 weeks

    Contact

    • Miklos

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

    References

    CostEstimate

    • ?

    Contact

    • Maxim

    UX wish list

    Some potential GSoC projects could also be tendered.

    Unit in numerical inputs

    Numinput.jpg

    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

    Keyboard customization

    Customize.jpg

    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

    CostEstimate

    • 6 weeks

    Contact

    • Muhammet

    Application Themes (formerly known as Mozilla Persona)

    Apptheme.png

    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)

    Multi-color gradient

    Gradientimg.png

    From the proposal 1.2.16 of the 2020 tenders: 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: 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

    CostEstimate

    • 10 weeks

    Contact

    • Armin

    Accessibility

    Improve the accessibility checker for PDF/UA

    CostEstimate: 3 weeks Contact: Tomaz Vajngerl, Miklos Vajna

    There has been already an effort to add initial PDF/UA support in LibreOffice, see blog post. The goal of this task would be to improve that up to the state that it could be enabled in non-experimental mode.

    This would include the followings: detecting badly visible formatting, fake footnotes/headings/tables, floating content, accessibility aspects of formulas, image captions, "information by formatting" problems, tables for formatting, bad contrast of text, bad background images, typewriter-style formatting (empty paragraphs to add vertical space, space to add horizontal space), and bad underlined text.

    Topics from the 2020 budget list

    Many topics have been collected over the years and made it into the 2020 budget list.

    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.

    Core Code Refactorings and Cleanups

    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
    • 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

    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.

    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.

    AW080 Paradigm changes: SdrObject Homogen Transformations (cc'ed from 2018 suggestions)

    CostEstimate: 8 weeks

    Contact: Armin

    For general information of "AW080 paradigm changes" see [3]. 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 [4]. 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 [5]. 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 [6]. 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 [7]. 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: 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 [8]), 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.

    The changes are mostly related to text selection in EditEngine and mouse pointer/cursor. In the EditEngine, the main effort would be changing the usage of DrawSelectionXOR() function. This grep search shows the number of usages, in which all of them are DrawSelectionXOR() usages:

    $ git grep XOR editeng/|awk -F: {'print $1'}|awk '{a[$0]++} END{for (k in a) print k,a[k]}' RS='space:+' 

    editeng/source/editeng/impedit4.cxx 14
editeng/source/editeng/editview.cxx 17
editeng/source/editeng/editeng.cxx 4
editeng/source/editeng/impedit.cxx 25
editeng/source/editeng/impedit2.cxx 7
editeng/source/editeng/impedit.hxx 2
editeng/source/editeng/editundo.cxx 2
editeng/source/editeng/impedit3.cxx 1

    Beyond that, there are needed changes that was previously defined as an EasyHack (tdf#38844), in which received a few patches. In this case, most of the patches were actually refactoring. There are around 20 instances of such needed changes remaining:

    $ git grep RasterOp::Xor|grep -v wmf|grep -v emf|grep -v workben|awk -F: {'print $1'}|awk '{a[$0]++} END{for (k in a) print k,a[k]}' RS='space:+' 

    vcl/source/gdi/mtfxmldump.cxx 1
sw/source/uibase/utlui/shdwcrsr.cxx 1
drawinglayer/source/processor2d/vclhelperbufferdevice.cxx 2
vcl/source/outdev/gradient.cxx 2
vcl/source/gdi/print.cxx 1
drawinglayer/source/processor2d/vclpixelprocessor2d.cxx 1
vcl/source/filter/ipict/ipict.cxx 2
vcl/qa/cppunit/outdev.cxx 2
vcl/source/filter/imet/ios2met.cxx 2
vcl/backendtest/outputdevice/outputdevice.cxx 3
svx/source/xoutdev/_xoutbmp.cxx 1
vcl/qa/cppunit/svm/svmtest.cxx 1
vcl/source/window/window.cxx 1
vcl/source/filter/svm/SvmConverter.cxx 1
vcl/source/outdev/outdev.cxx 1
vcl/source/gdi/virdev.cxx 1

    https://bugs.documentfoundation.org/show_bug.cgi?id=38844 is related

    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.

    Refactor Writer repaint to Primtives and VOC usage

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

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


    Bitmaps in vcl: Merge RGB and A layer into one

    CostEstimate: ???? weeks

    Contact: Lubos Lunak? Caolán McNamara?

    • Currently, we store RGB and Alpha/Transparency separately. This is both very awkward, and contrary to how modern graphics APIs work
    • Ideally we should store just one layer
    • However, this layer is sometimes treated as a mask, and some code depends on that

    Blocking features

    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.

    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.

    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)


    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

    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:

    QA and Automated Testing

    Cleanup & further improve ODF conformance

    CostEstimate: 8 weeks

    Contact: Thorsten Behrens

    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

    Ideas added after 2021-01-25

    These were added after the current deadline, so this is more just a placeholder for ideas that could be interesting for a next round.

    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.

    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.

    Retrieved from "https://wiki.documentfoundation.org/index.php?title=Development/Budget2021&oldid=674232"