Tenders for budget 2025
TDF LibreOffice Document Liberation Project Community Blogs Weblate Nextcloud Redmine Ask LibreOffice Donate
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)
Uncategorized
Reconstitute document structure when opening a PDF
Cost Estimate: 26 week
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.
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
Decouple 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
- tdf#152661 Allow to assign Layouts to Master Slides, effectively creating a new "Master Slide+Layout combination" for presentations in Impress
- tdf#78156 Make slide Layouts editable; allow to create custom slide Layouts]
- OASIS#OFFICE-4127: Make slide Layouts editable; allow to create custom slide Layouts