Tenders for budget 2023

    From The Document Foundation Wiki

    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

    Make Firebird implementation production-ready

    CostEstimate: 24 weeks

    Contact: ?

    Reviewers: ?

    List taken and further curated from tdf#51780 [META] Default to Firebird not HSQLDB in Base (for _new_ files):

    • tdf#105220: Firebird: Insert with direct SQL - RETURNING without values
    • tdf#116935: Firebird: Support for collation in the UI
    • tdf#116936: Firebird SDBC should implement XRowUpdate interface
    • tdf#117513: Firebird: DATALOSS Data updated (new/edit) using the data Beamer window or Dataform in odt/ods file is lost when odt/ods file is closed.
    • tdf#118817: FIREBIRD: EXTRACT Function - WEEK, WEEKDAY, YEARDAY AND MILLISECOND
    • tdf#119628: EDITING: Firebird Embedded: error message when resetting auto increment a second time
    • tdf#120596: Firebird: Editing: Add support for UI data control update of Simple (updatable) views records.
    • tdf#120597: Firebird: Edit: Update Create View UI to support Firebird 'WITH CHECK OPTION' for Simple (updatable) Views
    • tdf#123591: Firebird - Incorrect Pasting of Numeric Data
    • tdf#124054: FIREBIRD: incorrect ASC order with varchar data
    • tdf#124340: Firebird: Autovalue inconsistency when inserting values into table via macro
    • tdf#126941: Date format with frontslashes (15/08/2019) will be changed to format with points (15.08.2019) when input data in a date-field of a tablecontrol of a form.
    • tdf#130345: FIREBIRD: Impossible to create an autovalue key when inserting a new table
    • tdf#132693: firebird - cannot execute multiple SQL commands in one go in Tools > SQL (driver does not implement sdbc::XMultipleResults)
    • tdf#137566: FIREBIRD: some errors during - create Table and insert records via menue "tools/SQL"

    The goal is to reduce dependency with Java.

    Rotated Writer TextFrames

    CostEstimate: 24 weeks

    Contact: Miklos Vajna

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

    The motivation for this item (in addition to the bugreport) is that this is part of tdf#128194, i.e. competitors use the lack of this feature as part their marketing propaganda showing how unusable LO is. What is really hard about this task is that TextFrames can contain complex Writer content (tables, tracked changes, etc) and this content was never rotated anywhere else so far (only simple content in shapes). To simplify, the expectation is that the rendering is rotated, but as long as the "frame edit" mode is active, it's fine to un-rotate the edited content; this is also what Word does This means we need to implement "only" the rendering / layout of the edited content, but no tweaks to cursor positioning, selection is needed

    for the actual week numbers, the sub-tasks are:

    • Document model: need to extend sw::SpzFrameFormat to store the rotation; need to check what else is possible here (flip? mirror? etc) (1-2 weeks)
    • UNO API: scripting read/write for these new properties (1-2 weeks)
    • Layout: this is the hard part. shape text is decomposed to polypolygons and VCL just draws those rotated polypolygons when rotated, while Writer performs all its rendering with direct VCL calls need to design a solution here that doesn't require rewrite of Writer's rendering; perhaps do it similar to semi-transparent text that renders into a metafile and then probably that can be rotated, or something like that. Big risk here, lots of unknowns in a fixed estimate (4-8 weeks)
    • ODT filter: usual work + need to find out how this interacts with textboxes (complex geometry + complex content) (1-2 weeks)
    • DOCX filter: the format has support for this already, so while usually doing anything in writerfilter/ is complex, this should be reasonably straightforward (1-2 weeks)
    • DOC filter: need to find out how best to express rotated text frames here (1-2 weeks)
    • RTF filter: similar to DOCX and DOC (1-2 weeks)
    • HTML filter: sure browsers have rotated text, but what exact markup to choose for import + export needs research & implementing (1-2 weeks)
    • UI: The temporary unrotate for edit + rotate back. Edit the rotation setting (2-4 weeks)
    • Tests: Ideally each feature commit has a matching test, but need to find out if there is something that just works by accident and cover that with a test so it keeps working (1-2 weeks)
    • Documentation: Update of help.git, review where we suggest this is not possible (1-2 weeks)
    • Specification: make sure this gets into ODF next (1-2 weeks)

    Continuous Section Breaks

    CostEstimate: 9 weeks

    Contact: Michael Stahl

    Main bug: tdf#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.

    Add more combo chart types

    CostEstimate: 15 weeks

    Contact: Balázs Varga

    Relevant reports:

    • tdf#40124: FILEOPEN XLS and XLSX: Add support for combined charts comprising of Line, Dot with Lines, Dot with Lines and Markers type data series
    • tdf#113256: .xlsx graphs show wrong numbers in Calc
    • tdf#118887: FILEOPEN XLSX Add support for combined charts of data series types Stacked Area, Scatter with Smooth Lines and Clustered Column
    • tdf#122165: FILEOPEN XLSX Add support for combined charts of data series types Area, Line and Line with markers
    • tdf#127102: FILEOPEN Combined Chart of type stacked area + stacked column loses column stacking
    • tdf#127386: ring chart is different from MSO
    • tdf#127397: FILEOPEN PPTX combined stacked bar - stacked line chart has line category-axis not bottom but left

    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: support math equations in Calc shapes

    CostEstimate: 5 weeks

    Contact: Dennis Francis

    tdf#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: tdf#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

    Better full text justification

    CostEstimate: ? week

    Contact: Khaled

    Reviewers: ???

    tdf#38159When formatting a serious piece of text with full justification, the current algorithm seems to work on a line by line basis. The result is often large unsightly gaps between words. This is not acceptable for professional work, e.g. typesetting a book.

    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:

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

    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: 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: 0.5 weeks

    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

    tdf#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: 8 weeks

    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.

    tdf#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".

    3D rotation of Impress shapes

    CostEstimate: 12 weeks

    Contact: Tomaž Vajngerl, Miklos Vajna

    Bugreports: tdf#143863, tdf#45495 and tdf#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)

    For a discussion about advantages of doing this, see the text following the link.

    AW080 Precision changes: Enhance DrawingLayer Precision

    CostEstimate: 4 weeks

    Contact: Armin

    For general information of "AW080 precision changes" see [3]. There are quite some Precision Changes which should be done, not all of these will be doable in the mentioned time frame. This is a more general entry to suggest spending some time on this and do as much as possible of the points mentioned in the Wiki page. For a discussion of possibilities see the text following the link.

    AW080 Other Changes: Various DrawingLayer enhancements

    CostEstimate: 4 weeks

    Contact: Armin

    For general information of "AW080 Other changes" see [4]. There are many Other Changes/enhancements possible (called so because not fitting to the other categories), not all of these will be doable in the mentioned time frame. This is a more general point to suggest spending some time on this and do as much as possible of the mentioned points. For a discussion off possibilities see the text following the link.

    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.

    Direct Conversion from Primitives to SdrObjects

    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

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

    Replace remaining Carbon functions with non-Carbon functions (macOS)

    CostEstimate: 8 weeks

    Contact: -

    Proposed by: Julien

    LibreOffice contains Carbon and Cocoa parts. The goal is to migrate Carbon parts into Cocoa since the first one is obsolete. (see tdf#130453)

    The following shared libraries are still linked to the Carbon framework:

    • libAppleRemotelo.dylib
    • libmacabdrv1.dylib
    • libuno_sal.dylib.3
    • libvclplug_osxlo.dylib

    Migrating to single modern 2D graphics library

    CostEstimate: 8 weeks

    Contact: Lubos Lunak

    Windows, macOS and Linux gen backend already has the ability to use Skia. To be able to use Skia everywhere (and start using Skia unconditionally at some stage), the remaining backends need to support Skia as well. This includes the headless (svp) backend, gtk3 and kf5 on Linux.

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

    Refactor Calc repaint to Primitives 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.

    Refactor font handling on Mac

    CostEstimate: -

    Contact: -

    Proposed by: Xisco

    Font handling on Mac has been problematic since LibreOffice 4.1, see tdf#69254.

    The idea behind this task is to refactor font handling on Mac and fix the bug mentioned above.

    Refactor Writer repaint to Primitives 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.

    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 [5]. We currently have no parameter associated with our PolyPolygons to represent that and imply these to follow the Nonzero-Rule. This gets problematic with various external Formats supporting both Winding Rules. In the best cases we try to 'Convert' imported PolyPolygons which are not of type Nonzero-Rule to this. This is very runtime-expensive (see some very slow loading imports) and requires fully cut and touch free PolyPolygons, including the whole clipping steps (related to clipping refactor below). For export, we always assume Nonzero-Rule because we know no other. This change is about supporting both Winding Rules at Imports, in the Core, in the graphic stacks (most support it anyways) and at export time (also supported by quite some formats). It is not needed or planned to offer at the UI (from my POV - the diffs what you can do with the different interpretations of topology are subtile and only usable for experts).

    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.

    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

    Splitpane.png

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

    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

    SVG rendering improvements

    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

    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

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

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

    Improve visual appearance of tracked changes

    Main bugs:

    tdf#140157

    tdf#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).

    Slideshow: rendering content on top of videos

    CostEstimate: 8 weeks

    Contact: Miklos Vajna

    tdf#150133 has a PPTX file which contains a media shape and other shapes are on top of it. We currently fail to render this document correctly, since we play videos in an overlay, on top of slideshow content.

    The task is to make sure that shapes on top of the video are rendered on top of the video, like PowerPoint does. This is probably doable by rendering what is supposed to be on top of the video to a bitmap and use it as an 'overlay'. It seems this could also handle transparency.

    Improve release process of ODF versions

    CostEstimate: 7 weeks

    Contact: Regina Henschel

    Reviewers: Michael Stahl

    To make a release of ODF, currently many manual steps are required. Those should be automated as far as possible to support a shorter release cycle of the standard and to allow the TC to concentrate on content-related aspects.

    From a high level view: allow as much automation for OASIS/ISO release as possible, avoiding recurrent time-consuming error-prone task.

    Areas to improve:

    • Tool to fill in release meta data, e.g copyright, release name & date, editor names, from a config template to all needed locations in deliverable files.
    • Tool to generate the reference sections in the text parts from the RNG schema
    • Tool for creation of HTML5 and PDF versions of the normative files, including a HTML5 version of the RNG schema with linked definitions and references.
    • Tool to validate the links in the appendix section, which lists the incorporated JIRA issues and the affected parts in the specification.
    • Tool to generate an element and attribute index.
    • To make such tools possible, it is necessary to create a common document template, base all four parts of the specification on it and check that only styles of that template are used.
    • To make all these sustainable usable and maintainable a guide for a release process is needed. It should not only reflect the OASIS related needs of the release process but in addition where to find and how to use the tools, how to check accessibility and how to validate the deliverable files against their file format standard.

    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

    CostEstimate

    • 12 weeks

    Contact

    • Miklos

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

    References

    CostEstimate

    • ?

    Contact

    • Maxim

    Performance

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

    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:

    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)

    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)

    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

    • 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

    CostEstimate

    • 6 weeks

    Contact

    • Muhammet

    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

    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

    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

    1. Right-to-left script, List of RTL scripts
    2. Craig Lawrenson, "Key considerations when testing right-to-left language sites"
    3. Wikipedia, Complex text layout
    4. Don Vaughan, The World’s 5 Most Commonly Used Writing Systems

    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

      Arabic writing of Allah

    • Vector version of the previous file)

      Vector version of the previous file)

    • Rendering Allah in LibreOffice

      Rendering Allah in LibreOffice

    • Allah rendered with pango-view

      Allah rendered with pango-view

    AI utilities

    Extensions or Built-in use for TTS, STT, OCR and other AI utilities

    CostEstimate: ?

    Contact: ?

    Reviewers: ?

    Text to speech extensions or built-in (different input options: types of files, etc. ; output options: speakers, files (mp3, wav, etc.; import add voices option, i.e., Linux does not have modern voices installed by default; highlighting words or sentences as it reads, translation options, aids for visually impaired))

    Speech to text extensions or built-in (different input options: mic, audio files; output options: plain text, format (subtitles, dialogue, spelling, etc.); feedback of pronunciation, reading-writing feedback, aids for visually impaired)

    Optical character recognition (recognition of text from images, files, etc.; identification of images, searching of copyright issues, etc.)

    Another AI extensions to elaborate summaries, images, graphs, etc; paraphrase text, translation options, enhancing thesaurus, spelling help, styles feedback, suggesting references, making calculations, etc.; (customized input and output)

    Offline also

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