Jump to content

Tenders for budget 2025

From The Document Foundation Wiki


Below are proposal for tenders for the Technical Budgeting Procedure described in TDF's Procurement Policy.

See what was on a similar page in 2024.

Current Status and requirements

The process is still in preparation.

The next step will be the "Open to everyone" phase as described on page 6 of the Procurement Policy:

All interested parties, including Conflicted Members can contribute by entering proposals in the list of potential activities, currently at https://wiki.documentfoundation.org/Development/Budget2025. In order to do so, the interested party should describe the requested item in sufficient detail. That means, a person skilled in the art should be able to understand what needs to be done, and how the end result should look like. A good description for a large project will usually be around one page of text, or it will reference bugzilla issues with a similar level of detail. This includes a rough estimate of the effort in person/time. The cost estimate does not necessarily have to be added by the proponent, who is invited to provide their own. Anyone with relevant technical skills can make a cost estimate, lest good proposals are excluded due to the lack of an upfront estimate. A sufficiently described proposal, is considered to be “admitted to the evaluation”. Insufficiently described proposals, however, will not be taken into consideration. Putting forward a proposal is not considered creating a COI.

Proposal Template

=== My idea ===

'''Contact: John Doe'''
'''Cost Estimate: 1 week (Jane Doe)'''
'''Cost Estimate: 2 weeks (Somebody Else)''' [can have multiple cost estimates, but at least 1 is required]

Description of the proposal

Proposals

(EyalRozenberg (talk) says: the 2024 proposals should be carried over from the 2024 budget/tender proposals page - but avoid overwiring options already present here)

QA and testing

Implement an ODF document anonymizer

Cost Estimate: 2 weeks MVP, up to 10 weeks for more features

Contact: Eyal Rozenberg + ???

Reviewers: ???

Users encountering a problem when working with LO often encounter a tall hurdle preventing them from filing a bug on Bugzilla: The problem occurs in a certain document, with certain content. If they're experienced and diligent they may be able to reproduce from scratch; or whittle down the document while maintaining the bug - but even for seasoned QA contributors this is not always possible. They could upload their document - but that, in fact, is rarely possible, since documents people work on are very often sensitive, restricted or copyrighted, and can't just be freely uploaded.

In this LibOCon 2022 talk, it was proposed to address this using a mechanism or utility for anonymizing documents: Replacing text with gibberish with about the same characteristics - overall and word-level length.

Further anonymization actions would be:

  • Scrubbing personally-identifying meta-data,
  • Support for different language groups
  • Support for different languages within a single group
  • Including within the same paragraph
  • Generic text, or gibberish?
  • Care for maintaining effects due to choice of characters
  • Inter-character effects: Direction control, Combining glyphs...
  • Not being too exact in word lengths - better anonymiziation
  • Replacing vector and raster graphics with generated graphics, either simply of the same dimensions, or geometrically similar
  • etc.

Notes:

  • This can, and perhaps, should, be implemented _outside_ of the LibreOffice codebase, using a library to read an ODF, make anonymizing 'passes' over it, then finally save it as another ODF. The programming language could be anything in which ODF reading is possible.
  • A future direction is integrating this somehow with the bug filing web forms - either as a suggestion to the filing user or as something which may be run before upload, or on the server side. But it is probably best to keep this tender to just the stand-alone utility for now.
  • Such functionality can also, in principle, be added to LO itself, directly or via an extension (e.g. adding a new "Save As" filter) - but that is probably not as useful as the separate utility.

Uncategorized

Implement most missing style categorizes in Draw/Impress

Formatting in ODF documents all goes through styles (even direct formatting is actually implemented as an extra unnamed style applied to the directly-formatted content); and in Writer, we have multiple style categories covering most of the kinds of contents we style: Characters, Paragraphs, Frame, Pages, Lists. In Impress/Draw, however, despite the apparently-reasonable ODF support, we only have almosty none of those accessible from the UI.

Let us, therefore, fimally add the missing UI for the three "easier" style categories, to Impress and draw. Work on these modules is of particular significance, seeing how Writer typically gets more attention and is much more polished.

This proposition does not include the design & implementation of proper table styles (and related styles for columns, rows, headers etc.), as though do not exist and aren't specified at the ODF level, are not available in Writer or any other modules, and would likely require a much more lengthy process.

Cost Estimate: 12 week

The cost estimated should be considered an extreme rough estimate, not being based on knowledgability in the relevant parts of the codebase.

Contact: Eyal Rozenberg + (Heiko Tieze?)

Reviewers: ???

Relevant LibreOffice Bugs:

  • tdf#152652 Meta-bug tracking missing Impress/Draw style categories
  • tdf#128810 Implement Character Styles in Impress/Draw
  • tdf#152653 Implement Paragraph Styles in Impress/Draw
  • tdf#152654 Implement Paragraph List Styles in Impress/Draw

Reconstitute document structure when opening a PDF

Cost Estimate: 26 weeks

Contact: Eyal Rozenberg + (Noel Grandin? Mike Kaganski?)

Reviewers: ???

LibreOffice is relatively popular as a PDF editor of sorts - despite not being very capable at the task, nor being designed with it in mind. This has been the subject of a 2023 LibOCon talk (slides). A fundamental challenge for such editing work is the fact that PDFs are not intended to represent the kind of structure which is essential for document editing: Instead of logical sequences of text with some hierarchical partitions we have multiple disparate frames/rectangles/boxes are; instead of styles, we have large numbers of entites sharing the same raw formatting, accidentally or intentionally; and so on.

In this project, the PDF import filter will be enhanced, to apply some heuristics for inferring such structure within a PDF document (hopefully, reconstituting structure which had existed originally). Structural elements to be consistuted (not an absolutely final list):

  • Intra-line: Hyperlinks (also across lines), superscript and subscript (and more generally, raised/lowerd text)
  • Line-level: full lines (yes, we don't actually have that...), line breaks
  • Paragraph-level: Paragraphs transitions, hierarchy of headings/titles, ordered and unordered lists, alignment, indentation, lists (numbered & bulleted, including multi-level), inter-paragraph and intra-paragraph vertical spacing, tabs and their direction, Text direction (RTL/LTR)
  • Other: The main body of content vs content in frames/shapes, document area within the page, page margin sizes, Comments, footnotes, endnotes, Page styles, tables (including multi-page), special tables like an ToC or Index, writing mode (i.e. tblr, lrtb, rltb and such).

The heuristics chosen must be documented and their rationale described. While UI work to expose this functionality is not itself necessary, the implementation should rely on preferences (which the user can set generaically via Tools > Options > LibreOffice > Advanced > Expert Configuration , even with no UI work done) for configuration of what to reconstruct and various more specific settings (e.g. tolerance thresholds).

There will likely be case where multiple possible documents, or fragments of documents, could have resulted in the same rendered fragment or set of entitites in a PDF. In these cases as well, a reasonable heuristic for making a choice among these is to be developed.

Finally, structural elements need names, which hopefully reflected their roles. Choosing names of elements and styles, rather than generic "paragraph_style_64", "list_style_12" should be attempted.

The resulting enhanced PDF input filter should be robust enough so that, when one opens a PDF originally exported from a straightforward document edited in one of the popular office suites, the reconstructed document will allow for relative hassle-free continued editing. e.g. ODT -> PDF -> ODT should not be overly garbled.


Some relevant LibreOffice bugs:

  • tdf#113123 [META] PDF import filter in Writer
  • tdf#99746 [META] PDF import filter in Draw
  • tdf#151598 Implement "Consolidate Text" functionality for text boxes in Writer
  • tdf#152627 PDF with hyperlinks: links are lost with import to Draw

Relevant external software:

  • pdf2docx Python library for (re)constructing DOCX from PDF files

Notes:

  • The focus of this project would be on Writer rather than Draw/Impress, as its documents stand to benefit more. However but all features detected in the Writer import filter, which are applicable to Draw/Impress must (should?) also be detected when opening Draw/Impress documents, i.e. must also be implemented in the Impress/Draw filter. There are structural features which are specific to Impress, and might be detected, but they are not a requirement for this project, such as: Master slides, their contents and which slides derive from them; animations; the handouts format; etc.
  • One of the challenges is the potential of being thrown-off by possible misplacement, due to font issues. Example: tdf#152679 consider the screenshot; if one doesn't examine the PDF's internal structure, one may misplace the right edges of the boxes so that they do not align with each other even one might fail to realize there are three identical columns.
  • Many of the bugs against the PDF import filter in Draw are, in fact, common to both existing import filters.
  • Consider a "breadth-first scan" from the least-complex features we currently support to the most-complex feature of a complete document:i.e. starting with paragraphs and paragraph-level features, generalizing character styles and paragraph styles, then proceeding to structures such as lists, tables, columns, frames, then page-level features like headers and footers along with sections etc.
  • Beyond a simple and straightforwd heuristic, identifying structure in a rendered document is, rephrarsed, the problem of identifying a function in a certain family, given its evaluation over a certain domain - a kind of machine-learning problem. This more methodical/generalized approach to the problem is not in the scope of this project per se, although it is possible that it might lean in this direction at some point.
  • There is existing software for converting PDF files into HTML or DOCX files. Code from such libraries may be used or ported conditioned upon license compatibility. In fact, a survey of existing work may well be the appropriate beginning for this work. Libraries as pre-built artifacts rather than filter code improvemen nts are probably off the table, unless a convincing counter-argument is made.
  • The work should not assume PDF contents is English, nor a western language; nor that text layout on a page is top-to-bottom, left-to-right; nor assume a certain uniform direction of text within paragraphs. If this presents any obstacles, consultation should decide how to proceed (e.g. workround or refocus on getting past these difficulties at the cost of achieving less).
  • It is recommend to get some initial "inspiration" from how the PDF output/export filters in LibreOffice breaks down document structure when rendering PDFs.
  • There may be a need to fix tdf#143095 (Draw and Writer PDF filter import misinterpret font family names) before this project is undertaken - as otherwise, it is difficult/impossible to determine where a text run ends, visually, on the basis of which one would need to decide things like alignment, line breaking, association with a frame/box/table etc.
  • The cost estimate is a very wild guess.

Correctly determine font family names in PDFs

Some font families have names with spaces, e.g. "Liberation Serif" or "Myriad Pro". Our current When we read PDF files, such font families are typically constituted with the spaces removed, e.g. "LiberationSerif" or "MyriadPro" - thus not rendered with the correct font.

For this project, the PDF import filters (themselves, or any library they may be using) must be made to obtain the correct font family and variant names for PDF elements/nodes with text. As this is possible for PDF viewers - which determine it well enough to locate the appropriate system font for rendering the document - it is obviously possible in LibreOffice as well. It may, however, require unpacking/decoding/parsing more content from the PDF file than we currently do.

When obtaining proper font family and variant names, the is another sub-issue to consider: Currently, LibreOffice itself does not use font family names proper, but rather also appends some of the variant information from the font, e.g. "Foo" might be replaced with a number of font 'families' named "Foo Light", "Foo", "Foo SemiBold", "Foo Bold", "Foo Black", or even worse - each of these may also have any of the condensation attribute values appended, e.g. "Foo SemiBold Cond", "Foo Black Ext", etc. etc. PDF files will likely not expose such variant names as family names, so extra adaptation/mapping work may be necessary.

Cost Estimate: 3 week

It may be the case that the cost is much lower for someone well-versed with the PDF format - but also perhaps significantly higher for someone who knows LO but not PDF intricacies, or vice-versa.

Contact: Eyal Rozenberg + (Noel Grandin? Mike Kaganski?)

Reviewers: ???

Relevant LibreOffice Bugs:

  • tdf#143095 Draw and Writer PDF filter import misinterpret font family names
  • tdf#153907 Apply an add-or-remove spaces heuristic when matching font family name
  • (Background regarding LO's splicing of family names with variant names:)
    tdf#35538 Handling of fonts with more than 4 styles (R/B/I/BI) is suboptimal

Reduce size overhead of Hybrid PDFs

CostEstimate: 2 weeks

Contact: Eyal Rozenberg

Reviewers: Tomaz Vajngerl, Eyal Rozenberg

LibreOffice supports exporting "hybrid PDFs", containing both a PDF-rendering of a document, and the document itself as an attachment to that PDF. At the moment, this often means essentially doubling the size of the resulting PDF. In documents taking larger amount of space, most of it is typically taken up by content other than document text or structure: Images and other attachments. This content, in regular LO document, is itself attached to the document's XML within a zip archive, so that in the actual document we have some kind of link. It should not be too difficult to link to content within the Hybrid PDF encapsulating the document, i.e. avoid adding each attachment both into the PDF per se and into the zip archive for the document, attached to the PDF.

Notes:

  • A second, or alternative, contact would be appreciated (as the proponent is not a developer).
  • The cost estimate is rather arbitrary.
  • One would need to use a linking scheme that is either already expressible in ODF, or can be covered by an LO ODF extension.

Relevant LibreOffice Bugs:

  • tdf#152661 "Hybrid PDF" must share embedded (non-font) media between the ODT and the proper PDF
  • tdf#103378 [META] PDF export bugs and enhancements

Blocking Features

Couple master slide and layouts (updated 2025)

CostEstimate: 9 weeks

Contact: Thorsten Behrens

Impress is currently constrained to a very limited set of slide layouts. The user can not create any custom ones; and even worse - the _developers_ can't add some critical idiomatic layout, such as one for presentation-title slides .

The predefined slide layouts are "independent" of the master slides: one can assign a predefined layout to a slide, and each slide has a master slide assigned. But - slide parts will obey their positioning by the Master slide, so it's a faux independence. 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:

  • Set, alter and show the association of layouts to master slides;
  • Filter the applicable layout based on the master slide;
  • (Possibly) Apply a master + layout combination, at once;
  • Create and edit custom layouts.

and to add import-export support for this in the ODF and OOXML filters (and PPT as well?)

Main bugs


Rework Impress slideshow to use DrawingLayer primitives

Note: there's currently a GSoC project ongoing for this rework!

Cost Estimate: 4 weeks

Contact: Thorsten Behrens

This is a copy of the GSOC project ideas page section of the same name, which has not been realized in 6 years.

The Impress slideshow, while being designed to only interact with Impress via interfaces, had to resort to an ugly hack to be able to render all Impress content. That was ok back in the day, but is becoming a liability these days. Nowadays, what one want to use is the DrawingLayer Primitives, which means porting over slideshow/source/engine/shapes/* to use this kind of abstraction, instead of the StarView Metafile previously in use.