The Document Foundation Planet

 

September 05, 2024

Official TDF Blog

LibreOffice 24.2.6 available for download, for the privacy-conscious user

Berlin, 5 September 2024 – LibreOffice 24.2.6, the sixth minor release of the free, volunteer-supported office productivity suite for office environments and individuals, the best choice for privacy-conscious users and digital sovereignty, is available at https://www.libreoffice.org/download for Windows, macOS and Linux.

The release includes over 40 bug and regression fixes over LibreOffice 24.2.5 [1] to improve the stability and robustness of the software, as well as interoperability with legacy and proprietary document formats. LibreOffice 24.2.6 is aimed at mainstream users and enterprise production environments.

LibreOffice is the only office suite with a feature set comparable to the market leader, and offers a range of user interface options to suit all users, from traditional to modern Microsoft Office-style. The UI has been developed to make the most of different screen form factors by optimizing the space available on the desktop to put the maximum number of features just a click or two away.

LibreOffice for Enterprises

For enterprise-class deployments, TDF strongly recommends the LibreOffice Enterprise family of applications from ecosystem partners – for desktop, mobile and cloud – with a range of dedicated value-added features, long term support and other benefits such as SLAs: https://www.libreoffice.org/download/libreoffice-in-business/.

Every line of code developed by ecosystem companies for enterprise customers is shared with the community on the master code repository and contributes to the improvement of the LibreOffice Technology platform.

Availability of LibreOffice 24.2.6

LibreOffice 24.2.6 is available at https://www.libreoffice.org/download/. Minimum requirements for proprietary operating systems are Windows 7 SP1 and macOS 10.15. Products based on LibreOffice Technology for Android and iOS are listed here: https://www.libreoffice.org/download/android-and-ios/.

Next week, power users and technology enthusiasts will be able to download LibreOffice 24.8.1, the first minor release of the recently announced new version with many bug and regression fixes. A summary of the new features of the LibreOffice 24.8 ifamily s available on this blog post: https://blog.documentfoundation.org/blog/2024/08/22/libreoffice-248/.

End users looking for support will be helped by the immediate availability of the LibreOffice 24.8 Getting Started Guide, which is available for download from the following link: https://books.libreoffice.org/. In addition, they will be able to get first-level technical support from volunteers on user mailing lists and the Ask LibreOffice website: https://ask.libreoffice.org.

LibreOffice users, free software advocates and community members can support the Document Foundation by making a donation at https://www.libreoffice.org/donate.

[1] Fixes in RC1: https://wiki.documentfoundation.org/Releases/24.2.6/RC1. Fixes in RC2: https://wiki.documentfoundation.org/Releases/24.2.6/RC2.

by Italo Vignoli at September 05, 2024 11:23 AM

September 03, 2024

Official TDF Blog

New “LibreOffice Expert 2024/2025” magazines available for schools and local communities

LibreOffice Expert magazines

Recently, Linux New Media released an updated version of its “LibreOffice Expert” magazine, which contains tutorials, tips and tricks about the office suite. And some articles were contributed by members of the LibreOffice community! The magazines come with DVDs that include LibreOffice for Linux, Windows and macOS, alongside extra templates, extensions, videos and guidebooks.

We have some copies to give away, for schools, universities and local communities. Ideally, we’d like to get these magazines out to places where internet connections aren’t always available – so that the users can really benefit from the DVDs.

So, if you can help us to distribute these magazines, drop us a line! Please note that we can only send a maximum of five copies to any one place, to make sure many people get a chance. When you contact us, please include this information (any requests without cannot be fulfilled):

  1. What you want to do with the magazines
  2. How many you want
  3. The address to which we should post them

Include that information in an email to us and let’s see what we can do!

(Note: if you want to buy the magazine directly from the publisher, you can do so here.)

by Mike Saunders at September 03, 2024 12:26 PM

Miklos Vajna

Improved interactivity for LOK clients in Writer's layout

Writer now has support for doing partial layout passes when LOK clients have pending events, which sometimes improves interactivity a lot.

This work is primarily for Collabora Online, but the feature is useful for any LOK clients.

Motivation

I recently worked with a document that has relatively simple structure, but it has 300 pages, and most of the content is part of a numbered list. Pasting a simple string (like an URL) into the end of a paragraph resulted in a short, but annoying hang. It turns out we updated Writer's layout for all the 300 pages before the content was repainted on the single visible page. In theory, you could reorder events, so you first calculate the first page, you paint the first page, then you calculate the remaining 299 pages. Is this possible in practice? Let's try!

Results so far

The relevant part of the test document is simple: just an empty numbered paragraph, so we can paste somewhere:

Bugdoc: empty paragraph, part of a numbered list and then pasting an URL there

This is a good sample, because pasting into a numbered list requires invalidating all list items in that list, since possibly the paste operation created a new list item, and then the number portion has to be updated for all items in the rest of the list. So if you paste into a numbered list, you need to re-calculate the entire document if all the document is just a numbered list.

The first problem was that Writer tracks its visible area, but LOK needs two kinds of visible areas. The first kind decides if invalidations are interesting for part of the document area. LOK wants to get all invalidations, so in case we cache some document content in the client that is near the visible area, we need to know when to throw away that cache. On the other hand, we want to still track the actually visible viewport of the client, so we can prioritize visible vs hidden parts of the document. Writer in LOK mode thought that all parts of the document are a priority, but this could improved by taking the client's viewport into account.

The second problem was that even if Writer had two layout passes (first is synchronous, for the visible area; second is async, for the rest of the document), both passes were performed before allowing a LOK client to request tiles for the issued invalidations.

This is now solved by a new registerAnyInputCallback() API, which allows the LOK client to signal if it has pending events (e.g. unprocessed callbacks, tiles to be painted) or it's OK for Writer layout to finish its idle job first.

The end result for pasting a URL into this 300 pages document, when measuring end-to-end (from sending the paste command to getting the first updated tile) is a decrease in response time, from 963 ms to 14 ms.

How is this implemented?

If you would like to know a bit more about how this works, continue reading... :-)

As usual, the high-level problem was addressed by a series of small changes:

The tracking issue for this problem was cool#9735.

Want to start using this?

You can get a development edition of Collabora Online 24.04 and try it out yourself right now: try the development edition. Collabora intends to continue supporting and contributing to LibreOffice, the code is merged so we expect all of this work will be available in TDF's next release too (25.2).

by Miklos Vajna at September 03, 2024 06:08 AM

September 02, 2024

Official TDF Blog

LibreOffice project and community recap: August 2024

LibreOffice project and community recap banner

Here’s our summary of updates, events and activities in the LibreOffice project in the last four weeks – click the links to learn more…

  • The biggest news in August was the release of LibreOffice 24.8. This is our latest major stable branch – and the second to use the “year.month” version number scheme. It has a ton of new features, improvements and fixes, some of which are shown in this short video (PeerTube version here):

Please confirm that you want to play a YouTube video. By accepting, you will be accessing content from YouTube, a service provided by an external third party.

YouTube privacy policy

If you accept this notice, your choice will be saved and the page will refresh.

LibreOffice Conference 2024 banner

  • In other conference news, we announced that the Luxembourg Media & Digital Design Centre is co-organising it. This is an Economic Interest Grouping gathering the Ministry of Education, Children and Youth (MENEJ), and the Ministry of Higher Education and Research (MESR), and the Luxembourg Institute of Science and Technology (LIST), created to support national activities related to digital learning and to operate service and innovation platforms.

 Luxembourg Media & Digital Design Centre logo

  • Next, we spoke to Khushi Gautam who is currently working on fixing bugs in her LibreOffice Outreachy project, “Sidebar Deck for Quick Findâ€�, alongside Google Summer of Code students to make further progress.

Khushi Gautam

LibreOffice in Microsoft Store

  • The Document Foundation (TDF) is the non-profit home of LibreOffice, and its Membership Committee (MC) administers membership applications and renewals following the criteria defined in the Foundation’s Statutes. An election for a new MC is coming up, and in August we ran three live “townhall” Q+A sessions with the candidates. Recordings from two of them are online (PeerTube versions here and here):

Please confirm that you want to play a YouTube video. By accepting, you will be accessing content from YouTube, a service provided by an external third party.

YouTube privacy policy

If you accept this notice, your choice will be saved and the page will refresh.

Please confirm that you want to play a YouTube video. By accepting, you will be accessing content from YouTube, a service provided by an external third party.

YouTube privacy policy

If you accept this notice, your choice will be saved and the page will refresh.

LibreOffice stand at FrOSCon 2024

Gladys David

LibreOffice Getting Started Guide 24.8

 LibreOffice Asia Conference 2024 in Taipei

Keep in touch – follow us on Mastodon, X (formerly Twitter), Bluesky, Reddit and Facebook. Like what we do? Support our community with a donation – or join our community and help to make LibreOffice even better!

by Mike Saunders at September 02, 2024 08:33 AM

August 28, 2024

Official TDF Blog

TDF Membership Committee election 2024 – Second live Q+A session

As announced earlier in the month, we’re running live “Q+A” sessions for candidates in The Document Foundation’s upcoming Membership Committee election. Here’s a recording from the second session (PeerTube version here):

Please confirm that you want to play a YouTube video. By accepting, you will be accessing content from YouTube, a service provided by an external third party.

YouTube privacy policy

If you accept this notice, your choice will be saved and the page will refresh.

by Mike Saunders at August 28, 2024 10:19 AM

August 27, 2024

Official TDF Blog

LibreOffice Asia Conference 2024 in Taipei – Government Migration and Community Experiences Sharing

LibreOffice Asia Conference 2024 in Taipei – Government Migration and Community Experiences Sharing

Our Taiwanese community reports back from a recent event:

The LibreOffice Asia Conference 2024 was held in Taipei from 2 – 3 August. This conference was suspended for several years due to the pandemic and was relaunched in Indonesia last year.

In addition to the local community, there were many partners from the Japanese and Indonesian communities, as well as experts from Germany and Italy, representing The Documentation Foundation and the Open Document Format Technical Committee, who attended this conference.

The main visual design of the conference was developed by students at the Open Design Club in National Chengchi University. They boldly adopted the theme of “rice” since that’s a common staple food in Asian countries, and created a series of exquisite logos, icons and merchandise.

LibreOffice Asia Conference 2024 in Taipei – Government Migration and Community Experiences Sharing
Staff in Government Day and the main poster

There were two main topics in this conference: Government Day and Community Day.

Government Day

The first day, “Government Day”, focused on Open Document Format (ODF) policy and “Public Money, Public Code” (PMPC). Six scholars and experts along with LibreOffice community members were invited to give talks, which covered topics from policy theory to practical practices when adopting ODF and PMPC in government. The audience was mostly made up of users from central and local government units.

The first speaker was Lothar Becker, co-chairman of TDF’s Certification Committee and also a board member of Open Source Business Alliance in Germany. This talk summarized lessons learned from 25 years of migration experiences to LibreOffice Technology in governmental organizations, from famous ones like the “LiMux” project in Munich, to up-to-date migration projects for 30,000 PCs in the government of the German state Schleswig-Holstein.

The second speaker was Prof. Naiyi Hsiao, the chair of Department of Public Administration, National Chengchi University. This session explored what and why the PMPC practice has encountered legal and administrative concerns among the diverse stakeholders.

The third speaker was Director Cheng Ming Wang, the general director of Department of Digital Service, Ministry of Digital Affairs, which is responsible for the ODF policy in Taiwan. His talk introduced three aspects of Taiwan’s ODF promotion: why Taiwan promotes ODF; the process and current status of ODF promotionl and the next steps.

The fourth speaker was Svante Schubert, co-chairman and co-editor of the ODF Technical Committee. His talk briefly gave an introduction to ODF and provided an update. In addition, he explained how the TDF-hosted ODF Toolkit is facilitating daily ODF usage (like for automated document translation).

The fifth speaker was Italo Vignoli, Board of Directors member of The Document Foundation. His talk discussed the role of open source software and open standards in digital sovereignty. Today, user-created content – and the ability to share it transparently – is in the hands of a few companies that take advantage of users’ limited digital culture. This situation can only be overcome by moving from proprietary to open source software and from proprietary to open standards.

The last session was from Prof. Tyng-Ruey Chuang, the Associate Research Fellow/Professor of Institute of Information Science in Academia Sinica, Taiwan. In this presentation, he highlighted the important roles of data infrastructure in facilitating the development and sharing of communal digital resources, and related the practice of communal data infrastructure to the Public Money Public Code (PMPC) initiative.

LibreOffice Asia Conference 2024 in Taipei – Government Migration and Community Experiences Sharing
Group photo of Government Day

Community Day

The second day of the conference was dedicated to the LibreOffice community, and was organized as a COSCUP session track. Community members from Taiwan, Indonesia, Germany, Italy, and Japan shared various topics. Italo Vignoli spoke about the history and evolution of LibreOffice and The Document Foundation. Lothar Becker shared several funny and ridiculous stories from his experiences helping different organizations to adopt LibreOffice. Two LibreOffice Certified Profession Trainers from Taiwan, Kai-Ju Tsai and Teresa Hou, demonstrated advanced applications of Writer and Calc. The Indonesian community focused on visual design, sharing their experiences in creating presentation templates, vector graphics and themes for LibreOffice.

Additionally, a member of the team who organized last year’s LibreOffice Asia Conference in Indonesia discussed the challenges and joys of planning international events. The Japanese community shared their difficult experiences in advocating LibreOffice to local governments and private sectors in Japan, resonating deeply with participants from other countries!

LibreOffice Asia Conference 2024 in Taipei – Government Migration and Community Experiences Sharing
Italo Vignoli introduced TDF to the Asian community

LibreOffice Asia Conference 2024 in Taipei – Government Migration and Community Experiences Sharing
LibreOffice Certified Professional Trainer Kai-Ju Tsai demonstrated advanced usage of Writer

LibreOffice Asia Conference 2024 in Taipei – Government Migration and Community Experiences Sharing
Two young Indonesian community members showed how they learned to make designs using open source tools like Inkscape and LibreOffice Draw

Additional Activities

In addition to the two-day main topics, there were also several additional activities.

On 4 August, the Open Design Club of National Chengchi University held a “Design workshop”. In this workshop, students from ODC and Indonesian community members divided into groups, and were challenged to design a movie poster in 30 minutes. Then they shared their experiences and work of designing using open source tools.

LibreOffice Asia Conference 2024 in Taipei – Government Migration and Community Experiences Sharing
Students from Taiwan and Indonesian community members designed a movie poster together

On 5 August, Franklin Weng, the president of Software Liberty Association Taiwan, led a group of ten international community members, including Svante Schubert, Italo Vignoli and Lothar Becker, to visit the Department of Digital Service, Ministry of Digital Affairs, which is responsible for promoting ODF policies.

They were received by General Director Cheng Ming Wang, Senior Analysts Chun-Wei Tsai and Tsung-Yen Wang, and Section Chief of Application Development, Chun-Chieh Chen. The meeting discussed various possibilities for participating in the ODF Technical Committee and collaborating with The Document Foundation’s certification system, as well as exchanging views on future artificial intelligence (AI) trends.

LibreOffice Asia Conference 2024 in Taipei – Government Migration and Community Experiences Sharing
Visit to Department of Digital Service, Ministry of Digital Affairs

During these days, several major Asian community leaders also reached an agreement that next year’s LibreOffice Asia Conference will be held in Japan. We look forward to LibreOffice/ODF/PMPC taking root more deeply in Asia!

by Mike Saunders at August 27, 2024 12:43 PM

August 26, 2024

Roman Kuznetsov

The best LibreOffice extensions. Code Highlighter 2

When I translated one book about Python to Russian which contained many examples of Python code I though quite long how to highlight them in the normal text. For book writing I used LibreOffice Writer (of course) but Writer has no a standard tool for code highlighting.

So after some searching I found the LibreOffice extension - Code Highlighter 2. It is also available on our extension site. This extension makes code highlighting using Pygments Python library. There is support for many programming languages and many color styles for highlighting there.

The extension worked fine, but I didn't like that for highlighting I should manually select every code example in the text, then press some shortcut, then select another code example, etc...

I wrote an issue on the extension github page and after some discussions the extension author Jean-Marc Zambon implemented a new feature that allows to highlight all code example in the book in only one action using Paragraph style!

So my workflow in this case will be as follows:

  • Create a snippet for the AutoText with code example that has a special paragraph style (for example, with font name Consolas and font size 12pt) with name, for example too - 'Python_code'.
  • Use this snippet to insert code examples
  • In the end of book writing just use the new feature in the extension and highlight all code examples in only one action!

 


Above you can see examples of the Code Highlighter work with some light and some dark styles.

by Roman Kuznetsov (noreply@blogger.com) at August 26, 2024 11:18 AM

August 23, 2024

Caolán McNamara

Linux Namespaces and Collabora Online

In Collabora Online (for the normal mode of operation) we have a single server process (coolwsd) that spawns a separate process (kit) to load and manage each individual document. Each of those per-document kit processes runs in its own isolated environment. See architecture for details.

Each environment contains a minimal file system (ideally bind mounted from a template dir for speed, but linked/copied if not possible) that each kit chroots into, limiting its access to that subtree.

That chroot requires the CAP_SYS_CHROOT capability (and the desirable mount requires the CAP_SYS_ADMIN capability), and granting those capabilities to the coolforkit and coolmount binaries is a root privilege that, for typical deb/rpm packages, is done automatically at install time.

But it would be far more convenient not to require these capabilities to be set to do this isolation. They grant online more ability to affect its host system than it uses, we only want to mount dirs and chroot into dirs that belong to online and have no need or desire to make them available to any other process or user, and it's awkward, especially during development. to require root privileges to set these capabilities.

This scenario is not unique, and Linux provides namespaces, typically used by container implementations, to support achieving this. So recent work in Collabora Online leverages these namespaces to do its own layer of per-document kit isolation. (There's a good series of articles by Steve Ovens on the various namespaces, with the mount namespaces the most relevant one here.)

In essence, a user level process can create its own namespace in which it is apparently root from its own perspective, but as the original uid from the outside perspective and limited to operating on resources that the original uid is limited to accessing. So for each forkit, instead of requiring initial system capabilities and creating a system level bind mount we instead have no specific initial capabilities, enter a new namespace, unique to each forkit, in which that forkit becomes king of its own castle with apparent full capabilities, and can create bind mounts and chroot into its minimal file system.

Which is pretty magical to me as the whole existence of namespaces passed me by entirely without notice despite debuting over a decade ago.

Nothing is ever simple however, so some hurdles along the way.

Entering the namespace "requires that the calling process is not threaded" (man 2 unshare) which is not a problem for the normal use case in each kit, but did pose a problem for the test coolwsd does in advance to probe if there are working namespaces on the system in determine if it should operate kits in namespace mode or not. There it turned out that the Poco::Logger we use backups existing logs when it creates a new one, and then by default spawns a  thread to compress the old log.

I initially had the vague notion that I could treat a namespace as a sort pseudo-sudo and switch back and forth freely between them, but that's not the model, typically it's a one way journey. But namespaces can be stacked instead with a namespace where the original uid is mapped to (apparent) root then containing another namespace where the user is mapped back to the original uid again. So we do that, each forkit enters its initial namespace and is mapped to root, does the mounts, enters another nested namespace mapped back to the original uid, chroots and drops all of the capabilities gained on entering a namespace.  Which aligns the namespace mode with the expectations of the non-namespaces mode as to what effective uid the kit appears to run as.

The mounts that each forkit does are private to that forkit, so while in the non-namespace case the mounts are visible system-wide, in the namespace case the mounts are not visible either to other forkits or to the parent coolwsd. So how the document is provided by coolwsd to a child kit had to be adapted for the new mode of even less potential leakage between components.

There was a glitch in mounting, because when we bind mounts dirs from our system template we want them to be readonly, which requires the typical Linux 2 step process of mount and remount with readonly flags. This worked for the non namespace case, but failed for namespaces even though the initial mount succeeded. Here we had an extra flag of MS_NOATIME when remounting to potentially shave a little time off use of the kit jail, but in namespaces removing that option from the underlying system mount isn't permitted.

Despite that mount flag change giving working namespace-using kits directly inside toplevel OS, one of our lxc-using ci systems still refused to allow a readonly remount in a namespace to work. The catch here was that lxc is bundled with default apparmor rules which additionally restrict a readonly remount call to a certain set of arguments which our remount effort didn't match, so that had to be adjusted. Specifically the rather obscure MS_SILENT use.

Performance-wise, an unexpected (to me at least) side effect of using namespaces is that the coolwsd measurement of the time to spawn a forkit on my hardware has reduced from an average of 39.63ms per spawn to an average of an average of 6.15ms per spawn, which wasn't the primary goal but is a nice benefit.

Surveying distros where namespaces are available by default suggests:

RHEL/CENTOS

  • 8.0+ works with namespaces out of the box
  • 7.9 (EOL) not enabled by default, possible with
    • echo 10000 > /proc/sys/user/max_user_namespaces

Debian

  • 11+ (bullseye) works with namespaces out of the box
  • 10 (buster) EOL, not enabled by default, possible with
    • sudo sysctl -w kernel.unprivileged_userns_clone=1

Ubuntu

  • 16.04+ works with namespaces out of the box

Ubuntu 24.04 however, while supporting namespaces out of the box, has restricted namespaces via apparmor rules, which complicates things again so Collabora Online .deb packages install an apparmor profile to enable it to use namespaces out of the box.

by caolan (noreply@blogger.com) at August 23, 2024 11:17 AM

August 21, 2024

LibreOffice QA Blog

QA/Dev Report: July 2024

General Activities

  1. LibreOffice 24.2.5 was released on July, 25
  2. Olivier Hallot (TDF) did many improvements to Calc function help pages and added documentation for wildcards in the Find & Replace help content
  3. Alain Romedenne added a help page for supported MS Office VBA object features and improved the help for IF Basic statement
  4. Pierre F. did many improvements to Calc function help pages and clarified the help text on crash reporter
  5. Dione Maddern reworked the help pages concerning Styles Sidebar deck and added a help page for Page Sidebar deck
  6. Stanislav Horáček updated help for Calc’s XMATCH function
  7. Gábor Kelemen (allotropia) did code cleanups in the area of warnings
  8. Laurent Balland did cleanups in Yellow Idea, Candy, Freshes and Growing Liberty Impress templates
  9. Miklós Vajna (Collabora) continued polishing support for content controls, improved the performance of working with documents having an unusually large number of bulleted lists, disabled export of form fields as PDF forms by default to match user expectations better and improved font fallback in DOCX import
  10. Szymon Kłos, Jaume Pujantell, Attila Szűcs, Michael Meeks, Pranam Lashkari, Marco Cecchetti, Áron Budea and Henry Castro (Collabora) worked on LOKit used by Collabora Online
  11. Tomaž Vajngerl (Collabora) continued refactoring and improving the code for Impress annotations
  12. Julien Nabet fixed crashes and did code cleanups especially in Python code
  13. Xisco Faulí (TDF) fixed an issue with deleting empty columns in Calc removing formatting from adjacent column, fixed a table copying crash, did simplifications in automated tests, added a dozen new tests, converted some tests from Java to Cppunit and upgraded Python to 3.10 alongside other dependency updates
  14. Michael Stahl (allotropia) made document repairing code more robust and made it possible to remove autoformatting from a Writer table while adding a configuration option to disable automatic updates of autoformatting when editing a table
  15. Mike Kaganski (Collabora) fixed rendering issues with GDI and EMF metafiles, made clipboard handling more robust on Windows, made UI tests more stable on Windows, fixed many issues related to database functionality, also making the Firebird integration better, made HTML/ReqIF export more robust and improved the performance of Calc autoformatting when applying to whole rows. He also did many code cleanups and optimisations
  16. Caolán McNamara (Collabora) fixed incorrect font emphasis in Expert Configuration dialog, fixed an issue with a certain type of imported PDF appearing as blank after exporting, improved font fallback automated tests and fixed crashes. He also fixed many issues found by static analysers and fuzzers
  17. Stephan Bergmann (allotropia) worked on WASM build, finishing the UNO bridge for it and enabling Start Center
  18. Noel Grandin (Collabora) greatly improved the export time of complex XLS/X spreadsheets to ODS, made UI tests more stable by making them use a generic clipboard rather than the system one, improved the performance of rendering animated GIFs in Impress and improved the saving time of ODS files with lots of comments
  19. Justin Luth (Collabora) implemented an option to the page number wizard that inserts headers/footers while fitting them into existing margins, fixed a style inheritance refresh issue after changing font sizes, implemented RTF export of different first header, fixed an issue causing headers/footers to be emptied after pasting RTF content into Writer, fixed an issue with images overlapping when separated by line breaks in DOCX files, fixed a content control regression causing extra characters to appear and fixed a visual glitch in content control dropdowns
  20. Michael Weghorn (TDF) made vertical tab dialogs beautiful, implemented accessibility support for the spelling dialog, worked on the Android version and worked on using native widgets in Qt UIs
  21. Balázs Varga (allotropia) worked on the accessibility checker
  22. Patrick Luby fixed an issue with contour wrap clipping semi-transparent pixels, fixed several crashes and hangs, fixed content not being visible in exported WEBP images, made tabbed dialogs accessible on macOS, implemented support for accessing toolbar dropdowns via VoiceOver macOS accessibility software, made it so Command-w shortcut on macOS closes the currently active window and fixed an issue preventing pasting into the search field in Calc, when using a non-Western keyboard
  23. Jim Raykowski added a feature for deleting all content of a certain type via the Navigator and made it so the actions applicable to a selected item show up as buttons in the top part of the Navigator. He also enhanced the Manage Changes dialog by fixing a focus issue, making the changes appear in the order they appear in the document and made it so clicking on a change in the document highlights the related change in the Manage dialog
  24. Sarper Akdemir (allotropia) made the new Impress Notes pane searchable, improved the UX of the encryption dialog by making it modal and added an option to the Save dialog for easy digital signing with default certificate
  25. Samuel Mehrbrodt (allotropia) expanded the coverage of ignored author data when exporting DOC files in privacy mode, made comment author initials handling more robust with PPT/X files, made it so changes in Bullets and Numbering dialog are not saved, if the user cancels, changed the bulleted list toolbar dropdown to display the customised bullet symbol and improved the UX of signing documents with password protected GPG keys
  26. Armin Le Grand (allotropia/Collabora) worked on a renovation of graphics rendering with Cairo library and continued the rework of handling attributes and properties
  27. Oliver Specht (CIB) implemented support for number formats in Writer tables when cloning formatting, fixed an issue with table cell widths in RTF import, fixed an issue with character properties not being applied to bullet symbols in RTF import, made it so paragraphs with empty mail merge fields are not hidden in Microsoft format imports, made the user field display in Edit Fields dialog harmonious, made VML shape visibility property be respected in DOCX import, made the handling of bullets in conditional paragraphs more robust in RTF import and corrected the calculation of paragraph heights in RTF/DOCX import with regards to tab stops and spaces
  28. Heiko Tietze (TDF) added a donate button to Start Center and made shipped palette names translatable
  29. László Németh added some Writer automated tests
  30. Ilmari Lauhakangas (TDF) did many Python code cleanups
  31. Christian Lohmaier (TDF) fixed several build issues
  32. Thorsten Behrens (allotropia) improved the newly-added Impress Notes pane search
  33. Eike Rathke (Red Hat) optimised the use of date & time calculations in the code, fixed an issue with database range keywords not being detected when using English function names in Calc and fixed function wizard breaking formula references to database ranges
  34. Jonathan Clark (TDF) fixed an issue causing Writer textbox direction to change depending on zoom, made line breaking more robust in bidirectional text, fixed inconsistencies in proportional line spacing in Writer, improved the layout performance of Tibetan text in Writer, fixed a Hebrew spell-checking issue related to quotes, made Korean word counting work properly, fixed overlapping CJK characters in PDF export and fixed incorrect baseline adjustment for vertical bidirectional text
  35. Regina Henschel continued working on angle unit import support and corrected the importing of Excel keywords like [#Data] and [#Totals] together with Eike Rathke
  36. Tibor Nagy (allotropia) made connector adjustments work in PPTX import, fixed an accessibility issue with Figure tag placement attribute when exporting to PDF and added support for Windows touch gestures for panning and zooming
  37. Adam Seskunas worked on the GSoC project to port Java tests to C++
  38. Ritobroto Mukherjee worked on the GSoC project to implement cross platform .NET bindings for UNO API
  39. Devansh Varshney worked on the GSoC project for adding histogram charts
  40. Ahmed Hamed worked on the GSoC project for improving the Functions Sidebar deck in Calc
  41. Rafael Lima fixed the rendering of Calc’s AutoFill overlay with certain zoom levels or after scrolling, made the new Calc active cell rectangle symmetric at any zoom level, made Calc’s column/row highlighting repaint when changing window size, gave better contrast for AutoFill handle, improved the look of vertical tabs in dialogs and fixed an issue with the newly-added translatability of palette names
  42. Leonard Sasse did Python code cleanups
  43. Hossein Nourikhah (TDF) did Calc code cleanups, made it so LibreOfficeKit headers and library files are now shipped with the SDK packages and added an ODK example for converting a file to PDF using LibreOfficeKit library
  44. Kira Tubo added a couple of Writer cppunit tests
  45. Stéphane Guillou (TDF) fixed infobar text colours not being adapted to background colour
  46. Moritz Duge (allotropia) added a Python example to ODK for key and mouse handlers and listeners and did several improvements to the UI of certificate handling and digital signing
  47. Peter Hagen optimised macOS clipboard handling code
  48. Bayram Çiçek (Collabora) worked on Excel Power Query round trip support
  49. Taichi Haradaguchi upgraded some dependencies
  50. Jean-Pierre Ledure worked on the ScriptForge library
  51. Jürgen Funk (CIB) fixed an issue with an unwanted empty page appearing in DOCX and RTF files with mirrored margins and made the placeholder text of fields reset to their defaults, if their content is deleted
  52. Vladislav Tarakanov improved the support of audio files in PPT/X files
  53. Vasily Melenchuk (CIB) continued working on the use of Windows attention-grabbing FlashWindow API
  54. Kurt Nordback continued polishing the pie-of-pie and bar-of-pie chart implementations

Kudos to Ilmari Lauhakangas for helping to elaborate this list.

Reported Bugs

430 bugs, 64 of which are enhancements, have been reported by 245 people.

Top 10 Reporters

  1. Eyal Rozenberg ( 25 )
  2. Mike Kaganski ( 12 )
  3. peter josvai ( 12 )
  4. Daniele ( 11 )
  5. Stéphane Guillou (stragu) ( 10 )
  6. Regina Henschel ( 10 )
  7. Gabor Kelemen (allotropia) ( 10 )
  8. Xisco Faulí ( 9 )
  9. Faisal ( 7 )
  10. Telesto ( 7 )

Triaged Bugs

440 bugs have been triaged by 65 people.

Top 10 Triagers

  1. Stéphane Guillou (stragu) ( 95 )
  2. m_a_riosv ( 58 )
  3. Buovjaga ( 54 )
  4. Heiko Tietze ( 29 )
  5. Mike Kaganski ( 23 )
  6. ady ( 17 )
  7. raal ( 16 )
  8. V Stuart Foote ( 15 )
  9. Xisco Faulí ( 14 )
  10. Julien Nabet ( 9 )

Resolution of resolved bugs

403 bugs have been set to RESOLVED.

Check the following sections for more information about bugs resolved as FIXED, WORKSFORME and DUPLICATE.

Fixed Bugs

162 bugs have been fixed by 39 people.

Top 10 Fixers

  1. Mike Kaganski ( 13 )
  2. Jonathan Clark ( 10 )
  3. Patrick Luby ( 10 )
  4. Caolán McNamara ( 9 )
  5. Justin Luth ( 7 )
  6. Heiko Tietze ( 6 )
  7. Miklos Vajna ( 6 )
  8. Michael Weghorn ( 5 )
  9. Balazs Varga ( 5 )
  10. Rafael Lima ( 5 )

List of critical bugs fixed

  1. tdf#161865 Base’s Table Design View and Create View not editable anymore (Windows) ( Thanks to Noel Grandin )

List of high severity bugs fixed

  1. tdf#114160 ZWJ shouldn’t be treated as breaking character ( Thanks to Jonathan Clark )
  2. tdf#148647 LO pastes previous clipboard content instead of latest copied from other app, depending on apps opened (Windows; see comment 11) ( Thanks to Mike Kaganski )
  3. tdf#152104 Long export to ods from xls / xlsx since 7.4.0beta1 ( Thanks to Noel Grandin )
  4. tdf#156530 FIREBIRD: Copying a table from one database file to another gives wrong decimal numbers. ( Thanks to Mike Kaganski )
  5. tdf#156689 Deleting empty column(s) removes styling / formatting of adjacent column ( Thanks to Xisco Fauli )
  6. tdf#160139 Header/footer contents removed and cannot be restored after some paste actions (from shape; as RTF; Zotero refresh…) (steps in comment 2) ( Thanks to Justin Luth )
  7. tdf#160976 FILESAVE RTF Footer content lost after saving from DOCX to RTF ( Thanks to Justin Luth )
  8. tdf#161421 Not all hyphenation separators (hyphens) are displayed in app, but are visible in blue in PDF export / print ( Thanks to Heiko Tietze )
  9. tdf#161568 VIEWING: Message for “no Search Results” sometimes not visible in Toolbar ( Thanks to Heiko Tietze )
  10. tdf#161653 The numbering toolbar dropdown no longer can select from the 8-block of options ( Thanks to Samuel Mehrbrodt )
  11. tdf#162174 Crash when opening Bullets and Numbering dialog a second time ( Thanks to Julien Nabet )
  12. tdf#162180 CRASH: copying table from document, or selecting it with 2

by x1sc0 at August 21, 2024 05:18 PM

August 15, 2024

LibreOffice Dev Blog

Extending the UNO API

Various functionalities of the LibreOffice are available through its programming interface, the UNO API. Here I discuss how to extend it.

What is UNO API?

Many functionalities of the LibreOffice is available through UNO API. You can write extensions and external programs that use LibreOffice functionality without the need to change the LibreOffice core source code.

Extensions work seamlessly with the software, and external applications can connect to the LibreOffice process and use it. The ability to do that depends on the UNO API.

On the other hand, some functionalities may not be available through this API. For example, newer features of the decent versions of LibreOffice, or functionalities that are not useful and/or important for external applications. Sometimes, you may want to use such functionalities elsewhere. Then you have to modify the LibreOffice core source code, and expose those functionalities through the API make them available to the external applications.

Let’s refer to the LibreOffice Developer’s Guide, which is mostly around the LibreOffice UNO API. There, you can read:

“The goal of UNO (Universal Network Objects) is to provide an environment for network objects across programming language and platform boundaries. UNO objects run and communicate everywhere.”

As UNO objects should be usable across different languages and platforms, they are described in an abstract meta language called UNOIDL (UNO interface definition language). This is similar to the IDL definitions in many other technologies like CORBA.

Example UNO API: FullScreen

The API that I discuss here, provides functionality to control full screen functionality for top level windows. Stephan, experienced LibreOffice developer, added that API in this commit:

commit af5c4092052c98853b88cf886adb11b4a1532fff

Expose WorkWindow fullscreen mode via new XTopWindow3

...deriving from the existing XTopWindow2. (Exposing this functionality via UNO
is useful e.g. for some embedded LOWA example application.)

The changes in this commit are over these files:

offapi/UnoApi_offapi.mk
offapi/com/sun/star/awt/XTopWindow3.idl
toolkit/inc/awt/vclxtopwindow.hxx
toolkit/source/awt/vclxtopwindow.cxx

First one, offapi/UnoApi_offapi.mk is needed to introduce the IDL file, according to its module, in a proper location. XTopWindow3.idl is added in com/sun/star/awt, which corresponds to com.sun.star.awt module. The other two, vclxtopwindow.hxx and vclxtopwindow.cxx are the implementation of the API in C++.

Let’s look into XTopWindow3.idl:

module com { module sun { module star { module awt {

/** extends XTopWindow with additional functionality

@since LibreOffice 25.2
*/
interface XTopWindow3: XTopWindow2 {
/** controls whether the window is currently shown full screen */
    [attribute] boolean FullScreen;
};

}; }; }; };

As you may see, it contains these important information:

1. It is an interface, called XTopWindow3.

2.It has a boolean attribute, FullScreen.

3. This functionality will be available in LibreOffice 25.2 and later.

4. This interface extends XTopWindow interface. You may find the documentation for XTopWindow in api.libreoffice.org.

More information about XTopWindow interface can be found in XWindow section of the LibreOffice Developer’s Guide, chapter 2.

C++ Implementation

C++ implementation basically consists of two functions to set and get the FullScreen property:

sal_Bool VCLXTopWindow::getFullScreen() {
    SolarMutexGuard g;
    if (auto const win = VCLXContainer::GetAsDynamic()) {
        return win->IsFullScreenMode();
    }
    return false;
}

void VCLXTopWindow::setFullScreen(sal_Bool value) {
    SolarMutexGuard g;
    if (auto const win = VCLXContainer::GetAsDynamic()) {
        return win->ShowFullScreenMode(value);
    }
}

Final Words

Some APIs are much more complex. The one that was discussed here was only an example to show the required things to extend UNO API. You can browse the API documentation in api.libreoffice.org for more complex APIs:

by Hossein Nourikhah at August 15, 2024 01:59 PM

August 07, 2024

Miklos Vajna

Improved font fallback in the DOCX import of Writer

Writer now has improved support for font fallback when you open a DOCX file that refers to fonts which are not available currently.

This work is primarily for Collabora Online, but the feature is fully available in desktop Writer as well.

Motivation

Font embedding is meant to solve the problems around missing fonts, but you can also find documents with stub embedded fonts that are to be ignored and our code didn't have any sanity check on such fonts, leading to unexpected glyph-level fallbacks. Additionally, once font-level fallback happened, we didn't take the font style (e.g. sans vs serif) into account, which is expected to work when finding a good replacement for the missing font.

Results so far

Here is how to the original rendering looked like:

Bugdoc, before: ugly glyph-level fallback

Once the handler for the embedded fonts in ODT/DOCX was improved to ignore stub fonts where even basic glyphs were not available, the result was a bit more consistent, but still bad. Here is a different document to show the problem:

Bugdoc, first improvement: no glyph fallback but the result is sans

Note how now we used the same font, but the glyphs are always sans, not serif. So the final step was to import the font type from DOCX and consider that while deciding font fallback:

Bugdoc, second improvement: no glyph fallback and the result is sans / serif

With this, we ignore stub embedded fonts from DOCX, we import the font type and in general font fallback on Linux takes the font type into account while deciding font fallback.

How is this implemented?

If you would like to know a bit more about how this works, continue reading... :-)

As usual, the high-level problem was addressed by a series of small changes:

Want to start using this?

You can get a development edition of Collabora Online 24.04 and try it out yourself right now: try the development edition. Collabora intends to continue supporting and contributing to LibreOffice, the code is merged so we expect all of this work will be available in TDF's next release too (24.8).

by Miklos Vajna at August 07, 2024 07:05 AM

August 05, 2024

Michael Meeks

2024-08-05 Monday

  • Mail chew - with newly migrated mail servers; hmm. Amused that an unusual job description from LinkedIn generates more interesting spam:
    "Michael, as the Christian & Hacker at Collabora Ltd you know how hard choosing the right global employment and work payment partner can be."
    presumably some new AI super-brain made the connection.
  • 1:1's with Miklos, Lily, Chris, content review with Richard, catch up with Pedro & Eloy.
  • Enjoyed John Stott's The Message of the Sermon on the Mount in the evening.

August 05, 2024 09:00 PM

August 04, 2024

Michael Meeks

2024-08-04 Sunday

  • Up early; All Saints - played Guitar, H. on Piano; Rick drumming - good, David S's run a family service.
  • Back for a Pizza lunch; slugged and read stories with the babes. Checked tent & packed with N.
  • Out to see James, Kate & Penelope, lovely to catch up with them in the afternoon.

August 04, 2024 09:00 PM

August 03, 2024

Michael Meeks

2024-08-03 Saturday

August 03, 2024 09:00 PM

August 02, 2024

Michael Meeks

2024-08-02 Friday

  • Long partner call, missed Ash' TTT, plugged away at some code, fun.

August 02, 2024 09:00 PM

August 01, 2024

Michael Meeks

2024-08-01 Thursday

  • Technical planning, COOL community, sync with Oli, lunch, catch up with Noel. Helped E. assemble a new flat-pak desk to much excitement.

August 01, 2024 09:00 PM

July 30, 2024

LibreOffice QA Blog

LibreOffice 24.8 RC2 is available for testing

LibreOffice 24.8 will be released as final at the end of August, 2024 ( Check the Release Plan ) being LibreOffice 24.8 Release Candidate 2 (RC2) the forth and last pre-release since the development of version 24.8 started at the beginning of December, 2023. Since the previous release, LibreOffice 24.8 RC1, 138 commits have been submitted to the code repository and 87 issues got fixed. Check the release notes to find the new features included in this version of LibreOffice.

LibreOffice 24.8 RC2 can be downloaded for Linux, macOS and Windows, and it will replace the standard installation.

In case you find any problem in this pre-release, please report it in Bugzilla ( You just need a legit email account in order to create a new account ).

For help, you can contact the QA Team directly in the QA IRC channel or via Matrix.

LibreOffice is a volunteer-driven community project, so please help us to test – we appreciate it!

Happy testing!!

IMPORTANT INFORMATION FOR WINDOWS 7 USERS
Internal python version has been upgraded to python 3.9 which no longer supports Windows 7. Be aware some LibreOffice functionalities written in Python may not work, like the wizards in File – Wizards. Please, do test this version and give us feedback.

Download it now!

by x1sc0 at July 30, 2024 04:34 PM

July 29, 2024

LibreOffice Dev Blog

Fuzz testing to maintain LibreOffice code quality

Here I discuss what fuzz testing is, and how LibreOffice developers use it incrementally to maintain LibreOffice code quality.

Maintaining Code Quality

LibreOffice developers use various different methods and tools to maintain LibreOffice code quality. These are some of them:

1. Code review: Every patch from contributors should pass code review on Gerrit, and after conforming to coding standards and conventions, it can become part of the LibreOffice source code.

2. Static code checking: “Coverity Scan” continuously scans LibreOffice source code to find the possible defects. An automated script reports these issues to the LibreOffice developers mailing list so that developers can fix them.

3. Continuous Testing: There are various C++ unit test and Python UI tests in LibreOffice core source code to make sure that the functionalities of the software remain working during the later changes. They are also helpful for making sure that the fixed regressions do not happen again. These test run continuously for each and every Gerrit submission on CI machines via Jenkins.

4. Crash testing: A good way to make sure that LibreOffice works fine is to batch open and convert a huge set of documents. This task is done regularly, and if some failure occurs developers are informed to fix the issue.

5. Crash reporting: LibreOffice uses crash testing to find out about the recurrent crashes, and fix them.

6. Tinderbox Platforms: Using dedicated machines with various different architectures, LibreOffice developers make sure that LibreOffice source code builds and runs without problem on different platforms. Here is the description of tinderbox (TB) from TDF Wiki:

Tinderbox is a script to run un-attended build on multiple repos, for multiple branches and for gerrit patch review system.

LibreOffice tinderboxes status

LibreOffice tinderboxes status

You can see the build status here:

https://tinderbox.libreoffice.org/

7. Fuzz testing: LibreOffice software is checked continuously using Fuzz testing. This is essentially giving various automated inputs to the program to find the possible places in the code where problem occurs. Then, developers will become aware of the those problematic places in the code, and can fix them.

Fuzz Testing LibreOffice

Fuzz testing on LibreOffice source code is active since 2017, and since then there has been various bug fixes for the problems that the fuzz tester reported. You can see more than 1500 of such fixes in the git log until now:

$ git shortlog -s -n --grep=ofz#

Issues Found with Fuzz Testing

This tool can find various different problems. These issues are then filed in a section of Chromium bug tracker, and after ~30 days, they are made public. When developers fix bugs of this kind, they refer to the issue number (for example 321) as ofz#321. A comprehensive list of all issues found is visible here:

Fixing the Issues

Let’s look at one of the fixes. You can find commits related to fuzzing with:

$ git log --grep=ofz

This is a recent fix from Caolán, an experienced LibreOffice developer that provided most of the fixes found through oss-fuzz:

commit d30ecb5fb07f005ebd944e864f0a15678289a4ed
    ofz#69809 Integer-overflow

--- a/filter/source/graphicfilter/icgm/cgm.cxx
+++ b/filter/source/graphicfilter/icgm/cgm.cxx
@@ -227,7 +227,7 @@ double CGM::ImplGetFloat( RealPrecision eRealPrecision, sal_uInt32 nRealSize )
         else
         {
             sal_Int32* pLong = static_cast<sal_Int32*>(pPtr);
-            nRetValue = static_cast(abs( pLong[ nSwitch ] ));
+            nRetValue = fabs(static_cast(pLong[nSwitch]));
             nRetValue *= 65536;
             nVal = static_cast( pLong[ nSwitch ^ 1 ] );
             nVal >>= 16;

As you can see, using abs() first, and then casting to double is changed in this commit to cast to double first, and then using fabs(). The reason of this change lies in the data type of some variables.

pLong is an array of sal_Int32, which is 32 bit signed integer. It can take values from -2,147,483,648 to 2,147,483,647. As you can see, the smallest negative 32-bit signed integer can not be stored in the same 32-bit signed variable if abs() is used to remove sign from that.

As the result is stored in nRetValue, a varible of type double, it is possible to first cast the array item to double, and then use floating point version of absolute function, fabs() over it. In this way, “integer overflow” will not happen anymore.

This patch was one of the smallest examples of what a fix can be. There are many bugs that are more complex, and require more careful examination to provide a fix.

Further Reading

You can read more in the TDF Wiki article around fuzz testing in LibreOffice. Also, OSS-Fuzz documentation is a good place to look into:

by Hossein Nourikhah at July 29, 2024 12:12 PM

July 25, 2024

LibreOffice Dev Blog

LibreOfficeKit for document conversion

In the previous blog post, I provided a brief introduction to LibreOfficeKit API which one can use for accessing LibreOffice functionalities in an external application. Here I discuss in detail how to use LibreOfficeKit for converting an ODT to PDF, or from/to virtually any other format that LibreOffice supports.

LibreOfficeKit C++ Headers

For this example, you only need one header: LibreOfficeKit/LibreOfficeKit.hxx. Include it, and that is enough. This header will be available in the future versions of LibreOffice community. But for now, you may need to download LibreOfficeKit headers folder from LibreOffice core source code, and put it alongside your source code.

C++ Example

The example is relatively short. Here it is:

#include <iostream>
#include <LibreOfficeKit/LibreOfficeKit.hxx>
int main(int argc, char *argv[])
{
    if(argc < 2)
    {
        std::cout << "Usage: lokconvert  \n";
        return 1;
    }
    const char *input = argv[1];
    const char *output = argv[2];

    lok::Office * llo = NULL;
    try
    {
        const char lo_path[] = LOROOT "/program/";
        llo = lok::lok_cpp_init(lo_path);
        if (!llo) {
            std::cerr << "Error: could not initialize LibreOfficeKit\n";
            return 1;
        }

        lok::Document * lodoc = llo->documentLoad(input, NULL /* options */);
        if (!lodoc) {
            std::cerr << "Error: could not load document: " << llo->getError() << "\n";
            return 1;
        }

        if (!lodoc->saveAs(output, "pdf", NULL /* options */))
        {
            std::cerr << "Error: could not export document: " << llo->getError() << "\n";
            return 1;
        }
    }
    catch (const std::exception & e)
    {
        std::cerr << "Error: LibreOfficeKit exception: " << e.what() << "\n";
        return 1;
    }

    std::cerr << "Success!\n";
    return 0;
}

The example is simple. Input and output file names are passed via command line arguments, and are received via argv[1] and argv[2], if argument count, argc, is at least 3. First one is the program name itself, which we don’t use here.

LibreOffice binary folder is needed here, so you should set OO_SDK_URE_BIN_DIR environment variable, or you may even set that in your program itself.

This part of the code is for LibreOfficeKit initialization:

llo = lok::lok_cpp_init(lo_bin_dir);

And after that, it is the time to load the document:

lok::Document* lodoc = llo->documentLoad(input, NULL /* options */);

Having the lodoc pointer is necessary for converting the document using saveAs function:

lodoc->saveAs(output, "pdf", NULL /* options */)

As you can see, relevant code is inside a try/catch block. In case some exception occur, you will see relevant error information on the console. Also, in each step, from initializing LibreOfficeKit, to loading and in the end generating the output, there are error handling mechanisms to make sure that the work goes forward smoothly.

In the end, if everything is successful, you will see this message on the screen:

Success!

Build with cmake

You can use cmake to build this example. Here is an example CMakeLists.txt which also provides LO_ROOT and LO_SDK_ROOT to be used inside C++ file, as an alternative to setting it via an environment variable, or putting it manually in the code.

cmake_minimum_required(VERSION 3.5)

project(lokconv LANGUAGES CXX)

set(CMAKE_CXX_STANDARD 17)
set(CMAKE_CXX_STANDARD_REQUIRED ON)

add_executable(lokconv main.cpp)

include(GNUInstallDirs)

set(LOVERSION 24.2)

if(WIN32)
    set(LOROOT C:/Progra~1/LibreOffice)
    set(LOSDKROOT ${LOROOT}/sdk)
    add_definitions(-DWIN32)
elseif(APPLE)
    set(LOROOT /Application/LibreOffice.app/Contents/Frameworks)
    set(LOSDKROOT /Application/LibreOffice${LOVERSION}_SDK)
    add_definitions(-DMACOSX)
else()
    set(LOROOT /opt/libreoffice${LOVERSION})
    set(LOSDKROOT ${LOROOT}/sdk)
    add_definitions(-DLINUX)
endif()

add_compile_definitions(LOK_USE_UNSTABLE_API)

target_compile_definitions(lokconv PRIVATE LOROOT="${LOROOT}")

include_directories(lokconv PRIVATE
    ${LOSDKROOT}/include
)

Final Words

There are many nice things that can be done with LibreOfficeKit, but you may have to enable LOK_USE_UNSTABLE_API to be able to use those functionalities. This symbol is visible in the above cmake file. But, in the C++ example I did not use any of such functions. I will discuss about these functionalities in later blog posts.

by Hossein Nourikhah at July 25, 2024 02:04 PM

July 17, 2024

LibreOffice Design Blog

Peer-to-peer collaboration with LibreOffice

A while ago, Simon Phipps, member of the Board of Directors at The Document Foundation, shared the idea to introduce a peer-to-peer collaboration built in to desktop LibreOffice without the requirement for a cloud provider. This idea has received a lot of attention inside the organization and the design team has started to outline the project now.…

by Heiko Tietze at July 17, 2024 08:22 AM

July 16, 2024

LibreOffice QA Blog

LibreOffice 24.8 RC1 is available for testing

LibreOffice 24.8 will be released as final at the end of August, 2024 ( Check the Release Plan ) being LibreOffice 24.8 Release Candidate 1 (RC1) the third pre-release since the development of version 24.8 started at the beginning of December, 2023. Since the previous release, LibreOffice 24.8 Beta1, 243 commits have been submitted to the code repository and 120 issues got fixed. Check the release notes to find the new features included in this version of LibreOffice.

LibreOffice 24.8 RC1 can be downloaded for Linux, macOS and Windows, and it will replace the standard installation.

In case you find any problem in this pre-release, please report it in Bugzilla ( You just need a legit email account in order to create a new account ).

For help, you can contact the QA Team directly in the QA IRC channel or via Matrix.

LibreOffice is a volunteer-driven community project, so please help us to test – we appreciate it!

Happy testing!!

IMPORTANT INFORMATION FOR WINDOWS 7 USERS
Internal python version has been upgraded to python 3.9 which no longer supports Windows 7. Be aware some LibreOffice functionalities written in Python may not work, like the wizards in File – Wizards. Please, do test this version and give us feedback.

Download it now!

by x1sc0 at July 16, 2024 11:37 AM

July 09, 2024

Miklos Vajna

Fixing handling of line object transformations in the DOCX import of Writer

Writer now has improved support for toplevel line shapes when you import those from DOCX.

This work is primarily for Collabora Online, but the feature is fully available in desktop Writer as well.

Motivation

As described in a post from 2014, Writer reads the drawingML markup for shapes in DOCX files, including line shapes. While investigating a simple-looking problem around a horizontal vs vertical line, it turns out that there is a deeper issue here, and it looks like now have proper fix for this bug.

Results so far

Imagine that your company template has a nice footer in two columns, and the content in the columns are separated by a vertical line shape, but when you open your DOCX in Writer, it crosses the text of that footer instead:

Bugdoc, before: reference is red, Writer result is painted on top of it

While researching how line shapes are represented in our document model and how ODT import works, it turned out that the proper way to create a line shape is to only consider size / scaling when it comes to the individual points of the line, everything else (e.g. position / translation) should go to the transform matrix of the shape, then the render result will be as expected:

Bugdoc, after: reference is red, Writer result is painted on top of it

It was also interesting to see that this also improved other, existing test documents, e.g. core.git sw/qa/extras/ooxmlimport/data/line-rotation.docx looked like this before:

3 rotated lines, before: reference is red, Writer result is painted on top of it

And the same fix makes it perfect:

3 rotated lines, after: reference is red, Writer result is painted on top of it

Just stick to the rule: scaling goes to the points -- translation, rotation and horizontal shear goes to the shape.

For now, this is only there for toplevel Writer lines, but in-groupshape and Calc/Impress lines could also follow this technique if there is a practical need.

The "after" screenshots show ~no red, which means there is ~no reference output, where the Writer output would be missing.

How is this implemented?

If you would like to know a bit more about how this works, continue reading... :-)

The bugfix commit was tdf#161779 DOCX import, drawingML: fix handling of translation for lines.

The tracking bug was tdf#161779.

Want to start using this?

You can get a development edition of Collabora Online 24.04 and try it out yourself right now: try the development edition. Collabora intends to continue supporting and contributing to LibreOffice, the code is merged so we expect all of this work will be available in TDF's next release too (24.8).

by Miklos Vajna at July 09, 2024 12:46 PM

July 08, 2024

LibreOffice QA Blog

QA/Dev Report: June 2024

General Activities

  1. LibreOffice 24.2.4.2 was announced on June 6
  2. Olivier Hallot (TDF) added help pages for LET Calc function, improved the help for other new Calc functions, made it so help pages show a link to LibreOffice guide books, updated help pages for Save and Calc View options and updated help pages after UI string changes
  3. Alain Romedenne updated some Basic and Python help pages
  4. Pierre F. updated the help for regular expressions, pointing to ICU Regular Expressions documentation
  5. Dione Maddern updated help for Bullets and Numbering Image tab, Clone Formatting and Insert Table command in Impress
  6. Bogdan Buzea did code cleanups in the area of includes and UI files
  7. Gábor Kelemen (allotropia) fixed an issue with hiding drawing shapes from printing
  8. Laurent Balland did cleanups in Impress Yellow Idea template, replaced built-in binary template for HTML files with an OTH file generated from XML sources and fixed a special Calc number formatting case involving misplaced minus signs
  9. Miklós Vajna (Collabora) continued polishing the implementation of continuous endnotes for Microsoft Word compatibility, added a helper script to diff reference rendering vs. LibreOffice rendering via PDF, fixed a DOCX import glitch involving paragraph borders getting mixed up with table cell borders, fixed lost numbering in paragraph style with DOCX import, fixed a shape text padding issue with DOCX import, made it so pasting rich text from other LibreOffice applications into Writer no longer brings in lots of unnecessary styles, fixed some issues when exporting content controls to PDF forms and fixed handling of line object transformations with DOCX import
  10. Szymon Kłos, Jaume Pujantell, Darshan Upadhyay and Henry Castro (Collabora) worked on LOKit used by Collabora Online
  11. Tomaž Vajngerl (Collabora) continued refactoring and improving the code for Impress annotations, for example expanding the support for types and properties when exporting annotations to PDF and also when importing PDF files
  12. Julien Nabet fixed some crashes and debug assertions
  13. Xisco Faulí (TDF) fixed an issue with paragraph classifications getting deleted after Print Preview or when opening file, made SVG fill handling more robust, upgraded many dependencies and fonts, continued applying SAL_RET_MAYBENULL for enforcing null checking and added over a dozen automated tests
  14. Michael Stahl (allotropia) continued polishing recognition of localised paragraph style names in DOCX files, fixed DOCX file opening crashes, changed Writer tab handling to take some very strange behaviour of Microsoft Word into account and made many improvements to libcmis library (for Content Management Interoperability Services standard)
  15. Mike Kaganski (Collabora) improved loading of broken documents, fixed an issue with Writer text wrapping in very wide pages, made spell check red lining more robust, fixed a Writer layout loop involving tables within tables, improved interoperability of styles with DOCX export, fixed a goal seek macro crash and some other goal seek issues and made it so QuickStarter setting is remembered after upgrade on Windows
  16. Caolán McNamara (Collabora) polished the small caps support in Impress and optimised the code for displaying extended tooltips. He also fixed many issues found by static analysers and fuzzers
  17. Stephan Bergmann (allotropia) worked on WASM build and made form controls safer when dealing with remote linked images
  18. Noel Grandin (Collabora) made documents with lots of tracked changes open faster, continued optimising Calc performance when getting the text script type, continued speeding up the loading of large XLS files, made complex DOCX files with lots of footers or headers open faster, greatly improved the rendering performance of certain types of filled polygons imported from PDF files and improved the performance of EditEngine text. He also did many code cleanups
  19. Justin Luth (Collabora) expanded text wrapping support for shapes in DOCX files, fixed a z-order issue related to VML shapes in DOCX files and made it so small caps are not applied to numbering in Microsoft Office formats
  20. Michael Weghorn (TDF) made qt6 UI backend handle audio-only media objects, fixed OpenGL Impress transitions with Qt-based UI backends and worked on the accessibility features of Windows, GTK4 and Qt UIs in areas such as menu bar focusing, Calc cells and Sidebar buttons
  21. Balázs Varga (allotropia) continued tweaking the XMATCH and XLOOKUP Calc function implementations, added a new LET function to Calc which assigns names to calculation results, improved the display of direct formatting warnings in the accessibility Sidebar deck and added accessibility checks for missing hyperlink names and directly formatted top and bottom margins in paragraphs
  22. Patrick Luby fixed several macOS memory leaks and crashes, fixed a macOS performance issue related to documents with embedded fonts, fixed an issue with colour picker showing the wrong colours when using Skia raster rendering on macOS and fixed an issue with contour text wrapping against images with transparency
  23. Jim Raykowski made many improvements to the newly-added Quick Find Sidebar deck and fixed an issue with Format setting in Find and Replace dialog affecting Quick Find
  24. Sarper Akdemir (allotropia) removed the ability to trust unvalidated macro signatures in high security mode, made Additions dialog show connection errors, improved LanguageTool connection error reporting and continued polishing the new pane display of Presenter Notes in Impress
  25. Samuel Mehrbrodt (allotropia) continued working on vertical tabs for certain dialogs and bulleted/numbered list improvements and made it so author/date data is not exported to documents when in privacy mode
  26. Armin Le Grand (allotropia) worked on advanced diagram support and continued the rework of handling attributes and properties
  27. Oliver Specht (CIB) made it so simple HTML is preferred over RTF when pasting into Draw, fixed an issue with wrong inner margin in mirrored page in DOCX/RTF import and added a warning and a progress indicator to AutoFormat in case of applying to large selections
  28. Heiko Tietze (TDF) made it so Select All in Calc selects only the closest range of cells filled with data, added a command to cut a Calc cell without removing its formatting and made Calc column headers stand out
  29. László Németh fixed several issues related to images and objects in Writer tables, fixed resizing the rows and columns of Writer tables inside frames, continued polishing the No Break hyphenation feature, fixed spellchecking issues related to apostrophes, improved DOCX interoperability regarding hyphenation, made it so ASCII double quote matches typographic quote when searching, fixed a recent regression causing narrow no-break spaces to mess with spellchecking and fixed several AutoCorrect issues
  30. Ilmari Lauhakangas (TDF) fixed moving focus to document from Calc Functions Sidebar deck with Esc and made SVG images behave better in Help
  31. Christian Lohmaier (TDF) worked on Windows autoupdater and made large-scale simplifications to makefiles
  32. Thorsten Behrens (allotropia) worked on WASM build
  33. Eike Rathke (Red Hat) made it so certain range functions such as SUMIF and SUBTOTAL now accept inline arrays as arguments
  34. Jonathan Clark (TDF) fixed an issue causing incorrect glyphs to be displayed in RTL font fallback, fixes issues causing Writer to clip paragraphs at the ascent of the top line and descent of the last line, fixed overlapping RTL and LTR text when used together along with footnotes and fixed an issue causing Writer to corrupt layout for vertical text following a frame overflowing to the next page
  35. Regina Henschel made the handling of rotation angles conform to ODF spec
  36. Printf Debugging made it so there is feedback in the UI when resizing a frame or graphical objects would not be accepted
  37. Tibor Nagy (allotropia) fixed an issue with broken hyperlinks with ScreenTip set in imported DOCX files, made it so Name attributes of hyperlinks are exported to PDF as tooltips and fixed PPTX issues in the areas of colourmapping in master slides, placeholders, glue points and transparency
  38. Adam Seskunas worked on the GSoC project to port Java tests to C++
  39. Rafael Lima fixed an issue with Goal Seek macro corrupting the data in Calc cells, made Goal Seek settings be remember during a session and improved the visibility of outline in the selection overlay in Calc
  40. Leonard Sasse did cleanups in Python code
  41. Ritobroto Mukherjee ported some Java SDK examples to Python and worked on the GSoC project to implement cross platform .NET bindings for UNO API
  42. Attila Szűcs (Collabora) fixed images in PPTX files appearing horizontally compressed and fixed chart issues related to leader lines and pie chart label positions
  43. Andreas Heinisch made it so a jump statement is not executed in BASIC, if the expression is out of range, made case changing commands be correctly added by the macro recorder and aligned the implementation of the NOW function in BASIC with the one in Calc to include nanoseconds
  44. Hossein Nourikhah (TDF) made it so LibreOfficeKit headers are shipped in packages, allowing to create C++ applications that can access LibreOffice functionality without building LibreOffice, only by installing SDK and build tools
  45. Sujatro Bhadra replaced Show All and Hide All in the Comments category context menu of Writer Navigator with togglable commands Show Comments and Show Resolved Comments
  46. Kira Tubo added a unit test
  47. Theppitak Karoonboonyanan added a Thai thesaurus and Thai AutoCorrect Support

Kudos to Ilmari Lauhakangas for helping to elaborate this list.

Reported Bugs

432 bugs, 43 of which are enhancements, have been reported by 275 people.

Top 10 Reporters

  1. Eyal Rozenberg ( 16 )
  2. Gabor Kelemen (allotropia) ( 14 )
  3. Mike Kaganski ( 13 )
  4. Rafael Lima ( 11 )
  5. nobu ( 8 )
  6. Telesto ( 8 )
  7. Miklos Vajna ( 7 )
  8. Óvári ( 7 )
  9. Regina Henschel ( 7 )
  10. Olivier Hallot ( 6 )

Triaged Bugs

421 bugs have been triaged by 52 people.

Top 10 Triagers

  1. Stéphane Guillou (stragu) ( 107 )
  2. m_a_riosv ( 36 )
  3. Heiko Tietze ( 27 )
  4. ady ( 24 )
  5. Buovjaga ( 23 )
  6. Julien Nabet ( 22 )
  7. Mike Kaganski ( 18 )
  8. V Stuart Foote ( 18 )
  9. Xisco Faulí ( 14 )
  10. Dieter ( 11 )

Resolution of resolved bugs

436 bugs have been set to RESOLVED.

Check the following sections for more information about bugs resolved as FIXED, WORKSFORME and DUPLICATE.

Fixed Bugs

177 bugs have been fixed by 36 people.

Top 10 Fixers

  1. László Németh ( 19 )
  2. Mike Kaganski ( 13 )
  3. Michael Stahl ( 10 )
  4. Patrick Luby ( 8 )
  5. Miklos Vajna ( 8 )
  6. Tibor Nagy ( 7 )
  7. Balazs Varga ( 6 )
  8. Michael Weghorn ( 6 )
  9. Xisco Fauli ( 6 )
  10. Caolán McNamara ( 6 )

List of critical bugs fixed

  1. tdf#161461 Crash on second copy after pasting using Enter in Calc on macOS ( Thanks to Patrick Luby )

List of high severity bugs fixed

  1. tdf#141773 Autocorrection for all languages doesn’t work anymore ( Thanks to László Németh )
  2. tdf#160877 Paragraph classification deleted after Print Preview or when opening file ( Thanks to Xisco Fauli )
  3. tdf#161030 Vertical Tab dialogs–width available for Tab name is too narrow with jumping view of Tab names ( Thanks to Xisco Fauli )
  4. tdf#161198 Negative / inverted highlight when hovering Navigator elements (or Draw tabs) no longer shown ( Thanks to Noel Grandin )
  5. tdf#161498 autocontour function is broken (does not take into account PNG transparency) ( Thanks to Patrick Luby )
  6. tdf#161511 [CRASH] Macro using seekGoal crashes on a brand new document ( Thanks to Mike Kaganski )
  7. tdf#161653 The numbering toolbar dropdown no longer can select from the 8-block of options ( Thanks to Samuel Mehrbrodt )

List of crashes fixed

  1. tdf#160769 LibreOffice 24.2 Document recovery (from timed autoSave) doesn’t restore all open files after crash ( Thanks to Justin Luth )
  2. tdf#160801 Writer crash when use clear formatting after insert page break (macOS only) ( Thanks to Patrick Luby )
  3. tdf#161217 FILEOPEN DOCX Crash when opening specific file ( Thanks to Michael Stahl )
  4. tdf#161346 CRASH: exporting to PDF ( Thanks to Michael Stahl )
  5. tdf#161461 Crash on second copy after pasting using Enter in Calc on macOS ( Thanks to Patrick Luby )
  6. tdf#161511 [CRASH] Macro using seekGoal crashes on a brand new document ( Thanks to Mike Kaganski )
  7. tdf#161786 Manually entering “oper” in the formula editor will cause a crash ( Thanks to Julien Nabet )

List of performance issues fixed

  1. tdf#155212 Writer is very slow when

by x1sc0 at July 08, 2024 11:15 AM

June 27, 2024

LibreOffice Dev Blog

LibreOfficeKit API in action

If you want to use LibreOffice functionality in your applications, LibreOfficeKit API is one of the good ways to do that. Here I describe how, with some examples. If you want to add the capability of loading, displaying, editing, saving and/or converting LibreOffice/MS Office files to your application, you have come to a good place.

What is LibreOfficeKit?

LibreOfficeKit is the (relatively) new API to access LibreOffice functionalities in C/C++ without the need of older UNO API and its dependencies. It is the underlying technology for LibreOffice Online, and also LibreOffice Viewer for Android.

LibreOffice functionality is usable via the older UNO API, which is several years old and provides many functionalities of LibreOffice through network or sockets. But UNO API is not helpful if you want to have the LibreOffice UI in your application. In comparison, LibreOfficeKit is capable of doing that.

LibreOfficeKit can create tiles from the LibreOffice, as a static library. It lets the user interact with LibreOffice from somewhere else, either different application, or a web browser.

In this way, it becomes much easier to create applications that incorporate the actual functionalities of LibreOffice in them, while having the LibreOffice UI in themselves.

Example: GTK Tiled Viewer

As an example, gtktiledviewer provides a small editor that can load the LibreOffice/MS Office files, display them and the user can actually edit those files.

LibreOffice GTK Tiled Viewer

LibreOffice GTK Tiled Viewer

If you have a working build of LibreOffice, you can run thegtktiledviewer application this way:

bin/run gtktiledviewer --lo-path=$PWD/instdir/program path/to/test.odt

Building such an application will be much easier compared to building and running LibreOffice UNO API applications which require many dependencies.

In order to compile LibreOfficeKit applications, you need LibreOfficeKit headers. These headers will be shipped with the  next version of LibreOffice community distribution, LibreOffice 24.8.

Example Usage: Document conversion

Another interesting example is document conversion. For example, if you want to convert an ODT file to PDF or other formats with LibreOffice, you can use LibreOfficeKit API to do that.

One example code that does that is the lloconv project. You may find it on gitlab:

The conversion code happens inside convert.cc source file, and it is pretty straightforward, although there are some extra code which handles finding LibreOffice binary path, and parsing command line arguments.

The important functions that are used in loading and converting documents can be found in these lines:

Office * llo = lok_cpp_init(lo_path);

And also:

Document * lodoc = llo->documentLoad(input_url.c_str(), options);

And at last:

lodoc->saveAs(output_url.c_str(), format, options)

It  essentially initializes the document vialok_cpp_init, then loads the document using documentLoad function, and at last convert it to the final file format using saveAs() function.

The API for conversion is pretty straightforward, and it is enough to to know the path to the LibreOffice installation path to be able to compile and run the C++ example.

More interesting things are possible with LibreOfficeKit API, and I will write more about them.

by Hossein Nourikhah at June 27, 2024 02:07 PM

June 19, 2024

Collabora Community

Hacking LibreOffice in Budapest

Earlier this month, we were pleased to sponsor the Libreoffice Technology Hackfest in Budapest, Hungary, and enjoyed meeting up with some of our fellow LibreOffice Technology hackers. Over two days, a dozen developers from Collabora Productivity and the wider community met up in the Eco Community Space to work on the LibreOffice codebase, and reap the benefits of spending time together.

 

A hackfest is an event where developers from multiple organisations meet each other, work on what they want and also more freely exchange ideas while being together in person. While having an international community working remotely on the codebase is excellent, there are still many benefits to more directly seeing what problems are being tackled by other developer sitting next to you; and this friendly environment allows building relationships that can then help even more in the future (even remotely).

As one attendee Miklos Vajna shared with us after the event, “It was really great to spend a couple of days with the other developers. I found it very helpful seeing what other people are working on, sharing ideas about the future feature possibilities, and especially enjoyed going out for a dinner with everyone in Budapest after a hard day’s work!

For this reason, we were very pleased to sponsor this most recent meet up. Many thanks to all who joined us in Budapest, we look forward to seeing you soon at the next meeting!

If you would like to find out more about joining the Collabora Online or LibreOffice community, we would encourage you to join the Collabora Online Community Forum or have a look at the Collabora Online Github to learn about how to get started.

For more information about our upcoming events, and to learn where you could meet us next, do have a look at our events page.

by Richard Brock at June 19, 2024 11:00 AM

June 14, 2024

LibreOffice QA Blog

LibreOffice 24.8 Beta1 is available for testing

LibreOffice 24.8 will be released as final at the end of August, 2024 ( Check the Release Plan ) being LibreOffice 24.8 Beta1 the second pre-release since the development of version 24.8 started at the beginning of December, 2023. Since the previous release, LibreOffice 24.8 Alpha1, 672 commits have been submitted to the code repository and 191 issues got fixed. Check the release notes to find the new features included in this version of LibreOffice.

IMPORTANT INFORMATION FOR WINDOWS 7 USERS
Internal python version has been upgraded to python 3.9 which no longer supports Windows 7. It’s very important to us to know whether LibreOffice 24.8 still works on Windows 7 or not, as well as its python functionalities. Please, do test this version and give us feedback.

LibreOffice 24.8 Beta1 can be downloaded for Linux, macOS and Windows, and it can be installed alongside the standard version.

In case you find any problem in this pre-release, please report it in Bugzilla ( You just need a legit email account in order to create a new account ).

For help, you can contact the QA Team directly in the QA IRC channel or via Matrix.

LibreOffice is a volunteer-driven community project, so please help us to test – we appreciate it!

Happy testing!!

Download it now!

by x1sc0 at June 14, 2024 02:23 PM

June 05, 2024

LibreOffice Design Blog

Convenient handling of shortcuts

Shortcuts are a major topic for user experience. Novices are advised to learn basic shortcuts beyond the famous Ctrl+C/X/V like Ctrl+1/2/3.. to quickly change the paragraph style to heading 1/2/3… in Writer. Once you have learned those combinations you never want to unlearn and to change the muscle memory.…

by Heiko Tietze at June 05, 2024 01:35 PM

June 03, 2024

Miklos Vajna

Section-based continuous endnotes in Writer

Writer now has much better support for continuous / inline endnotes (not on a separate page) in Writer, enabled by default for DOCX files.

This work is primarily for Collabora Online, but the feature is fully available in desktop Writer as well.

Motivation

As described in a previous post, Writer already had minimal support for not rendering endnotes on a separate endnote page, but it was not mature enough to enable is by default for DOCX files.

Results so far

What changed from the previous "continuous endnotes" approach is that instead of trying to map endnotes to footnotes, we now create a special endnotes section, which only exists at a layout level (no section node is backing this one), and this hosts all endnotes at the end of the document. It turns out this is a much more scalable technique, for example a stress-test with 72 endnotes over several pages is now handled just fine.

Here are some screenshots:

Before: reference is red, Writer result is painted on top of it

After: reference is red, Writer result is rendered on top of it

As you can see, there were various differences for this document, but the most problematic one was that the entire endnote was missing from the (originally) last page, as it was rendered on a separate page.

Now it's not only on the correct page, but also its position is correct: the endnote is after the body text, while the footnote is at the bottom of the page, as expected. The second screenshot shows ~no red, which means there is ~no reference output, where the Writer output would be missing.

How is this implemented?

If you would like to know a bit more about how this works, continue reading... :-)

As usual, the high-level problem was addressed by a series of small changes:

The tracking bug was tdf#160984.

Want to start using this?

You can get a development edition of Collabora Online 24.04 and try it out yourself right now: try the development edition. Collabora intends to continue supporting and contributing to LibreOffice, the code is merged so we expect all of this work will be available in TDF's next release too (24.8).

by Miklos Vajna at June 03, 2024 02:26 PM

May 30, 2024

LibreOffice Dev Blog

Porting Java tests to C++

In this blog post, I discuss porting Java tests from Java to C++. We have many Java tests, and porting them to C++ is beneficial for LibreOffice. Here I discuss why, and how.

Why Porting Java Tests?

In the past, Java was used extensively in LibreOffice, and many tests where written in Java. They consist of various tests, including JUnit.

Searching for junit in LibreOffice source code gives many results: (Note that this is not the number of tests)

$ git grep -i junit | wc -l

901

Although these tests are useful, they have drawbacks:

1. They are slower than C++ CppUnitTests

2. They are outside process, which is creates them even more slower, and harder to debug

Porting these tests to C++ can make them faster, more reliable, and easier to debug. Let’s see how we can do it.

Start from Examples

The best way to find out how to do porting is to look into the previous examples. This issue is around porting Java API tests to C++:

There are many commits in the above page, which can be an interesting way to learn how to do that. For example, consider this commit:

In the above commit, Jens has ported qadevOOo/tests/java/ifc/sheet/_XSheetCellRanges.java test to C++ test test/source/sheet/xsheetcellranges.cxx.

I can summarize the changes in this way:

1. An equivalent C++ file, in test/ folder

2. Removal of Java file from qadevOOo/.

3. The Makefiles in test/ and qadevOOo/ folders should reflect the removal of Java test, and addition of C++ test.

4. Some Java tests are adjusted to reflect the deletion of the old Java test.

5. Some C++ tests are adjusted to reflect the addition of new C++ test.

Final Words

To be able to port a test, one should be able to understand the old test. Reading the code is the best way that one can achieve this purpose. By looking into similar ports, you can gain a better understanding of what to do. In Bugzilla page for tdf#45904, you may find similar ports.

by Hossein Nourikhah at May 30, 2024 02:08 PM

May 27, 2024

Björn Michaelsen

Writer Again!

Writer Again!

After resigning from the Board of Directors of TDF over the weekend, I hope I will again find more time to look into the technical details of LibreOffice Writer. I will also try to do my best to write some good article here about the depth of that application. While a text processor in itself is not that interesting anymore these days, the challenges of migrating that big old legacy code might be fascinating quite often. Hope to have you as a reader for that soon!

Comments? Feedback? Additions? Most welcome here on the fediverse !

May 27, 2024 12:14 PM

April 30, 2024

allotropia

LibreOffice, JavaScript’ed

LOWA is LibreOffice built with Emscripten as a Wasm executable that runs in the browser. Controlling that LibreOffice through UNO with JavaScript looks like a natural fit. Enter Embind, a mechanism to generate the binding glue between JavaScript and Wasm/C++.

As we will see, the Embind vs. UNO match is not perfect, but it kind-of gets the job done, at least for a first iteration.

Mappings

To dive straight into technical matters, the UNO type system is mapped to JavaScript as follows. (If you would like to see some example code first, jump ahead to the Starting Points and come back here later for reference.)

  • UNO BOOLEAN, depending on context and somewhat inconsistently maps to JavaScript Boolean and to JavaScript Number values 0 and 1. (The C/C++ representation of UNO BOOLEAN is sal_Bool, which is an alias for unsigned char, which Embind maps to JavaScript Number. So in places where we directly rely on Embind, like for the return value of a UNO interface method invocation, we get the Embind mapping to Number. But in places where we have more control, like for the JavaScript get method for a UNO ANY, we can be a bit more fancy and use a mapping to Boolean.)
  • UNO BYTE, SHORT, UNSIGNED SHORT, LONG, UNSIGNED LONG, FLOAT, and DOUBLE all map to JavaScript Number (with restricted value ranges for everything but UNO DOUBLE).
  • UNO HYPER and UNSIGNED HYPER both map to JavaScript BigInt (with restricted value ranges).
  • UNO CHAR and STRING both map to JavaScript String (with single UTF-16 code unit strings for UNO CHAR).
  • UNO TYPE maps to JavaScript Module.uno_Type objects. There are construction functions Module.uno_Type.Void, Module.uno_Type.Boolean, Module.uno_Type.Byte, Module.uno_Type.Short, Module.uno_Type.UnsignedShort, Module.uno_Type.Long, Module.uno_Type.UnsignedLong, Module.uno_Type.Hyper, Module.uno_Type.UnsignedHyper, Module.uno_Type.Float, Module.uno_Type.Double, Module.uno_Type.Char, Module.uno_Type.String, Module.uno_Type.Type, Module.uno_Type.Any, Module.uno_Type.Sequence, Module.uno_Type.Enum, Module.uno_Type.Struct, Module.uno_Type.Exception, and Module.uno_Type.Interface for representations of all the UNO TYPE values. The Module.uno_Type.Sequence construction function recursively takes a UNO TYPE argument for the component type, while the Module.uno_Type.Enum, Module.uno_Type.Struct, Module.uno_Type.Exception, and Module.uno_Type.Interface construction functions each take a string argument denoting the given type’s name in dotted notation (e.g., Module.uno_Type.Interface('com.sun.star.uno.XInterface')). Those JavaScript objects implement toString, which is also used for equality checks (e.g., type === 'com.sun.star.uno.XInterface').
  • UNO ANY maps to JavaScript Module.uno_Any objects. There is a constructor taking a UNO TYPE argument and a corresponding value (using an undefined value for UNO type VOID). Those JavaScript objects implement a method get that returns the JavaScript representation of the contained UNO value.
  • UNO sequence types map to a pre-canned variety of JavaScript Module.uno_Sequence_... objects. The problem is that Embind does not let us have a generic mapping to the C++ com::sun::star::uno::Sequence<T> class template; we can only have individual Embind mappings to specific class template instantiations. As a hack, for every UNO sequence type that appears somewhere in the LibreOffice UNO API, we generate a specific JavaScript Module.uno_Sequence_.... The naming is Module.uno_Sequence_boolean, Module.uno_Sequence_byte, Module.uno_Sequence_short, Module.uno_Sequence_unsigned_short, Module.uno_Sequence_long, Module.uno_Sequence_unsigned_long, Module.uno_Sequence_hyper, Module.uno_Sequence_unsigned_hyper, Module.uno_Sequence_float, Module.uno_Sequence_double, Module.uno_Sequence_char, Module.uno_Sequence_string, Module.uno_Sequence_type, and Module.uno_Sequence_any for the simple UNO component types; Module.uno_Sequence_... followed by the UNO type name in dollar-separated notation (e.g., Module.uno_Sequence_com$sun$star$uno$XInterface) for enum, struct, and interface component types; and Module.uno_SequenceN_..., with N greater than 1, for sequence component types (e.g., Module.uno_Sequence2_long for the UNO type “sequence of sequence of LONG“). That means that there currently is just no way to come up with e.g. a JavaScript representation of the UNO type “sequence of interface com.sun.star.frame.XDesktop“, as that sequence type happens to not be mentioned anywhere in the LibreOffice UNO API. (But for those sequence types that are used as interface method parameter or return types, corresponding JavaScript representations are provided. That should hopefully cover all relevant use cases for now; a future overhaul of this part of the mapping is likely.) These JavaScript sequence objects have two constructors, one taking a JavaScript array of member values (e.g., new Module.uno_Sequence_long([1, 2, 3])) and one taking a size and a Module.FromSize marker (as Emind does not allow to have multiple constructors with the same number of arguments) whose members will have default values (e.g., new Module.uno_Sequence_long(3, Module.FromSize)). Additional methods are resize (taking the new length as argument), size (returning the current length), get (taking an index as argument and returning the member at that index), and set (taking an index and a new member value as arguments). (The naming of those resize, size, get, and set methods is modelled after Embind’s emscripten::register_vector.)
  • UNO enum types are mapped to Embind-provided enums named Module.uno_Type_... followed by the UNO type name in dollar-separated notation (e.g., Module.uno_Type_com$sun$star$uno$TypeClass).
  • Plain UNO struct types and UNO exception types are mapped to Embind-provided value objects named Module.uno_Type_... followed by the UNO type name in dollar-separated notation (e.g., Module.uno_Type_com$sun$star$beans$NamedValue, Module.uno_Type_com$sun$star$uno$Exception). Polymorphic UNO struct types face a similar issue to sequence types, in that Embind does not allow to directly map their corresponding C++ class templates. It would be possible to do a similar hack and add specific mappings for all instantiated polymorphic struct types that are mentioned anywhere in the LibreOffice UNO API, but that has not been implemented so far. (And, similar to sequence types, a future overhaul of this part of the mapping is likely.)
  • UNO interface types are mapped to Embind-provided classes named Module.uno_Type_... followed by the UNO type name in dollar-separated notation (e.g., Module.uno_Type_com$sun$star$uno$XInterface). Null references are mapped to JavaScript null. The special com.sun.star.uno.XInterface UNO interface methods queryInterface, acquire, and release are not exposed to JavaScript client code.
  • UNOIDL single-interface–based service constructors are mapped to JavaScript functions named Module.uno_Function_...$$... followed by the service’s name in dollar-separated notation, followed by the constructor’s name set of by two dollar signs (e.g., Module.uno_Function_com$sun$star$beans$Introspection$$create). Like with other UNO language bindings, those functions take the com.sun.star.uno.XComponentContext as an additional first argument.
  • UNOIDL service-based singletons are mapped to JavaScript functions named Module.uno_Function_... followed by the singleton’s name in dollar-separated notation (e.g., Module.uno_Function_com$sun$star$frame$theDesktop). Like with other UNO language bindings, those functions take the com.sun.star.uno.XComponentContext as their (sole) argument.

Starting Points

To make all this work, the Embind mapping of the LibreOffice UNO API needs to be set up first. This is done by a call to

const uno = init_unoembind_uno(Module);

which also returns a wrapper object uno that allows for more natural access to all the UNOIDL entities whose mappings use that dollar-separated notation: Instead of Module.uno_Type_com$sun$star$uno$XInterface one can write uno.com.sun.star.uno.XInterface, and a call to uno_Function_com$sun$star$beans$Introspection$$create(context) can be written as uno.com.sun.star.beans.Introspection.create(context). If you want to cut down on the common uno.com.sun.star prefix even further,

const css = uno.com.sun.star;

lets you reduce that to just css.uno.XInterface and css.beans.Introspection.create(context).

The starting points to access the LibreOffice UNO API from JavaScript are Module.getUnoComponentContext() (returning the central css.uno.XComponentContext, through which all the services and singletons are reachable) and a Module.getCurrentModelFromViewSh() convenience function (returning the css.frame.XModel of the currently showing document). The gitlab.com/allotropia/lowa-demos repository is a growing site of example code showing all of this in action.

Summing this up, here is some example code that iterates over all the paragraphs of a Writer document and gives each of them a random foreground text color:

const uno = init_unoembind_uno(Module);
const css = uno.com.sun.star;
const model = Module.getCurrentModelFromViewSh();
const document = css.text.XTextDocument.query(model);
const text = document.getText();
const access = css.container.XEnumerationAccess.query(text);
const paragraphs = access.createEnumeration();
while (paragraphs.hasMoreElements()) {
  const paragraph = css.text.XTextRange.query(
    paragraphs.nextElement().get());
  const props = css.beans.XPropertySet.query(paragraph);
  const color = new Module.uno_Any(
    Module.uno_Type.Long(),
    Math.floor(Math.random() * 0xFFFFFF));
  props.setPropertyValue("CharColor", color);
  color.delete();
}

Cleanup

Embind is built on the concept that whatever C++ objects you reference from JavaScript, you manually and explicitly need to declare those references as no longer needed once you are done, by calling delete() methods on the corresponding JavaScript objects. (Or else, you risk memory leaks.) This can be quite cumbersome and would pollute the code with tons of such delete() calls. Luckily, JavaScript grew a FinalizationRegistry mechanism that allows code to be executed when the JavaScript garbage collector finds an objet to be unused and reclaims it. (And that code can thus transparently do the delete() call for us.) Embind implements such FinalizationRegistry-support for some types (those that are modelled based on some “smart poiner”) but not for others.

That means that (besides all the primitive types) JavaScript mappings of UNO string, type, enums, sequences, exceptions, and interfaces all do not need explicit delete() calls, while the mappings of UNO any and UNO sequences, and the various Module.uno_InOutParam_... all need explicit delete() calls.

Even though we expect that the JavaScript engines that we target do support the FinalizationRegistry mechanism, Embind is prepared to work with older engines that do not support it. Therefore, whenever an object is transparently cleaned up, Embind logs a somewhat unhelpful warning to the JavaScript console, stating that it “found a leaked C++ instance” (and that it will “free it automatically”).

Interfaces

For each UNO interface type there is a JavaScript class method query taking any JavaScript UNO object reference (in the form of the common com.sun.star.uno.XInterface base interface) as argument (and internally using UNO’s queryInterface to obtain either a correspondingly-typed reference to that object, or a null reference). There is also a JavaScript helper function Module.sameUnoObject, taking two interface references as arguments and returning whether both are references to the same UNO object.

UNO interface methods taking out or in-out parameters need special treatment. There are Module.uno_InOutParam_... wrappers (with a val property carrying the actual value) that need to be set up and passed into the UNO method. Such wrappers have a constructor taking no arguments (creating a dummy object, suitable for pure out parameters) and another constructor taking one argument of the wrapped type (suitable for in-out parameters). For example, to read data from a com.sun.star.io.XInputStream:

const stream = ...;
const input = css.io.XInputStream.query(stream);
if (input) {
  const data = new Module.uno_InOutParam_sequence_byte;
  input.readBytes(data, 100);
  for (let i = 0; i != data.val.size(); ++i) {
    console.log('read byte ' + data.val.get(i));
  }
  data.delete();
}

Exception Handling

Support for throwing and catching exceptions between JavaScript and C++ is rather rough: JavaScript code can use try ... catch (e) ... to catch a UNO exception thrown from C++, but all the information it can get about that exception is e.name stating the exception’s type. Also, for technical reasons, the catch block needs some increment– and decrementExceptionRefcount boilerplate,

try {
  ...
} catch (e) {
  incrementExceptionRefcount(e);
    //TODO, needed when building with JS-based -fexceptions,
    // see
    // <https://github.com/emscripten-core/emscripten/issues/17115>
    // "[EH] Fix inconsistency of refcounting in Emscripten
    // EH vs. Wasm EH"
  if (e.name === 'com::sun::star::uno::RuntimeException') {
    ...
  }
  decrementExceptionRefcount(e);
}

To throw UNO exceptions from JavaScript code, there is a helper function Module.throwUnoException that takes a UNO (exception) type and an instance of that type:

Module.throwUnoException(
  Module.uno_Type.Exception(
    'com.sun.star.lang.IllegalArgumentException'),
  {Message: 'bad argument', Context: null,
   ArgumentPosition: 0});

UNO Objects

The JavaSript-to-UNO binding is a full mapping, so you can even implement new UNO objects in JavaScript. This requires quite some boilerplate, though. For example, the below obj implements com.sun.star.lang.XTypeProvider and com.sun.star.task.XJob:

const obj = {
  // Implementation details:
  implRefcount: 0,
  implTypes: new Module.uno_Sequence_type([
    Module.uno_Type.Interface(
      'com.sun.star.lang.XTypeProvider'),
    Module.uno_Type.Interface(
      'com.sun.star.task.XJob')]),
  implImplementationId: new Module.uno_Sequence_byte([]),

  // The methods of XInterface:
  queryInterface(type) {
    if (type == 'com.sun.star.uno.XInterface') {
      return new Module.uno_Any(
        type,
        css.uno.XInterface.reference(
          this.implXTypeProvider));
    } else if (type == 'com.sun.star.lang.XTypeProvider') {
      return new Module.uno_Any(
        type,
        css.lang.XTypeProvider.reference(
          this.implXTypeProvider));
    } else if (type == 'com.sun.star.task.XJob') {
      return new Module.uno_Any(
        type,
        css.task.XJob.reference(
          this.implXJob));
    } else {
      return new Module.uno_Any(
        Module.uno_Type.Void(), undefined);
    }
  },
  acquire() { ++this.implRefcount; },
  release() {
    if (--this.implRefcount === 0) {
      this.implXTypeProvider.delete();
      this.implXJob.delete();
      this.implTypes.delete();
      this.implImplementationId.delete();
    }
  },

  // The methods of XTypeProvider:
  getTypes() { return this.implTypes; },
  getImplementationId() {
    return this.implImplementationId;
  },

  // The methods of XJob:
  execute(args) {
    if (args.size() !== 1 || args.get(0).Name !== 'name') {
      Module.throwUnoException(
        Module.uno_Type.Exception(
          'com.sun.star.lang.IllegalArgumentException'),
        {Message: 'bad args', Context: null,
         ArgumentPosition: 0});
    }
    console.log(
      'Hello, my name is ' + args.get(0).Value.get());
    return new Module.uno_Any(
      Module.uno_Type.Void(), undefined);
  },
};
obj.implXTypeProvider
  = css.lang.XTypeProvider.implement(obj);
obj.implXJob
  = css.task.XJob.implement(obj);

obj.acquire();
// ... pass obj to UNO here ...
obj.release();

by stbergmann at April 30, 2024 11:32 AM

April 04, 2024

Miklos Vajna

Improve copy&paste in Calc and elsewhere

Calc now supports much better copy&paste when you transfer data between Google Sheets and Calc.

This work is primarily for Collabora Online, but the feature is fully available in desktop Calc as well.

Motivation

First, Collabora Online was using the deprecated document.execCommand() API to paste text, which is problematic, as the "paste" button on the toolbar can't behave the same way as pressing Ctrl-V on the keyboard.

Second, it turns out Google Sheets came up with some additional HTML attributes to represent spreadsheet data in HTML in a much better way, and Calc HTML import/export had no support for this, while this is all fixable.

Results so far

In short, Collabora Online now uses the Clipboard API to read from the system clipboard -- this has to be supported by the integration, and Calc's HTML filter now support the subset of the Google Sheets markup I figured out so far. This subset is also documented.

Note that the default behavior is that the new Clipboard API is available in Chrome/Safari, but not in Firefox.

For the longer version, here are some screenshots:

We used to show a popup when you clicked on the paste button on the notebookbar

The new paste code in action, handling an image

Import from Google Sheets to Calc: text is auto-converted to a number, bad

Import from Google Sheets to Calc: text is no longer auto-converted to a number, good

HTML import into an active cell edit, only RTF was working there previously

Paste from Google Sheets to Calc: text is no longer auto-converted to a number, good

Paste from Google Sheets to Calc: booleans are now also preserved

Paste from Google Sheets to Calc: number formats are now also preserved

Paste from Google Sheets to Calc: formulas are now also preserved

Paste from Google Sheets to Calc: also handling a single cell

Copy from Calc to Google Sheets: text is now handled, no longer auto-converted to a number

Copy from Calc to Google Sheets: booleans are now handled

Cross-origin iframes also block clipboard access, now fixed

Copy from Calc to Google Sheets: number formats are now also preserved

Copy from Calc to Google Sheets: formulas are now also preserved

Copy from COOL Writer to a text editor: much better result, new one on the right hand side

How is this implemented?

If you would like to know a bit more about how this works, continue reading... :-)

As usual, the high-level problem was addressed by a series of small changes:

The tracking issue on the Online side was cool#8023.

Want to start using this?

You can get a snapshot / demo of Collabora Office 24.04 and try it out yourself right now: try the unstable snapshot. Collabora intends to continue supporting and contributing to LibreOffice, the code is merged so we expect all of this work will be available in TDF's next release too (24.8).

by Miklos Vajna at April 04, 2024 07:50 AM

March 12, 2024

Jean Hollis Weber

LibreOffice 24.2 Writer Guide published

LibreOffice Writer Guide 24.2LibreOffice 24.2 Writer Guide has been published. It is available for free download (PDF, ODT) from the Documentation page on the LibreOffice website.

Printed copies can be purchased from the Documentation Team’s store at Lulu.com.

The numbering system for LibreOffice releases has changed to year.month. LibreOffice will continue to be updated twice a year, but current plans are to update each user guide only once a year.

by Jean at March 12, 2024 01:34 AM

February 18, 2024

Jean Hollis Weber

Getting Started Guide 7.6 published

LibreOffice 7.6 Getting Started GuideLibreOffice 7.6 Getting Started Guide has been published. It is available for free download (PDF, ODT) from the Documentation page on the LibreOffice website.

Printed copies can be purchased from the Documentation Team’s store at Lulu.com.

by Jean at February 18, 2024 01:18 AM

February 11, 2024

Caolán McNamara

coverity 2022.6.0 and LibreOffice


After a long slog since November when the previous version of coverity was EOLed and we had to start using 2022.6.0 with its new suggestions for std::move etc, LibreOffice is now finally back to a 0 warnings coverity state

by caolan (noreply@blogger.com) at February 11, 2024 06:02 PM

January 25, 2024

Marius Popa Adrian

Firebird 5.0 Is Released

Firebird Project is happy to announce general availability of Firebird 5.0 — the latest major release of the Firebird relational database for Windows, Linux, MacOS and Android platforms.This release introduces improvements in areas of performance, multithreaded processing (including backup, restore, sweep), SQL queries profiling, with better scalability and numerous enhancements in SQL

by Popa Adrian Marius (noreply@blogger.com) at January 25, 2024 10:29 AM

January 12, 2024

LibreOffice Design Blog

Comments in Sidebar

Using comments is a key feature in text processing. A typical workflow might be to review a document where notes are made by different colleagues. LibreOffice Writer currently shows these comments in the document margin, which is limited to the page height, ending up in the need to scroll long text (even while editing [1]) and eventually in paging-like interactions if the number of comments exceed the total size.…

by Heiko Tietze at January 12, 2024 01:22 PM

December 18, 2023

Marius Popa Adrian

Call For Testing Firebird ODBC Driver for Firebird 3.x

The new version of Firebird ODBC driver is in Beta stage now. Version 3.0.0 Beta is available for testing on Windows. It works only with Firebird 3+ , and requires fbclient.dll from Firebird 3 or above.https://github.com/FirebirdSQL/firebird-odbc-driver/wikiPlease download, test, and report any issues!Issues can be reported here: https://github.com/FirebirdSQL/firebird-odbc-driver/issuesOriginal

by Popa Adrian Marius (noreply@blogger.com) at December 18, 2023 07:20 PM

December 08, 2023

Jean Hollis Weber

LibreOffice 7.6 Calc Guide

Cover of Calc 7.6 GuideThe LibreOffice 7.6 Calc Guide has been published. It is available for free download (PDF, ODT) from the Documentation page on the LibreOffice website.
Printed copies can be purchased from the Documentation Team’s store at Lulu.com.

by Jean at December 08, 2023 08:13 AM

November 19, 2023

Stephan Bergmann

I like it here. Can I stay?

(And do you have a vacancy for a back-scrubber?)

Thank you, Red Hat, for generously letting me work for so long on stuff that is near and dear to my heart. At the intersection of theory and practice, of compiler technology and the LibreOffice code base. But, to keep doing what I love, I need to move on.

So, thank you, allotropia, for having me. I’m excited.

And, above all, thank you, LibreOffice, family of friends. Lets make sure to keep this a happy family, one that Tolstoy would have nothing to write home about. With quarrels and arguments, for sure; feud even. But happy at heart. I wish to keep meeting you all for years to come, virtually, and for a feast at FOSDEM or LOCon. And booze.

To paraphrase Hamburger Tafel (donations needed, btw), “Wir haben LibreOffice noch lange nicht satt.”

Have fun, stay safe, peace,
sberg

by stbergmann at November 19, 2023 10:58 AM