Tenders for budget 2022

    From The Document Foundation Wiki


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

    See what was on a similar page a year ago.

    Traditionally we have prioritized tasks that there is no probability that will be delivered for free by someone else, in order to conserve TDF's budget. As such larger, less glamorous structural things are interesting, alongside put features.

    === My idea ===
    
    '''CostEstimate: 1 week'''
    
    '''Contact: John'''
    
    '''Reviewers: Hannah, Josphine'''
    
    Short description
    

    Requirements:

    • costs are stated in rough guestimate person weeks, so that it is possible to rank the proposals against each other.
    • costings should be created by or signed-off by a certified LibreOffice developer.
    • reviewers: these are people willing to oversee the project, help review the tender, sign off on its completion and help adminster this task for TDF.

    Blocking features

    Finish Firebird implementation

    CostEstimate: ?

    Contact: ?

    Reviewers: ?

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

    The goal is to reduce dependency with Java.

    Floating multi-page tables in Writer

    CostEstimate: 24 weeks

    Contact: Tamás Zolnai

    See e.g. https://bugs.documentfoundation.org/show_bug.cgi?id=61594, Word can have tables which are wrapped around by body text and they still split across multiple pages. Writer can't do this. The idea would be to have SwTabFrame not only inherit from SwFlowFrame, but also from SwFlyFrame to reach this. Cost is large because table layout is complex.

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

    Look-ahead styleref field for Writer

    CostEstimate: 1.5 weeks

    Contact: Miklos Vajna

    Fix https://bugs.documentfoundation.org/show_bug.cgi?id=86790. Forward-look version of the chapter field, \l in Word. ECMA-376 part 4, 2.16.5.66 STYLEREF has the Word behavior.

    Go through the doc model, UNO API, layout, filters, UI process and add support for this.

    Rotated Writer TextFrames

    CostEstimate: 24 weeks

    Contact: Miklos Vajna

    https://bugs.documentfoundation.org/show_bug.cgi?id=82627 Text from DOCX shapes is always mapped to Writer TextFrames so complex content can be represented (tables, etc). Writer TextFrame content can't be rotated, so the task is to add rotation support to TextFrames.

    Continuous Section Breaks

    CostEstimate: 9 weeks

    Contact: Michael Stahl

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

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

    Interdependant change tracking

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

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

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

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

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

    Add more combo chart types

    CostEstimate: ???

    Contact: ???

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

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

    XLSX Aggressive Competitors tracker: gridlines for 3d line charts

    CostEstimate: 2 weeks

    Contact: Dennis Francis

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

    Make sure that the feature works nicely, including correct anti-aliasing.

    XLSX Aggressive Competitors tracker: support math equations in Calc shapes

    CostEstimate: 5 weeks

    Contact: Dennis Francis

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

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

    XLSX Aggressive Competitors tracker: table styles

    CostEstimate: 24 weeks

    Contact: Dennis Francis

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

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

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

    Chart: data table rendered below chart

    CostEstimate: 7 weeks

    Contact: Dennis Francis

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

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

    Pivot Table – Compact view

    CostEstimate: 9 weeks

    Contact: Lubos Lunak

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

    Missing ODF Features (general collection)

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

    Contact: Regina, Michael Stahl

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

    • SVG Gradients: already tracked under its own item "Multi-color gradient"
    • persistent xml:id on lots of elements in all applications - 02-20 weeks depending on scope
      • sw: most important would be the ones that create noise in diffs
        • <text:list>
        • <text:changed-region>
        • these don't have xml:id, only text:id, so noise is the only problem:
          • <text:toc-mark-start>, <text:user-index-mark-start>, <text:alphabetical-index-mark-start>
      • sw:
        • <draw:frame>
        • <office:annotation>
        • <draw:object>
        • <draw:object-ole>
        • <draw:text-box>
        • <text:list-header>
        • <text:list-item>
        • <text:numbered-paragraph>
        • <table:table>
        • <table:table-cell> - these can be split and merged which complicates implementation
        • <table:table-column>
        • <table:table-row>
      • svx:
        • <draw:page-thumbnail>
        • <draw:caption>, <draw:circle>, <draw:connector>, <draw:control>, <draw:custom-shape>, <draw:ellipse>, <draw:frame>, <draw:line>, <draw:measure>, <draw:path>, <draw:polygon>, <draw:polyline>, <draw:rect>, <draw:regular-polygon>
        • <office:annotation>
        • <draw:a>
        • <draw:applet>
        • <draw:floating-frame>
        • <draw:image>
        • <draw:object>
        • <draw:object-ole>
        • <draw:page>
        • <draw:plugin>
        • <draw:text-box>
      • chart2:
        • <chart:chart>
        • <chart:data-point>
        • <chart:plot-area>
        • <chart:series>
      • sd:
        • <anim:par>, <anim:seq>, <anim:iterate>, <anim:audio>, <anim:command>
        • <presentation:sound>
        • <table:table>
        • <table:table-cell>
        • <table:table-column>
        • <table:table-row>
      • forms:
        • <form:number>, <form:date>, <form:time>
        • <form:password>, <form:file>, <form:fixed-text>, <form:button>, <form:image>, <form:radio>, <form:frame>, <form:image-frame>, <form:hidden>, <form:grid>, <form:value-range>, <form:generic-control>
        • <form:text>, <form:textarea>, <form:formatted-text>, <form:combobox>, <form:listbox>, <form:checkbox>
      • editeng:
        • <text:p> - these can be split and merged which complicates implementation
        • <text:list>
        • <text:list-header>
        • <text:list-item>
        • <text:numbered-paragraph>
      • sc:
        • <table:table>
        • <table:table-cell>
        • <table:table-column>
        • <table:table-row>
        • <text:changed-region>
    • (own item below) <draw:regular-polygon> missing completely -> moved to own item, see below
    • <draw:page-thumbnail> usage other than as Notes in Impress
    • <text:page-sequence> missing completely
    What does this do? is it a way to set a sequence of page styles that is completely independent of the properties of the content of a text document? why was this added to the standard?
    It is way to layout documents as it is down in desktop publishing applications like Scribus.
    • <office:image> is missing completely but nobody wants it anyway
    • Attribute draw:copy-of of a <draw:frame> element
      • this is similar to virtual SdrObject in header/footer in sw? except that each of them has its own position and needs to be exported - 4 weeks?
    • (own item below) attribute svg:d of <draw:path> some of the possible commands are missing
    • (own item below) concentric gradient fill of custom-shapes tdf#144925
    • draw:wrap-influence-on-position
      • "iterative" is effectively unimplemented since 2004, but it's not obvious why we would want to add it now as it's obviously the option most likely to introduce new layout performance problems
    • (own item below) draw:shadow-offset-x/y only partially implemented
    • style:overflow-behavior for text box
      • "auto-create-new-frame" only makes sense for sw, 6 weeks
    • HSL color animation
    • fo:hyphenate tdf#106733: in sw, 3 days
    • text:footnotes-position value 'text' not implemented tdf#90921
      • this is unlike any other footnote mode and could cause tricky oscillations, 4 weeks
    • (own item below) The attribute draw:text-rotate-angle is interpreted, but there exists no user interface to change it.

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

    CostEstimate: 2 weeks

    Contact: Regina, Michael Stahl, Armin

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

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

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

    Missing ODF Features: Concentric gradient fill of custom-shapes

    CostEstimate: 2 weeks

    Contact: Regina, Michael Stahl, Armin

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

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

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

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

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

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

    CostEstimate: 3 weeks

    Contact: Regina, Michael Stahl, Armin

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

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

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

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

    CostEstimate: TODO

    Contact: Regina, Michael Stahl, Armin

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

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

    CostEstimate: 2 weeks

    Contact: Regina, Michael Stahl, Armin

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

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

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

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

    Avoid ODF roundtrip for embedded objects in Impress and elsewhere

    CostEstimate: ?

    Contact: Noel Grandin

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

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

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

    Decouple master slide and layouts

    CostEstimate: 8 weeks

    Contact: Thorsten Behrens

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

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

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

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

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

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

    3D rotation of Impress shapes

    CostEstimate: 12 weeks

    Contact: Tomaž Vajngerl, Miklos Vajna

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

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

    Regina (talk):

    I support this suggestion. The associated bug is "(PPTX-3D) - [META] PPTX 3D model issues" tdf#120388. I had already started to work on the problem in https://gerrit.libreoffice.org/c/core/+/113445 with the idea to use the extrusion of custom shapes. I had abandoned it, because I have noticed, that there exists errors outside import/export filter, which need be solved beforehand. Still not solved from those are tdf#145700 and problems with property "RotationCenter" tdf#145904 and wrong calculation of "Origin" tdf#145956.
    The custom shape extrusion (including Fontwork) is already implemented to use the 3D objects render code.
    3D-rotation other than z-rotation and 3D-projection of text in custom shapes need extension to the ODF format. Other not directly on custom shapes in ODF representable features are light rigs with three lights and light rigs with colored light.
    To get better compatibility with the UI of MS Office, the dialog "3D-Settings" would need to be extended in case of a solution with custom shapes.
    For perspective projection of images an implementation similar to command .uno:Shear is currently missing, we have only simple shear, which would only fit to parallel projection.

    Core Code Refactorings and Cleanups

    AW080 Paradigm changes: SdrObject Homogen Transformations

    CostEstimate: 8 weeks

    Contact: Armin

    For general information of "AW080 paradigm changes" see [1]. This single Paradigm change is about using Homogen Transformations (Linear Algebra) throughout the DrawingLayer Model definitions (mainly but not only SdrObjects). I was doing this once for AW080 and know how this can work and what is doable. For a discussion about advantages of doing this, see the text following the link.

    AW080: Removal of NBC Methods, Improve DrawingLayer Broadcasting

    CostEstimate: 2 weeks

    Contact: Armin

    For general information of "AW080 paradigm changes" see [2]. This Paradigm change is about getting rid of the old NBC-Methods (which stands for NonBroadCast BTW) in DrawingLayer and cleanup of the Broadcasting/Messaging part of DrawingLayer involved with that. I was doing this once for AW080 and know how this can work and what is doable. Motivation: The original idea probably was that multiple changes at SdrObjects would trigger multiple change-messages which are sent as broadcasts to multiple listeners, currently over multiple channels. This has some problems:

    • It is not safe in the sense that sending an initial and terminating message is guaranteed since doing changes calls helper methods which do not really know if their change will be the last change in the task to perform
    • Some changes seem to not have been aware that not only a terminating message is needed, but also an initial one. To successfully invalidate visualization regions it is necessary to invalidate *both*, the covered part at start and end. If this is missed initially, the change will potentially modify the initial area covered and it will no longer be available. These broadcasts are not only used for invalidates, but for multiple purposes
    • This has led to quite some problems in the past and needs check/cleanup to find remaining places. It is not that dramatic anymore due to also using VOC information nowadays for these purposes, but only consequently for everything in Draw/Impress. If that was not clear yet, these mechanisms have to also work in the other apps (Writer/Calc/Chart/Math)
    • The broadcasting can be unified and secured, done something in that direction in AW080 already, but this is too old now, can be used as roadmap but needs new development. The current state is that the broadcasting has grown over the years and no one knows which ones are still needed and which not, neither if these are complete. All this needs check/rework to make more reliable and more performant - e.g. there will be superfluous things that may be removed completely or replaced my more efficient methods (not registering at general broadcast when needing only specific infos about specific changes of specific objects)

    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.

    Bitmaps in vcl: Merge RGB and A layer into one

    CostEstimate: 5 weeks

    Contact: Lubos Lunak Caolán McNamara?

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

    Bitmaps in vcl: Use a native format/depth

    CostEstimate: 2? weeks

    Contact: Lubos Lunak

    • When code uses a VCL Bitmap/BitmapEx, the code has to ask for a specific format as such 24bpp. But a VCL backend may not support that specific format, for example at least Cairo and Skia store 24bpp as 32bpp XRGB. This means that the bitmap data will be converted to a suitable format by the backend, which may have a noticeable CPU and/or memory cost, especially in cases like documents with large images.
    • Bitmaps should make it possible to ask for a suitable format (with a minimal bpp) and code using bitmaps should adapt to it.
    • At least image loaders and other possible generators of large bitmaps should be adapted.

    Bridge the gap between drawinglayer and VCL

    CostEstimate: ~2 weeks

    Contact: Tomaž Vajngerl

    In VCL, we can't currently use drawinglayer primitives because drawinglayer depends on VCL for the VCL pixel processor. The idea is to integrate the VCL processor into VCL itself and change the drawinglayer in such a way that the primitives are separated from the processors, so that they become independent of any "backend". After that is done, we can use primitives in VCL and can process a PrimitiveContainer directly in OutputDevice. This is important because we can, depending on the backend, do optimisations with the primitives directly and can bind resources to the life-cycle of a primitives.

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

    Font subsetter for font embedding

    CostEstimate: 4 weeks

    Contact: Thorsten Behrens, Khaled Hosny

    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.

    Migrate from Carbon to Cocoa framework on Mac

    CostEstimate: -

    Contact: -

    Proposed by: Julien

    LibreOffice contains Carbon and Cocoa parts. The goal is to migrate Carbon parts into Cocoa since the first one is obsolete. (see https://bugs.documentfoundation.org/show_bug.cgi?id=130453)

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

    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.

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

    SfxItem/SfxItemPool/SfxItemSet rework

    CostEstimate: 10 weeks

    Contact: Armin

    I am already experimenting with this, just adding here for completeness of ideas. This would lead to a much simpler, modern attribute/property system:

    • no int-slots, no WhichID-matching mayhem
    • just type-based
    • no global/per-app ItemPools
    • no need to define at each SfxItemSet what Items are allowed
    • on-par or better speed and mem usage (hard to get - do not underestimate the speed of the current ItemSet stuff :-))
    • easier to use for newbies :)

    No concrete time/weeks to be given, this will be a long-time project, but could nontheless need support...

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

    CostEstimate: 8 weeks

    Contact: Armin

    Currently only Draw/Impress knows Styles for DrawObjects. If these DrawObjects get copied to Writer or Calc (or Chart), the Styles are lost and get 'stamped' to the SdrObjects using a method called 'BurnInStyleSheetAttributes()' - the name is program, make all attributes hard attributes... Goal would be to also have DrawObject Styles in all Apps and to maintain them on Load/Save/Copy/Paste - Styles are mighty and useful nonetheless. This would be a multi-stage approach, so probably needs to be refined in finer granularity and broken to smaller ideas:

    • Unify Styles in the core to allow easier integration to all apps (currently all apps use similar but different impls - same same but different...)
    • Adapt this in Draw/Impress - currently using some wild string patterns like <name>~LT<family>, look for SD_LT_SEPARATOR definition and how/where this is used
    • Probably adapt Styles in other apps to a unified method to deal with them
    • Add handling/UI/Load/Save/Copy/Paste to all apps, adapt Draw/Impress to support that

    Time is very hard to estimate, I would propose better to do something like spending some amount of weeks and try to get as far as possible.

    UNO API at SdrObjects

    CostEstimate: 6 weeks

    Contact: Armin

    Currently SdrObjects and their UNO API implementation(s) are separated and reference each other vice-versa (which already caused/causes some lifetime problems). This seemed to be a decent method to do this when it was initially done, but also causes some runtime problems. Directly implementing at SdrObject level with modern methods (e.g. registering slots/calls using lambdas, no longer using endless if/else steps, ...) has the potential to greatly speed up and enhance the UNO API in that areas. Thus, all areas where this is used would profit - Chart, Load/Save, you name it. Time is very hard to estimate, I would propose better to do something like spending some amount of weeks and try to get as far as possible.

    Winding-Rule support for PolyPolygon Handling

    CostEstimate: 2 weeks

    Contact: Armin

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

    Unify Writer and Draw Images

    CostEstimate: 8 weeks Contact: Thorsten

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

    Enhancement requests with high importance

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

    Dark mode

    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)

    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 [7] (and provides ground to resolve the request as WONTFIX), the use case of proof reading two documents side-by-side is clear. Similar request might be to split the current document, as known from MS Office [8].

    References

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

    CostEstimate

    • 12 weeks

    Contact

    • Miklos

    Styles Highlighter

    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)

    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

    Table Styles improvements

    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.

    Currently drawing shapes are stored in binary format in the Gallery. That makes it impossible to maintain them. For example some "Fontwork" shapes (a hidden Gallery theme) use bitmap fillings, which do not exist any more, because those shape were originally from StarOffice. Or the dummy text "Fontwork" cannot be replaced with a localized one. Similar happens with shapes created in Draw. If someone creates a Gallery theme from a set of his shapes, and this theme is then deployed (extension or included), it is not possible to maintain the set afterwards, because the Gallery theme contains only the binary format. Making Gallery themes from draw objects for other users is currently very hard. That prevents community members from contributing. Gallery themes would be a wonderful opportunity for community members to make LibreOffice better usable in special areas (garden planing, engineering, education, interior design, for example). So my suggestion is to make a tender, that replaces the current format and internal treating with a version, that makes it possible to easily generate a set of drawing shapes as theme, deploy Gallery themes, maintain themes, adapt foreign themes to personal or localizing needs.

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

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

    References

    CostEstimate

    • 8 weeks

    Contact

    • Miklos

    UNO API / SDK Improvements

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

    Dialog Designer improvements

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

    References

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

    CostEstimate: 6 weeks

    Contact: Samuel Mehrbrodt

    Improve the experience of the CPP SDK

    CostEstimate: 4 weeks

    Contact: Bjoern

    UNO API changes subscription/feedback channel

    CostEstimate: 1 week

    Contact: Bjoern

    The simplest solution (KISS for a start) would be e.g.:

    • an archived mailing list (uno-changes@ ...)
    • an bot that puts every API change on that list, cc'ing the author of the change,
      • someone replying to the API change also reaches the author of the change
    • bot that filters for the API change discussions and put notifications and RSS feeds on api.libreoffice.org

    Localization and linguistic

    Better support for multi-language documents

    CostEstimate: 5 weeks

    Contact: Martin Hosken

    Better support for documents with multiple languages:

    • language at cursor -> keyboard changes accordingly
    • change keyboard -> language switches accordingly

    I.e. when a user changes keyboard, the text language changes. Likewise when a user moves their cursor into text of a different language, the keyboard switches. No bug raised on this yet.

    • UI-level: per-language styling (only in the UI)

    E.g. font would change automatically based on if I edit a piece of English or Thai text.

    Language Extensions

    CostEstimate: 4 weeks

    Contact: Martin Hosken

    Tim Eves has been doing good work on allowing dynamic loading of locale information as part of an extension. We have already added the capability for a language to be added to Libo via an extension. This takes it a step further and allows the locale information to be loaded as part of the language extension. Thus you would be able to have language specific sorting, dates, etc. But he has too much on his plate and would value help in getting the project finished. It's almost to the point of testing. The project would mean that a user can add support for a language to libo without having to rebuild libo. This may not sound much to libo developers, but it's huge in minority language communities. After all do you really want to ship libo with support for 2000 languages and the length of language selector UIs that would be needed, the increased size, etc. People are only interested in adding local support for a couple of languages at most. But everyone wants a different set of 'a couple of languages'.

    Localization support for templates

    CostEstimate: ??? weeks Contact: Miklos Vajna

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

    Normalized spell checking

    CostEstimate: 1.5 weeks

    Contact: Martin Hosken

    Spell checking should be done in either Normalization Form Canonical Composition (NFC) or Normalization Form Canonical Decomposition (NFD) and the dictionary encoded appropriately. Currently one has to produce a spelling dictionary with both in and that's no fun. It's a matter to normalize the copy of the string being spell checked.

    See https://www.wikiwand.com/en/Unicode_equivalence#/Normal_forms for details on these concepts.

    Miscellaneous

    In-app rating / un-structured feedback

    CostEstimate: 4 weeks Contact: Miklos Vajna

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

    Power optimization research

    CostEstimate: 6 weeks

    Contact: Luboš Luňák

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

    Stabilize cross-page table layouting

    CostEstimate: 1 week per bug (13 weeks)

    Contact: Michael Stahl?

    Proposed by: Telesto

    Table rendering is still an issue. Especially splitting tables over multiple page with embedded split tables in it. It causes layout changes entering at table. Pages going out of range. Edits can cause layout-loops. Crashes. Footnotes start jumping around. Different page counts on file-opening.

    References

    Improve visual appearance of tracked changes

    Main bugs:

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

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

    CostEstimate: 24 weeks

    Contact: László Németh

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

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

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

    ODT export nondeterminism

    CostEstimate: 1 week

    Contact: Michael Stahl

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

    Fix accessibility issues

    CostEstimate: 4 weeks

    Contact: Michael Weghorn

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

    Most annoying bugs

    Picked from the list of most-annoying bugs.

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

    See also Support embedded objects in editeng text

    References

    CostEstimate

    • 12 weeks

    Contact

    • Miklos

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

    Note pin.svg

    Note:
    This was fixed before tendering

    References

    CostEstimate

    • 2 weeks

    Contact

    • Thorsten, Xisco, (Khaled)

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

    References

    CostEstimate

    • ?

    Contact

    • Maxim

    Performance

    Showing and saving comments in Calc

    CostEstimate: 2 weeks

    Contact: -

    Proposed by: Telesto

    Calc and comments don't go well together. The main issue high CPU load when scrolling a document with many comments. A small assessment of issue can be found here: tdf#76324. There's probably also a performance issues in the area of opening/saving a file with lots of comments. Some technical info here tdf#119650

    Showing comments in Writer

    CostEstimate: 3 weeks

    Contact: -

    Proposed by: Telesto

    Writer and comments don't go well together. The main issue a high CPU when scrolling a document with many comments. A small assessment of issue can be found here: tdf#61558

    QA and Automated Testing

    MSO compatibility test framework using Win API

    CostEstimate: 6 weeks + VMs

    Contact: Tamás Zolnai

    • Microsoft published some API to work with Office applications.
    • It can be a good idea to create a test framework which tests MSO file format compatibility by opening files both with LibreOffice and Microsoft Office and checking document properties (e.g. number of pages, shapes, tables) using LO API and Windows API.
      • Of course this test framework would be Windows only.
    • First test can be for example a check for the number of tables in the imported document compared to the table number produced by Microsoft Office import.
      • After this simple test is implemented, we can run this on thousands of documents (this also means we can guarantee a specific level of compatibility by adding these tests and running them on lots of documents (also good for regression testing)).
      • Later the compatibility level can be increased.
    • Another good starting point can be some validation test of LO exported documents.
      • Just open saved documents in MS office automatically and check whether MSO can open them without a problem (e.g. tdf#104787)
      • Validation tools (like Open XML SDK) often shows false positives and also can happen they don't show a problem which actually makes MSO to fail opening a document. So better to test compatibility directly using MSO.

    A reasonably future-proof automated testing plan

    Regular scan-build reports like we do with CppCheck

    CostEstimate: 1 week

    Contact: Luke

    Regular scan-build reports like we do with CppCheck. See also: https://wiki.documentfoundation.org/Development/Clang_Code_Analysis

    Tests for drawinglayer and basegfx

    CostEstimate: ~3 weeks

    Contact: Tomaž Vajngerl

    Drawinglayer currently has almost no test, which is really sad considering it is the core of graphic drawing in LibreOffice. The important is to get the tests for basic primitives, visitors and the decompositions of primitives and the basic tools. Another very important part is basegfx, which contains some test, but the coverage is very limited.

    Fix unreliable unit tests

    CostEstimate: 3 weeks

    Contact: Michael Stahl

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

    UX wish list

    Some potential GSoC projects could also be tendered.

    Application Themes (formerly known as Mozilla Persona)

    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)

    Document Themes

    CostEstimate: ~6 weeks

    Contact: Tomaž Vajngerl

    Document themes are a simple way to allow users to quickly & consistently restyle the entire document. This however needs changes to everywhere we use font attributes, colors attribute and shape attributes as they need to be changed by a theme identifier. When designing with a theme support, instead of defining the attribute value (for example the text color #00FF00), you define a variable identifier instead (color "accent1"), which is then dependent on what the current theme uses. When the whole document is defined like this, the user can easily change the appearance of the whole document with just changing themes. This is also quite important for the OOXML support as MSO has this feature for a long time.

    Currently there is a start of this at feature/themesupport, but it is just a POC, however it lays a bit of the groundwork for the UI and core. What is still needed to complete this is:

    • add support for ODF
    • use the theme support in ooxml
    • change all the UNO API where color and font is used to allow for definition of the theme variables
    • UI to change themes
    • UI to create new themes

    Keyboard customization

    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

    Multi-color gradient

    Gradientimg.png

    One highly missing feature are Multi-Step-Gradients. This shows in quite some places, e.g. at import of external formats which support these - as such, it is also a MSO interop problem. We have to reduce to Two-Color-Gradients which are as 'similar' as possible. This is also true for the gradient geometry we have to use one of our old internal formats that comes as close as possible to more modern formats. This is also true for SVG-Gradients currently. We should be able to support these directly and add these to our internal gradients. These changes have quite some aspects of which not all will be solvable in one step. It should include: a) Support in core (model/rendering), b) Support in FileFormats (ODF for MultiColorSteps, SVG-Gradients, partial adaption of external format im/export filters), c) Support in UI (MultiColorSteps for existing and SVG-Gradients - (not sure how lean this can be, probably no initial support for interactive Gradients - yes we have something like this already)

    References

    CostEstimate

    • 10 weeks

    Contact

    • Armin

    Redesign of chart wizard UI

    CostEstimate: 6 weeks

    Contact: Bubli

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

    Unit in numerical inputs

    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

    Fix diacritics rendering defects

    CostEstimate: ?

    Contact: Khaled

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

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

    Automated test tools for finding text rendering defects

    CostEstimate: ?

    Contact: Khaled

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

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

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

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