Tenders for budget 2024

    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

    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

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

    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.

    Re-allow wrapping around frames in header/footer (tdf#143793)

    CostEstimate: 2.5 weeks

    Contact: Justin Luth

    In order to be compatible with Microsoft, wrapping around shapes in headers and footers was simply ignored - including for ODT. However, since 2013, Microsoft document now allow wrapping. LibreOffice should stop ignoring that wrapping, which will result in being more in-line with user expectations, documentation specifications, and interoperability with modern MSO documents.

    The biggest aspect of this work will be to fix the inevitable layout fallout.


    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.

    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

    Transition to ODF 1.4

    I hope version 1.4 of the ODF standard is published so early, that it is possible to put the necessary transitions into the 2024 budget. If not, this section can be moved to 2025 budget. Regina (talk) 12:54, 18 July 2023 (UTC)

    In case you have experience in an area please review and correct the tasks lists. Regina (talk) 13:40, 28 July 2023 (UTC)

    Basic transition tasks

    These might be done outside tenders or might be merged to the proposal "Transition of already implemented features to ODF 1.4" below.

    CostEstimate: 2 weeks

    Contact: Regina

    • Add the ODF 1.4 schema files to schema directory
    • Create the OpenDocument-v1.4+libreoffice files
    • Adapt enum ODFSaneDefaultVersion
    • Adapt Load/Save in Options dialog and add the associated code
    • Adapt SvXMLExport::GetODFVersionAttributeValue()
    • Adapt the ODF validator to handle ODF 1.4
    • Check MSO interoperability
    • More to do?

    The current (2024-07-24) state of ODF 1.4 is in https://github.com/oasis-tcs/odf-tc/tree/master/docs/odf1.4

    The transition from ODF 1.2. to ODF 1.3 was mainly done by Michael Stahl. Look into the history of files in e.g. /core/schema/ and file /core/include/unotools/saveopt.hxx or search for 'ODF 1.3' in the commit messages to find relevant commits. For example: commits 7f3c9da5 or a541cd91

    Transition of already implemented features to ODF 1.4

    CostEstimate: 4 weeks

    Contact: Regina

    The description here assumes that "Basic transition tasks" above are already done.

    • Remove use of table:cell-range-address attribute within the <chart:plot-area> element. The attribute is already deprecated in ODF 1.3. Bugzilla report is tdf#131862, the corresponding issue in ODF TC bug tracker is oasis#3741.
    • Use new handle attributes in export and import of ODF 1.4 documents.
    oasis#4110 19.179 draw:handle-position has wrong parameter order in case of polar handle-position
    ODF 1.4 replaces the attributes draw:handle-polar and draw:handle-position with the new attributes draw:handle-position-x draw:handle-position-y, draw:handle-polar-pole-x, draw:handle-polar-pole-y, draw:handle-polar-radius, and draw:handle-polar-angle. Task is to write these new attributes in addition to the old attributes. The old attributes are deprecated but may be written, so we keep them for backward compatibility. The import from ODF 1.4 must use the new attributes and ignore the old ones. Only ODF import and export is affected.
    • ODF 1.4 contains features that are already implemented in LibreOffice. Currently, these are stored in "ODF 1.3 extended" file format. The task is to convert them to "ODF 1.4 strict". Such conversion includes:
      • Adapt the ODF export to no longer use private namespaces in case of save to ODF 1.4 but still write private namespaces in case of save to ODF 1.3 extended. Thereby make sure that needed transformations (e.g. in local name or value) are done.
      • Adapt the ODF import to read the private namespace for documents in ODF 1.3 extended and read the namespace specified in ODF 1.4 in documents in ODF 1.4. Thereby make sure needed transformations are done.
      • Modify the relevant export tests and, if necessary, write new ones that check if the namespace specified in ODF is used when saving in ODF version >= 1.4 and the private namespace is used when saving in "ODF 1.3 extended".
      • Modify the relevant import tests and, if necessary, write new ones that check whether documents in ODF 1.4 with namespaces specified in ODF and documents in ODF 1.3 extended with the previous private namespaces result in the same correct internal representation.
    • Check MSO interoperability
    Some hints to related commits can be found in List of LibreOffice ODF Extensions.
    The corresponding issues in ODF TC bug tracker are:
    Issue Number Subject of issue Comments
    oasis#3022 14.1 <office:annotation> currently not usable with <draw:page> e.g. a9ac4f
    oasis#3759 Inability to recognize errors e.g. a8b7c724
    oasis#4105 Additional gutter space for binding e.g. 11e91719
    oasis#4026 Add command arcangleto (G) to draw:enhanced-path e.g. d8720d4e
    oasis#4047 Allow overlap graphic property e.g. a5698f1a
    oasis#4073 Page-content-bottom vertical relation e.g. 65b7873a, ea414f8f
    oasis#4107 19.615.2 <table:filter-condition>: Extend table:data-type attributes to filter by color e.g. e2bdd31c
    oasis#4122 Extend current data type of 19.168 draw:extrusion-specularity e.g. c893c0e3
    oasis#4123 new attribute draw:extrusion-metal-type e.g. 157b027c
    oasis#4132 Marking images/non-text objects as presentational/decorative e.g 31084ebb and 2721520c
    oasis#4030 Bottom to top, left to right writing direction This affects not only use of value bt-lr but tb-rl90 value too. The latter is used for custom-shapes. e.g 8af98ac8, cd2a7acd and c70ee4a6

    Chart axes improvements

    CostEstimate: 5 weeks

    Contact: Regina

    The description here assumes that "Basic transition tasks" above are already done.

    ODF 1.4 introduces the two new attributes chart:major-orgin and chart:minor-logarithmic. These attributes enable more flexible ways to determine major and minor intervals on an axis. The specification how to interpret their values is given in the description of the chart:interval-major and chart:interval-minor-divisor attributes.

    Related ODF TC issue is oasis#3936. Despite its subject “logarithmic scale misses information about basis” it is relevant for non-logarithmic axes too.

    This is a new feature for LibreOffice. Its implementation includes:

    • Adapt the model.
    • Extend the rendering of all affected charts.
    • Implement save and load of ODF 1.4 documents.
    • Transfer affected ODF 1.3 documents to ODF 1.4 on loading.
    • Save to ODF 1.3 without using these new attributes.
    • Adapt the UI. Thereby take care of accessibility.
    • Provide texts for the help, so that the documentation team can easily adapt the help.
    • Provide a guide for users including illustrations that explains the purpose of these attributes. Such can be done in the WIKI.
    • Extend the API so that the new attributes can be used by macros.
    • Add test documents and tests for the new attributes. This might require to extend the special way chart objects are accessed in tests.
    • Adapt the import filter for OOXML to use the new attributes where appropriate.
    • Adapt the export filter to OOXML so that charts look same in MS Office in regard to axis intervals, as far as possible.
    • Adapt the filter for binary MS Office formats.

    Bugzilla contains some issues, which can likely be fixed using the new attributes.

    • Fix these bugs as far as possible.
    • If not possible document in the bug report, why the problem cannot be solved using the new attributes.

    Affected bug reports are:

    Number Subject
    tdf#132480 Lines are not spaced correctly for log scale graphs that don't start at a power of 10
    tdf#62924 Add additional lines into a log scale of charts (minor ticks)
    tdf#119701 Logarithmic axis should have minor ticks
    tdf#113233 Add an attribute with reference value for grid and ticks.
    tdf#139149 EDITING Chart category axis does not have “Interval between labels” setting.

    Additions to Writer page breaks

    CostEstimate: 6 weeks

    Contact: Regina

    The description here assumes that "Basic transition tasks" above are already done.

    Related:
    oasis#3751 Subject: 20.177 fo:break-after / 20.178 fo:break-before
    oasis#2092 Subject: Member Proposal: BreakOddEvenAuto

    This task has three parts.

    Implement includes: Change model, change layout algorithm, adapt API, adapt UI, change and/or create tests, adapt load/save to ODF 1.4 and ODF 1.3, adapt OOXML filter, write a description about the feature to help documentation team to update help and user guides.

    (1) Implement using fo:break-after and fo:break-before at the same time in a <style:paragraph-properties> or in a <style:table-properties> element.

    Bugs tdf#132763 and tdf#141288 are related. Bug tdf#151002 contains some discussion about the UI.
    The solution needs to be extendable to the new break values even-page and odd-page

    (2) Implement using fo:break-after and fo:break-before in <style:table-row-properties>. Such page break is not yet implemented in LibreOffice although the attributes already exist in ODF 1.2. Only the use of both in the same style is new in ODF 1.4.

    Bug tdf#57725 Subject: FILEOPEN: Forcing page break in middle of table is not possible (causes interoperability problems with DOCX)
    Bug tdf#108233 Subject: ODF spec allows a table row to have the formatting property "Page break before", but not implemented in LO
    The solution needs to be extendable to the new break values even-page and odd-page

    (3) Implement the new break values even-page> and odd-page for the attributes <fo:break-before> and <fo:break-after> for the cases <style:paragraph-properties>, <style:table-properties> and <style:table-row-properties>.

    Neither of the three parts includes implementing a page break in <style:table-column-properties>.

    All three parts are restricted to Writer.

    Attribute style:first-page-number for Draw/Impress

    CostEstimate: 4 weeks

    Contact: Regina

    The description here assumes that "Basic transition tasks" above are already done.

    This proposal is related to:

    oasis#3953 Subject: Allow presentation to start with slide number 0

    tdf#115611 FORMATTING: more flexible page numbering method for presentation

    The style:first-page-number attribute exists since ODF 1.1. ODF 1.4 aligns the schema to the description, so that now negative values and zero are allowed in the schema too. Caution, the data type has in addition to integer the keyword continue. That value might be desired if the presentation contains links to slides of another presentation. A negative value might be desired if number 1 should be shown on the third physical slide, for example.

    OOXML has for presentations a similar attribute firstSlideNum with data type int. However MS Office restricts it to 0 to 9999 inclusive, see MS-OI29500 Part 1 Section 19.2.1.26.

    The attribute style:first-page-number is currently not implemented for Draw and Impress, but only for Calc. Implementing it for Draw/Impress increases interoperability with MS Office.

    The task "Implement style:first-page-number for Draw and Impress" includes the following subtasks:

    • Adapt model. Thereby allow integer values and keyword or special, unlikely integer value for continue. The style:first-page-number attribute is usable with the <style:page-layout-properties> element, which is child element of <style:default-page-layout> and <style:page-layout> elements.
    • Extend the API. The existing API property FirstPageNumber is not suitable, because value 0 has the special meaning continue in that property.
    • Adapt editing of page number fields and rendering of page numbers in edit mode and presentation mode. Consider the case, that slides are linked from other presentations.
    • Save and load presentations in ODF 1.4 format.
    • Use the style:first-page-number attribute on import from OOXML to reflect its firstSlideNum attribute. That is an attribute of the presentation root element of the presentation.xml file. Implement export to OOXML format as far as the restricted features of the firstSlideNum attribute in MS Office allows it.
    • Extend the UI by the style:first-page-number attribute.
    • Provide test presentations and unit tests for save/load ODF 1.4 presentations and for OOXML filters.
    • Adapt SVG, PDF, and XHTML export if needed.
    • Adapt the binary export filter if needed to produce valid ppt-files.
    • Deliver a description text about the new feature, suitable to help the documentation team. That can be done in the release notes or as separate file.

    Adaption of Calc to ODF 1.4

    CostEstimate: 3 weeks

    Contact: Regina

    The description here assumes that "Basic transition tasks" above are already done.

    • Implement unit SI_at"
    Related:
    oasis#3851 Public Comment: About OpenDocument Format and units "at"/"atm"
    Bug tdf#72174 convert_add() from "at" and "atm" to "Pa" gives the same answer.
    Tasks:
    Extend the CONVERT function to support the new unit SI_at.
    Add unit tests for load and save of the new unit with ODF 1.4 using direct values and references.
    Change the WIKI page Documentation/Calc_Functions/CONVERT so that it contains the new unit and the deprecation of the unit at.
    Change the help so that it contains the new unit.
    • Adapt EASTERSUNDAY function
    Related:
    oasis#2164 Add EASTERSUNDAY function
    Bug tdf#162177
    Tasks:
    The import needs to be changed to accept of:=EASTERSUNDAY in addition to of:=ORG.OPENOFFICE:EASTERSUNDAY. That change should be done to all active LibreOffice versions and master.
    The export has to be changed to write of:=EASTERSUNDAY in case of save to ODF 1.4. That has to be done on master.
    Include unit tests for import and export.

    Non-graphic background fill

    CostEstimate: 4 weeks

    Contact: Regina

    The description here assumes that "Basic transition tasks" above are already done.

    ODF 1.4 allows complex background fills like hatch or gradient on non-graphic objects. Some of the new possible formatting is already implemented and now needs a transition to ODF 1.4. Those are included here.

    • Fix tdf#103602 new documents fail ODF validation with Error: unexpected attribute "draw:fill" for page styles in Writer documents.
    The attributes related to page fill are erroneously put as attribute into <style:page-layout-properties> element. In case of Writer documents they have to be in the <style:drawing-page-properties> child element of the <style:style> element that is referenced in the draw:style-name attribute in the <style:master-page> element. That has been already implemented with transition from ODF 1.2 to ODF 1.3, but the erroneous place has not been removed.
    The task includes
    the fix itself for save/load for ODF 1.4 on master
    save/load unit tests for ODF 1.4 on master
    Backport fix to those active LibreOffice versions, which do not support ODF 1.4 but only ODF 1.3, likely LO 7.6 and LO 24.2
    unit test for save for ODF 1.3 on 7.6 and 24.2 branch
    • Fix tdf#103602 new documents fail ODF validation with Error: unexpected attribute "draw:fill" for header and footer in Writer documents.
    The attributes related to background fill are erroneously written without loext: prefix as attributes of the <style:header-footer-properties> child element of the header or footer style. With ODF 1.4 they have to be written as <style:background-fill> child element. Issue oasis#4125 is related.
    The task includes
    the fix itself for save/load for ODF 1.4 on master
    save/load unit tests for ODF 1.4 on master
    Make active LibreOffice versions, which do not support ODF 1.4 but only ODF 1.3, able to read the <style:background-fill> child element of a ODF 1.4 document so that we get some backward compatibility.
    unit tests for load of ODF 1.4 documents on LibreOffice 7.6 (and LibreOffice 24.2, if any) branch.
    • Transition of complex fill (e.g. gradient) from private namespace to ODF 1.4 for paragraphs in Writer documents.
    Complex fill is already implemented for paragraphs in Writer. Currently the information is written as <loext:graphic-properties> child element of the paragraph style. In ODF 1.4 it has to be a <style:background-fill> child element in the <style:paragraph-properties> child element of the paragraph style.
    Documents in ODF 1.3 and older need to be still loaded correctly. For backward compatibility to active LibreOffice versions without ODF 1.4 support the <loext:graphic-properties> has to be written in addition. If both are present, the <style:background-fill> child element has precedence.
    The task includes save/load for ODF 1.4 and ODF 1.3 with appropriate unit tests.

    Improve list numbering

    CostEstimate: 5 weeks

    Contact: Regina

    The description here assumes that "Basic transition tasks" above are already done.

    ODF 1.4 provides two changes for list numbering
    oasis#4118 Allow zero as value of text:start-value in <text:outline-level-style> and <text:list-level-style-number> in 19.874
    oasis#4108 new attribute for list level format string

    Because they affect the same places in the code, they should be treated together. They are only separated here to get a better overview.
    In many places the term 'list' is used. That includes chapter numbering, because from point of ODF that is only a default list for headings.

    TODO: The current description considers only Writer, but the ODF changes apply to lists in Draw/Impress too. I have not yet investigated the situation in Draw/Impress in LibreOffice. Regina (talk) 18:20, 6 August 2023 (UTC)

    • Allow zero as value
    MS Office allows zero as start value. This can now be represented in ODF 1.4. Even negative start values are now allowed. The LibreOffice API has this as attribute StartWith with data type short in css.style.NumberingLevel service. Although non-positive vales are now allowed, the default start value is still 1.
    The task includes
    Adapt the model to allow non-positive list start values.
    Adapt the UI to allow non-positive list start values.
    Adapt the DOCX filter to proper handle zero as start value. Add unit tests for this.
    Adapt the ODF filter to handle non-positive list start values. Add unit tests for this.
    Make sure that PDF, RTF, and binary MS Office filter produce valid results, when a list starts with a non-positive number.
    Make sure that HTML and XHTML export filter produce valid results, when a list starts with a non-positive number. Add unit tests for case XHTML.
    Make sure references in ToC, indexes and bookmarks still work, at least with zero as start value. Make sure the list creating with AutoCorrect works with non-positive start value too.
    Fix tdf#154864 Changing starting number of numbered list does nothing
    Update tdf#98520. Update tdf#108536, investigate why the value -1 is written and implement a different solution for that reason if needed.
    Inform about the feature in the release notes.
    • custom format string
    MS Office allows complex, user defined format strings. Similar format strings are now possible in ODF 1.4 too. LibreOffice can already use such format strings, but the implementation is incomplete. It is written as attribute loext:num-list-format for ODF 1.3 extended. The LibreOffice API has this as attribute ListFormat with data type string in css.style.NumberingLevel service. Notice: A placeholder for the number is written as e.g. %1% in the format string in LibreOffice. Wherea in ODF 1.4 the placeholder is written as element <number:num-list-label text:level="1"/>, for example.
    The task includes
    Fix tdf#156598 Custom list numbering from DOCX import is not available in UI. Discuss your design proposal with the UX team. Take care of accessibility.
    Provide propsals for help and user guide for the changed dialog. The proposal can be attached to tdf#156598. Add an information about the changed dialog in the release notes.
    Adapt the ODF import and export filter. Thereby make sure that save to ODF 1.3 extended still writes the loext: prefix. Add unit tests for this.
    Fix tdf#156105 Percents behave wrong in list level prefix/suffix
    Fix tdf#149258 FILESAVE DOCX Dots appear IN MS WORD for custom numbering
    Update tdf#67986 EDITING: FORMATTING: Choose characters of each SEPARATOR between numbers in Outline Numbering. Update too the bugreports listed as duplicate or 'see also'.
    Fix tdf#156239 Entry for loext:num-list-format it missing in List of LibreOffice ODF Extensions.

    Improve paragraph tab stops

    CostEstimate: 4 weeks

    Contact: Regina

    The description here assumes that "Basic transition tasks" above are already done.

    LibreOffice uses the setting TabsRelativeToIndent to distinguish between the behavior of MS Word and the from OpenOffice inherited behavior. In ODF 1.4, an attribute text:relative-tap-stop-position of the default paragraph style can be used instead.

    oasis#3846 Subject: Use @text:relative-tab-stop-position as well for style:tabs-stops instead of using settings.xml flag

    Related bug reports are
    tdf#82234 EDITING: Indent size shouldn't effect the tab stop position values
    tdf#76005 UI missing to set document properties: "TabsRelativeToIndent", "TabOverMargin"

    Tasks:

    Adapt the model if needed.
    Change the import of ODF 1.4 documents to use the new attribute instead TabsRelativeToIndent setting. Adapt the import of the TabsRelativeToIndent setting for documents from earlier versions of the standard if needed.
    Change the export to write the new attribute and for backward compatibility the TabsRelativeToIndent setting in case of ODF 1.4.
    Add unit tests for import and export.
    The intended behavior is described in the ODF 1.4 standard. Make sure that LibreOffice uses it as specified. Make sure it works as specified in right-to-left writing mode too. Add a unit test with RTL.
    Implement a UI for the new attribute. Discuss a design proposal with the UX team. The setting is global for the document, so a paragraph style dialog might not be a correct location.

    I think, when working in this area an additional problem should be fixed at the same time although not ODF 1.4 related. That is bug
    tdf#125804 PARAGRAPH BORDERS: Incorrect alignment in paragraph with first line indented
    This includes fixing the bug itself and adding unit tests with LTR and RTL documents as well. Regina (talk) 21:44, 7 August 2023 (UTC)

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