by Popa Adrian Marius (noreply@blogger.com) at May 05, 2023 04:12 PM
by Popa Adrian Marius (noreply@blogger.com) at May 05, 2023 04:12 PM
Berlin, May 4, 2023 – LibreOffice 7.5.3 Community, the third minor release of the LibreOffice 7.5 line, the volunteer-supported free office suite for desktop productivity, is available from https://www.libreoffice.org/download for Windows (Intel/AMD and ARM processors), macOS (Apple Silicon and Intel processors), and Linux [1].
A description of new features of LibreOffice 7.5 is available in the Release Notes [2].
Based on the distinctive features of the LibreOffice Technology platform for personal productivity on desktop, mobile and cloud, LibreOffice 7.5 provides a large number of improvements and new features targeted at users sharing documents with MS Office or migrating from MS Office. These users should check new releases of LibreOffice on a regular basis, as the progress is so fast, that each new version improves dramatically over the previous one.
Products based on LibreOffice Technology are available for major desktop operating systems (Windows, macOS, Linux and Chrome OS), for mobile platforms (Android and iOS), and for the cloud.
For enterprise-class deployments, TDF strongly recommends the LibreOffice Enterprise family of applications from ecosystem partners – for desktop, mobile and cloud – with a large number of dedicated value-added features and other benefits such as SLA (Service Level Agreements): https://www.libreoffice.org/download/libreoffice-in-business/.
Availability of LibreOffice 7.5.3 Community
LibreOffice 7.5.3 Community is available from: https://www.libreoffice.org/download/. Minimum requirements for proprietary operating systems are Microsoft Windows 7 SP1 and Apple macOS 10.14. LibreOffice Technology-based products for Android and iOS are listed here: https://www.libreoffice.org/download/android-and-ios/.
The Document Foundation does not provide technical support for users, although they can get it 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 with a donation at https://www.libreoffice.org/donate.
[1] Change log pages: https://wiki.documentfoundation.org/Releases/7.5.3/RC1 and https://wiki.documentfoundation.org/Releases/7.5.3/RC2
[2] Release Notes: https://wiki.documentfoundation.org/ReleaseNotes/7.5

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





Writer now has continued steps to handle tables that are both floating and span over multiple pages.
This work is primarily for Collabora Online, but is useful on the desktop as well. See the second post for background.
The previous post finished with cursor traversal: if a floating table is on both page 1 and page 2, then you expect Writer to be able to move between the rows of the table, even if those are not on the same page. In this post, we'll see what else started to work during the past month.
The feature is enabled by default and now the DOCX/DOC/RTF import makes use of it if. This allows stress-testing the layout code with complex user documents, hopefully with the found breakage fixed before it would be released in a stable version.
On the positive side, core.git repository has has 19 files now which are focusing on correct handling of floating tables. Also, there are additional tests that quickly build a specific multi-page floating table in the memory and do some operation on it, e.g. delete the last row and assert what happens.
Here are some screenshots from the effort so far:

The first case is about editing: if a floating table had a first, middle and last page, then deleting the last row of a table lead to incorrect layout, which is now fixed.

An odd problem is that the vertical position of tables on non-first pages is generated by the layout, which means that normal drag&move to position them won't work, leading to annoying jumps. This is now fixed by selecting the first (master) fly frame on click, and you can always reposition that table (even vertically.)

Once DOCX import/export was there, the next step is binary DOC import, which gives us access to a larger corpus of test documents, to stress-test the layout code. This shows how the binary DOC import looked before the work.

And this one shows how it works now.

DOC import is not enough, e.g. Collabora Online will save your documents automatically, so we really want to export everything that is possible to import. Here is how good DOC export looks like in Word.

At this point the first crashtest results arrived (we try to import about 280 thousand documents and see what crashes). The first problem was floating tables in footers. Well, we should not try to split such tables (even if they don't fit): adding one more page does not give us more footer space.

Similar to the DOC filter, RTF can express floating tables. Here is how we did a bad rendering of an RTF document before.

And here is how we import it currently. The RTF control words are quite close to the binary DOC markup semantically, just the syntax is different.

The RTF export side was also missing, as visible in Word, before the work.

And this is how the good RTF export result looks like in Word.

Another crashtest find was that sometimes we map Word's continuous section breaks to Writer sections, so we can't assume that tables are anchored directly in body frames. This is now fixed.

A related problem was that non-floating tables have a trick, that we call the TableRowKeep mode. If this is on (which is the default for documents imported form Word), a table row will stick to the next table row (we try to keep them on the same page) if the first cell's first paragraph in that row has the "keep with next" paragraph property specified. It turns out, this should be ignored when the table is floating.

A next problem was that some page breaks simply disappeared. It turns out that we need to transfer the "break before" property from the table to the table anchor (paragraph) to get the desired layout, since page breaks are generally ignored inside text frames.

All combinations of nesting with floating tables is not yet handled, but at least we should not crash when the user tries to do that. Here is 3 tables, nested in each other, the second table is marked to be floating.

The last fixed problem is when a floating table is immediately followed by an other, non-floating table. Given that we try to anchor the floating table in the next paragraph, the layout could not handle this previously, but now we ensure that each floating table is followed by a paragraph.
And that's where we stand. Hope to address all problems reported by crashtesting soon. Once that happens, it may be possible to switch from bugfixing mode to feature mode again, e.g. better handling of overlapping or nested tables could be done.
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:
You can get a snapshot / demo of Collabora Office 23.05 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 (7.6).

(This is part of The Document Foundation’s Annual Report for 2022 – we’ll post the full version here soon.)
In January 2022, our English-language Twitter account @LibreOffice had 45,802 followers; by the end of the year, we had grown this to 52,808. Our most popular tweets were for major releases, but we also tweeted customised images for “Community Member Monday” interviews with short quotes, encouraging more users to get involved with LibreOffice projects.
In addition, we focused not only on our own tweets, but also retweeting announcements from the LibreOffice ecosystem and community members. We liked and retweeted messages of support from end users – many of whom were surprised and thankful that a large project would show them support. To keep the content flowing, we retweeted popular older tweets, and responded to individual messages.
On other social media platforms, we focused on growing our account on Mastodon, a Twitter-like open source, federated and self-hosted microblogging service. In 2019 we set up @libreoffice and started posting content, often more focused on technical users, compared to our tweets and Facebook posts. In 2022 we worked more on expanding our activities here, and from January to December, we grew our follower base from 6,844 to 16,500.

Our Facebook page growth was smaller, from 59,241 page likes to 60,209. We’ve noticed a gradual reduction in activity on Facebook over the last few years, which reflects its changing audience, and the move towards newer mobile applications. Nonetheless, Facebook still provides a good opportunity to interact with end users of LibreOffice, and every day we checked in to answer questions, get feedback, and post announcements/tips about the software.
Our YouTube channel grew from 15,015 subscribers and 2,420,699 video views in January 2022 to 17,964 subscribers and 2,858,092 video views by the end of the year. The “LibreOffice 7.3: New Features” video (a fantastic production by the Indonesian community) had over 196,000 views – while the video for LibreOffice 7.4 had over 47,000. We also added videos from FOSDEM and the LibreOffice Conference 2022.
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.
If you accept this notice, your choice will be saved and the page will refresh.
Meanwhile, our community helped out with tutorial videos – in particular Harald Berger of the German community, who continued to produce a series of professional-looking step-by-step guides to installing and using LibreOffice.

Want to expand your skillset and gain experience with UX, marketing, documentation, QA or translations? Join the Month of LibreOffice, May 2023! Over the next four weeks, hundreds of people around the world will collaborate to improve LibreOffice – and you can help them. There are many ways to get involved, as we’ll see in a moment.
And best of all: everyone who contributes to LibreOffice in the next four weeks can claim a cool sticker pack, and has the chance to win extra LibreOffice merchandise such as mugs, hoodies, T-shirts, rucksacks and more (we’ll choose 10 participants at random at the end):

So, let’s get started! There are many ways you can help out – and as mentioned, you don’t need to be a developer. For instance, you can be a…
We’ll be updating this page every few days with usernames across our various services, as people contribute. So dive in, get involved and help make LibreOffice better for millions of people around the world – and enjoy your sticker pack at the end as thanks from us! And who knows, maybe you’ll be lucky enough to win bonus merch as well…

(This is part of The Document Foundation’s Annual Report for 2022 – we’ll post the full version here soon.)
Due to the COVID pandemic and travel restrictions our conferences for 2020 and 2021 had to take place online. For 2022, however, we could finally meet in-person again – although we live-streamed sessions, for participants to watch remotely (and they could ask questions in our chat channels too).
The conference took place from September 28 – October 1, in the Fondazione Culturale San Fedele, in downtown Milan. Four rooms were made available for the event: the auditorium, along with Ricci, Loyola and Saverio.

Following the opening session, presentations and talks were given across various “tracks”, or categories: Development, Advocacy, Marketing, Design, OpenDocument Format, Quality Assurance, Documentation and more. There were highly technical talks focused on specific areas of the software and source code, along with more open discussions about community building and recent updates from The Document Foundation.
In addition to the talks, where was also a community dinner evening, in which various kinds of pasta were served, along with a walking tour of interesting parts of the city. On the final day, the conference wrapped up with a closing session, headed by Italo Vignoli who helped to organise the event.

The event was sponsored by Collabora, allotropia, Net Service S.p.A and Passbolt. Thanks to this sponsoring, attendees could get merchandise at the conference, including T-shirts with the conference logo.

Full details about the event are available on our main conference website. For a quick overview of all the talks, including links to PDF versions of the presentations, see the schedule.
Videos from most of the talks are available in this playlist:
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.
If you accept this notice, your choice will be saved and the page will refresh.
Planning is already underway for the LibreOffice Conference 2023, which is due to take place in Bucharest, Romania in September. The local organisation team has already found a suitable location, and is now working on other preparations for the event, including visas for attendees, catering and merchandise. We at TDF are helping them to get things ready, and are very grateful for their work.
Thank you to all who attended our COOL Days 2023 meet up in Cambridge on 28th & 29th March. We had a great time organising the event for our partners, the Collabora team and open source community. It was a great success!
If you didn’t manage to make it to Cambridge, check out our 90 second YouTube short which shows a quick overview of the fun we had.
COOL Days was based at Clare College, the second oldest of the 31 historic Cambridge Colleges. We started off our packed schedule full of lightning talks, partner workshops and team building with a meal at Millworks on the Monday evening (famous for it’s delicious Shawarma!)
Is it possible to fit 45 lightning talks into one day? Yes!
We were live from Cambridge all day on Tuesday 28th March. It was wonderful to see so many presentations of all the work that’s been developing over the last 6 months by the Collabora Online team, community and partners all across Europe and beyond.


Wednesday 29th March was our Partner Day, full of workshops and discussions around our collaborative Partner Programme. It was a privilege to have Simon Phipps and Robert Riemann kick off the day with their insights into the importance of data protection in Europe and future of open source.
Throughout the rest of the day we had many open discussions with our Partners about how we can support them and work together even more successfully and talked about the development road map for 2023.


We made sure there were plenty of opportunities for team building including a treasure hunt around Cambridge, punting down the river Cam and of course, some delicious meals together. On the final evening we dined at Ridley Hall which for many, gave them a taster of what dining at Hogwarts might be like – minus the owls!
You may have seen some of our team live tweeting from the event – search #COOLDays and follow us on Twitter, Mastodon and Linkedin to see updates from events and conferences throughout the year.
We hope to see you at our next COOL Days event.
In the meantime, keep an eye out for where we’ll be next:
May 6, 2023 – Bern, Switzerland
May 12 - 13, 2023 – Zaragoza, Spain
September 20 - 23, 2023 – Bucharest, Romania
The post Recapping COOL Days 2023: The Event that Rocked Cambridge! appeared first on Collabora Office and Collabora Online.
Kudos to Ilmari Lauhakangas for helping to elaborate this list.
630 bugs, 72 of which are enhancements, have been reported by 370 people.
842 bugs have been triaged by 86 people.
649 bugs have been set to RESOLVED.

Check the following sections for more information about bugs resolved as FIXED, WORKSFORME and DUPLICATE.
207 bugs have been fixed by 42 people.
List of high severity bugs fixed
List of crashes fixed
List of performance issues fixed
List of old bugs ( more than 4 years old ) fixed
Writer now has the early steps to handle tables that are both floating and span over multiple pages.
This work is primarily for Collabora Online, but is useful on the desktop as well. See the first post for background.
The previous post finished with split rows are now in a reasonable shape towards our journey to fix tdf#61594. In this post, we'll see what else is needed to get perfect rendering for that single document.
The plan is to iterate on that later, adding more and more incremental improvements & fixes for this feature.
The feature is still enabled by default, but the DOCX import only makes use of it if you set the
SW_FORCE_FLY_SPLIT=1 environment variable. This allows playing with the feature even if there are
lots of known problems still.
On the positive side, core.git sw/qa/core/layout/data/ has 12 files now which are rendered exactly
the way Word does. Also, there are additional tests that quickly build a specific multi-page
floating table in the memory and do some operation on it, e.g. delete the last row and assert what
happens.
Here are some screenshots from the effort so far:

Here the problem was that a normal row went to a next page after a split row. Now the document is correctly of 2 pages, instead of the previous unwanted 3 pages.

Here the additional complexity was to have multiple columns on a table, since previously we always had 1 column and 2 or more rows. Now these are also split correctly across pages.

This is an incorrect table row split, because widow control is broken.

And here is how it looks when it's working. That little line on page 2 is no longer alone.

Even better when the minimal height for non-first ("follow") table frames is working, as you can notice that space between the last line and the table bottom border on page 2.
At this point, the bug document from the motivation section worked fine, apart from the workaround that one has to re-save it in non-legacy mode in Word. So what's next? We need to instantly add a legacy mode for the brand new (not even fully enabled) multi-page floating table feature, since otherwise whatever we do, some DOCX files will be handled incorrectly.

As it turns out, the core of the legacy mode is that the floating table is sometimes allowed to flow into the footer / bottom margin area of the page, but not always. It's quite inconsistent, so one can understand why this is no longer the default behavior. The above is the naive rendering, which is logical, but incorrect.

And this is the correct result in legacy mode. After a bit of experimenting, it seems one can flow into the bottom margin area if the height of the table frame would fit the body frame, but some vertical offset causes it to be pushed down.

The final trick with legacy mode is to make sure that all tables (first one, middle ones, last one) have the required minimal height, which can result in not splitting the row in case a part of that would be less than the minimal height. E.g. a 3 cm minimal height means that a total height of 4 cm (2cm + 2cm) is not enough for a split row.
With this, we reached the goal to render that given bug document perfectly (when compared to Word), and the next step is to fix up breakage that would be caused by enabling by default.

The first problem was tracked changes support, which needs special care: as the importer converts body text to table cells, we need to keep the tracked insert/delete text ranges correctly. This is now working fine.

The next problem is around nested tables: a normal inner table inside a floating table was lost on DOCX file open, now fixed.

The other version is when a normal table has an inner floating table. This broke badly, the outer table was not imported at all.

And it's now better. The inner table is still not actually floating, but turns out that was never working for DOCX files, so it's not a regression. Fine to revisit that only later.

So far all the previous tables were aligned to the left. It turns out that the horizontal positioning was bad in every other case for non-first tables, e.g. when you wanted to center them.

And it's now fixed.
As a last fix for this post, let's look at traveling with the cursor:

After fixing this, now you can use the up/down arrows to go from the A1 cell to A2 and back. The cursor traversal code wasn't aware that the master/follow table frame was connected.
And that's where we stand. Hope to enable even the DOCX import bit by default soon.
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:
You can get a snapshot / demo of Collabora Office 23.05 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 (7.6).
by Popa Adrian Marius (noreply@blogger.com) at April 02, 2023 12:20 PM
In every C/C++ source code file, we use header files to put declarations of functions, data types, class, macro and other relevant things inside it. These files have the extension of .h (for C) and .hxx (for C++).
We have different header types: internal and global includes. You can find some of the header files in many places. For example, in LibreOffice we have several modules that many other modules depend on them. Here, we focus on the VCL module. For the global includes, they are placed inside include/ folder, and for internal headers of VCL module, the include files are put inside include/vcl/.
On the other hand, not all the VCL headers are beneficial outside the VCL module. In this case, it is preferred that these include files are put inside the vcl/ folder. Usually, those header files should be inside vcl/inc folder.
As an example, we have the header include/vcl/salnativewidgets.hxx file which have declarations that are not used outside vcl/. In this case, we can put the declarations inside vcl. The suggested place is vcl/inc/nativewidgets.hxx.
As suggested in the bug report, one trick is to look at the class/function declaration. If it doesn’t have a SAL_DLLPUBLIC attribute decorating it, there is good chance that you can move it to the private headers, and in this case, vcl/inc/ folder.
Other than that, you should use the include syntax <…>. For example, if you have created vcl/inc/nativewidgets.hxx, then the include syntax would be:
#include <nativewidgets.hxx>
This is because the file is not exactly next to the cxx file. You can read more here:
EasyHacks are good starting points for someone who wants to start LibreOffice development. This specific issue for improving header files of VCL is avaiable as tdf#97228 in TDF’s Bugzilla. To understand how to start LibreOffice development, you can refer to our getting involved page in the TDF Wiki, or our video tutorial for getting started with LibreOffice development.
Towards GTK 4.10 some of the functionality to integrate LibreOffice's internal accessibility support with GTK has been exposed. Some experimenting this week with GTK trunk gives me the above, writer's document accessibility hierarchy integrated with the GTK one.
Very little actually works, but a working base to start from.
by Popa Adrian Marius (noreply@blogger.com) at March 20, 2023 11:01 PM
by Popa Adrian Marius (noreply@blogger.com) at March 17, 2023 10:03 PM
Kudos to Ilmari Lauhakangas for helping to elaborate this list.
589 bugs, 78 of which are enhancements, have been reported by 382 people.
665 bugs have been triaged by 83 people.
483 bugs have been set to RESOLVED.

Check the following sections for more information about bugs resolved as FIXED, WORKSFORME and DUPLICATE.
164 bugs have been fixed by 37 people.
List of critical bugs fixed
List of high severity bugs fixed
List of crashes fixed
List of old bugs ( more than 4 years old ) fixed
73 bugs have been retested by 35 people.
125 bugs have been duplicated by 29 people.
45 bugs have been verified by 17 people.
426 bugs have been categorized with a metabug by 34 people.
Recent user guides from the LibreOffice Documentation team are available for free download (PDF, ODT) from the Documentation page on the LibreOffice website, and low-cost printed copies can be purchased from Lulu.com.
LibreOffice 7.4 Draw Guide
LibreOffice 7.5 Writer Guide
LibreOffice 7.5 Calc Guide
LibreOffice uses an internal GUI toolkit, named VCL (Visual Class Library). It creates the GUI widgets for LibreOffice, but it is not generally available for other applications. But there are ways that you can create standalone applications with VCL, at least to learn it better.
If you take a look into the vcl/workben, you will see several workbenches that are actually built during the build process. Previously, we discussed some of them in this post.
Now, I want to discuss the code of the simplest example: minvcl.
It basically creates a simple application with a single window, and that’s all! But even doing that needs several steps. Let’s discuss the code itself.
First come the includes. The include sal/config.h should come with each and every file in LibreOffice, and also VCL. Then, we have several includes from framework, cpppuhelper, comphelper, com/sun/star/lang and com/sun/star/uno, and then language classes from i18nlangtag.
#include <sal/config.h> #include <framework/desktop.hxx> #include <cppuhelper/bootstrap.hxx> #include <comphelper/processfactory.hxx> #include <com/sun/star/lang/XMultiServiceFactory.hpp> #include <com/sun/star/uno/XComponentContext.hpp> #include <i18nlangtag/languagetag.hxx> #include <i18nlangtag/mslangid.hxx>
After that, comes the includes from VCL. We only use two: the one for a VCL application, and another for a VCL window:
#include <vcl/svapp.hxx> #include <vcl/wrkwin.hxx>
Keep in mind that you have to provide the link libraries via the make file. In this case, the make file is vcl/Executable_minvcl.mk:
...
$(eval $(call gb_Executable_use_libraries,minvcl,\
tl \
sal \
vcl \
cppu \
cppuhelper \
comphelper \
i18nlangtag \
fwk \
))...
And at last, the include file for the main function of the VCL application. Every VCL application is supposed to have SAL_IMPLEMENT_MAIN() instead of main(), which is declared in this file.
#include <sal/main.h> #include <iostream>
The class TheApplication should fall into an anonymous namespace. This class inherits the VCL application class with the name of Application. As you can see, we keep a VclPtr to a vcl::Window named mpWin that keeps a pointer to our window.
namespace
{
class TheApplication : public Application
{
public:
virtual int Main();
private:
VclPtr<vcl::Window> mpWin;
};
}
In the main file, we use a method named Create() to create a window. Then, we set the title using SetText(), and then invoke show() to make the window visible on the screen. This is the main file of the VCL application. It is the entry point for the application.
int TheApplication::Main()
{
mpWin = VclPtr<WorkWindow>::Create(nullptr, WB_APP | WB_STDWORK);
mpWin->SetText(u"Minimum VCL application with a window");
mpWin->Show();
Execute();
mpWin.disposeAndClear();
return 0;
}
We use LibreOffice APIs to create a component context and a service manager. The setProcessServiceFactory() function is used to set the service manager for the process. To understand the service manager, you can refer to the DevGuide:
The LanguageTag::setConfiguredSystemLanguage() function sets the language of the application to the system language. Finally, the framework::getDesktop() function terminates the framework and the DeInitVCL() function frees VCL resources.
SAL_IMPLEMENT_MAIN()
{
try
{
TheApplication aApp;
auto xContext = cppu::defaultBootstrap_InitialComponentContext();
css::uno::Reference<css::lang::XMultiServiceFactory> xServiceManager(
xContext->getServiceManager(), css::uno::UNO_QUERY);
comphelper::setProcessServiceFactory(xServiceManager);
LanguageTag::setConfiguredSystemLanguage(MsLangId::getSystemLanguage());
InitVCL();
aApp.Main();
framework::getDesktop(::comphelper::getProcessComponentContext())->terminate();
DeInitVCL();
comphelper::setProcessServiceFactory(nullptr);
}
catch (...)
{
std::cout << "Exception has occurred\n";
return 1;
}
return 0;
}
We should handle the exception in the main function. Here, we just print a simple text to make the user aware that some bad thing has happened.
That’s all! The application is complete now. You can run it via:
./bin/run minvcl
Keep in mind that you have to compile LibreOffice first. 

The minvcl window
There are many complex things that you can do with VCL, but this was the simplest example that you can possibly create! I will discuss creating more complex applications that create user interfaces with things like buttons, text and many other UI things. The nice thing about VCL is that you can even create UI from the widgets created from the .ui files designed with Glade. This makes creating GUIs much easier.
I will discuss more complex examples in the next blog posts.
Writer now has the early steps to handle tables that are both floating and span over multiple pages.
This work is primarily for Collabora Online, but is useful on the desktop as well.
As requested in tdf#61594 10 year ago, the use-case is that you can already have floating tables:

And multi-page tables:

And what we want is a combination of them, like this:

This is a quite complicated feature, since both floating objects and tables are complex, and this combines them to create even more complexity.
However, such constructs are used in existing DOCX files and we're expected to correctly display them.
The feature is enabled by default, but the DOCX import only makes use of it if you set the
SW_FORCE_FLY_SPLIT=1 environment variable. This allows playing with the feature even if there are
lots of known problems still.
On the positive side, core.git sw/qa/core/layout/data/ has 4 files now which are rendered exactly
the way Word does.
A bit of terminology: once a frame is split, the first element of the chain is called master, the remaining frames are called follows.
Here are some screenshots from the journey so far:

This is a fly frame with enough content that it doesn't fit the body frame. It should split, but fly frames could not be split.

First try, just limit the height of the (master) fly frame, so at least it stays inside the body frame. But now some content is not rendered.

Next try. Now have have 2 flys, but the second has zero height and the content of the second fly leaks into the body of the second page.

This one is better, but the position of the follow fly frame is bad, no actual wrapping happens. Also, we assume that there are multiple paragraphs after the table, which will cause problems for floating tables at the end of the document. So I reworked the anchoring code to split the anchor to as many pages as necessary...

Which sounds good, but now the text around the anchor point is duplicated.

Better, now the anchor text is gone in the master anchor, but still there is a misleading paragraph marker.

And now this looks reasonable. Fine, we have some minimal split flys, let's try it with tables instead of just two paragraphs:

With a bit of work, the table's two rows can split, but again the text in the anchor is duplicated.

Next try, now the anchor text is correct, but the horizontal position of the table is still bad, it bleeds out towards the left margin area.

And with more work, now this looks correct.

Let's add some vertical offset! That should be only applied on the first page, and now the follow fly doesn't have that unwanted offset.
Now we have 2 documents that lay out correctly on 2 pages. Let's try 3 pages:

This falls apart, the 2nd and the 3rd row are both on page 2.

After partitioning the fly frames to 3 categories (master, non-last follows, last follow), more than 2 pages also work.

This is a sample where the table has a single cell, so we need to split the (only) row, not just split the table's rows. The first is harder. Currently we don't even try to split it.

Next try, now we split it, but the position of the follow fly is wrong.

Finally split of a single row inside multi-page floating tables also work. That's where we are. Don't try to do anything too custom (like inserting a header or footer), those cases are still known-broken.
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 design of the layout representation is documented in the SwFormatFlySplit constructor.
You can get a snapshot / demo of Collabora Office 23.05 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 (7.6).
In this article, I will discuss the recent problems with compiling LibreOffice using Microsoft Visual Studio, things that I did to debug and find the root cause, the source of problem itself – which is problems in Microsoft’s telemetry – and how I could fix it.
Recently, I was encountering a problem when configuring LibreOffice’s source code before compilation. Sometimes, random errors appeared without further details on why. The title: “powershell.exe” was also strange, as I wasn’t using PowerShell directly.

Powershell Error
At first, I ignored the message, but then it become more error common, and at some point the configuration was aborted. I ignored that for a while, but after a few days, one of the mentees reported a somehow similar problem.
The error was that the UCRT (which is Microsoft Visual Studio C++’s standard C library), was not found. This is an error log:
$ ./autogen.sh . . . checking for Windows SDK... found Windows SDK 10.0 (/cygdrive/c/PROGRA~2/WI3CF2~1/10) checking for midl.exe... C:\Program Files (x86)\Windows Kits\10\/Bin/10.0.20348.0/x64/midl.exe checking for csc.exe... C:\Windows\Microsoft.NET\Framework\v4.0.30319\/csc.exe checking for al.exe... C:\Program Files (x86)\Microsoft SDKs\Windows\v10.0A\bin\NETFX 4.8 Tools\/al.exe checking .NET Framework... found: C:/PROGRA~2/WI3CF2~1/NETFXSDK/4.8/ checking whether jumbo sheets are supported... yes checking whether to enable runtime optimizations... yes checking for valgrind/valgrind.h... no checking for sys/sdt.h... no checking what the C++ library is... configure: error: Could not figure out what C++ library this is Error running configure at ./autogen.sh line 321.
The important log that contains the output of the configuration is the config.log file. In this file, I could see these related lines:
... configure:19511: result: no configure:20052: checking what the C++ library is configure:20078: C:/PROGRA~1/MIB055~1/2022/COMMUN~1/VC/Tools/MSVC/1430~1.307/bin/Hostx64/x64/cl.exe -c -IC:/PROGRA~2/WI3CF2~1/10/Include/ucrt -IC:/PROGRA~2/WI3CF2~1/10/Include/ucrt -IC:/PROGRA~1/MIB055~1/2022/COMMUN~1/VC/Tools/MSVC/1430~1.307/Include conftest.cpp >&5 conftest.cpp C:/PROGRA~1/MIB055~1/2022/COMMUN~1/VC/Tools/MSVC/1430~1.307/Include\cstddef(12): fatal error C1083: Cannot open include file: 'stddef.h': No such file or directory Microsoft (R) C/C++ Optimizing Compiler Version 19.30.30711.2 for x64 Copyright (C) Microsoft Corporation. All rights reserved. ...
The strange thing was that I could configure that compilation with another Cygwin terminal with slightly different settings. To find the differences, I used the command export to see the values of the environment variables in the two configured terminals, and compare them using diff.
Then, I found that I could evade the problem by setting this environment variable. This was the environment variable from one of the terminals:
export CYGWIN="disable_pcon" https://cygwin.com/cygwin-ug-net/using-cygwinenv.html
Unfortunately, this was not the case for our mentee who has the same problem. I also knew that this approach may lead to performance degradation.
I tried to look further into the details of configure.ac, and debug to understand the root cause of the problem. At first, I changed the version manually in configure.ac, and the configuration actually worked! If you take a look into find_ucrt() function, the relevant part is:
PathFormat "$(win_get_env_from_vsdevcmdbat UniversalCRTSdkDir)" UCRTSDKDIR=$formatted_path UCRTVERSION=$(win_get_env_from_vsdevcmdbat UCRTVersion)
Setting the PathFormat and UCRTVERSION to something from a good build fixed the problem: configuration and make went smooth, and finished successfully.
Then, I tried to look into win_get_env_from_vsdevcmdbat() function. As the name implies, it runs the VsDevCmd.bat, and uses the contents of the two environment variables: PathFormat and UCRTVERSION.
This function creates a batch file in the temporary folder, runs it and gets the output, and then removes it. So, removed the removal part, and saved the created batch files.
I was skeptical about the commands that were processing the outputs of the batch files, so I tried to change them a little, but that didn’t help. The nice thing was that each of them were working fine. I ran them several times, but there was no problem! Then I decided to run them exactly one after another, and then I saw that sometimes there was no output.
At the point, I was almost certain that the problem was from the VSDevCMD.bat itself, but I didn’t know why, and how to fix that. So, I took a look into the script, and guess what: the problem was from the telemetry! If the variable VSCMD_SKIP_SENDTELEMETRY is not set, the command line tries to open a PowerShell script, and send data to Microsoft! That was the source of problem. This is the relevant part of the code:
@REM Send Telemetry if user's VS is opted-in
if "%VSCMD_SKIP_SENDTELEMETRY%"=="" (
if "%VSCMD_DEBUG%" NEQ "" (
@echo [DEBUG:%~nx0] Sending telemetry
powershell.exe -NoProfile -Command "& {Import-Module '%~dp0\Microsoft.VisualStudio.DevShell.dll'; Send-VsDevShellTelemetry -NewInstanceType Cmd;}"
) else (
START "" /B powershell.exe -NoProfile -Command "& {if($PSVersionTable.PSVersion.Major -ge 3){Import-Module '%~dp0\Microsoft.VisualStudio.DevShell.dll'; Send-VsDevShellTelemetry -NewInstanceType Cmd; }}" > NUL
)
)
To fix that, I used the value 1 for the variable to opt out of telemetry:
set VSCMD_SKIP_SENDTELEMETRY=1
This change is now merged into the LibreOffice code:
So, the problem should be fixed by now.
It took a lot of time to debug and find the root cause of the problem. I think the best way to avoid causing problems for the users of the Visual Studio would be asking for the users’ consent before activating the telemetry.
I agree that there are legitimate or justifiable reasons to do telemetry, but getting the users’ consent is very important before sending data back to the corporate servers.
In LibreOffice, we consider users the top priority, and we are bound to the best practice of: “Telemetry required? Ask users first”, and we ask others to do the same.
On last Saturday I talked online (using our jitsi) about QA process in LibreOffice for some Russian people who want to be QA engineer in near future. One smart person made the record of my video presentation and now you can watch it on Youtube by link below:
There were around 20 persons there. Some from them now want to try to contribute in LibreOffice project as QA. Let's see =)
by Roman Kuznetsov (noreply@blogger.com) at February 13, 2023 08:31 AM
Kudos to Ilmari Lauhakangas for helping to elaborate this list.
501 bugs, 44 of which are enhancements, have been reported by 302 people.
717 bugs have been triaged by 77 people.
541 bugs have been set to RESOLVED.

Check the following sections for more information about bugs resolved as FIXED, WORKSFORME and DUPLICATE.
164 bugs have been fixed by 34 people.
List of critical bugs fixed
List of high severity bugs fixed
List of crashes fixed
List of old bugs ( more than 4 years old ) fixed
Writer now has a set of new automation commands and APIs that allow clients to build user interface for citation handling that's more advanced than the default in-Writer bibliography support.
This work is primarily for Collabora Online, see the CODE release notes for one possible way to use this.

Users frequently using scientific citations are probably familiar with the limits of Writer's built-in bibliography support, and solutions like Zotero appeared (with a LibreOffice extension included) to improve that situation.
This means that instead of storing all your scientific notes and data locally, you can store them on a Zotero server, then work with that from anywhere, once you provide your credentials.
The trouble comes when you want to combine this with collaborative editing, which is provided by Online, but you can't use the extension made for the desktop.
The above CODE release notes explains how an end user can use this feature, this post is meant to document what new UNO commands and LOK APIs I added that serve as a backend for this. Especially the UNO commands are also useful in other contexts, like in macros or other extensions.
Zotero can store citations using 3 markups in documents: fields (DOCX only), bookmarks (DOCX and ODT) and finally reference marks / sections (ODT only). The added plumbing allows several operations for all 3 cases, to work with existing documents using any of these markups.
The citation and the bibliography is handled the same way for fields (Writer's fieldmarks) and bookmarks. The last case uses reference marks for citations, but sections for the bibliography.
The following operations are supported:
create the citation / bibliography
read the object under the cursor
read all objects of a given type in the document
update the object under the cursor
update all objects of a given type in the document
delete all objects of a given type in the document
Reading is only available to LOK clients, you need to call the getCommandValues() API. The rest is normal UNO commands that you can invoke from document macros or extensions as well.
The added plumbing is the following:
| Operation | Fieldmark | Bookmark | Refmark | Section |
|---|---|---|---|---|
| Create | .uno:TextFormField | .uno:InsertBookmark | .uno:InsertField | .uno:InsertSection |
| Read | getCommandValues(".uno:TextFormField") | getCommandValues(".uno:Bookmark") | getCommandValues(".uno:Field") | None |
| Read all | getCommandValues(".uno:TextFormFields") | getCommandValues(".uno:Bookmarks") | getCommandValues(".uno:Fields") | getCommandValues(".uno:Sections") |
| Update | .uno:UpdateTextFormField | .uno:UpdateBookmark | .uno:UpdateField | None |
| Update all | .uno:TextFormFields | .uno:UpdateBookmarks | .uno:UpdateFields | .uno:UpdateSections |
| Delete all | .uno:DeleteTextFormFields | .uno:DeleteBookmarks | .uno:DeleteFields | .uno:DeleteSections |
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:
You can get a snapshot / demo of Collabora Office 22.05 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 (7.6).
A QR code is a type of 2D barcode that is useful for encoding data, such as a URL, contact information and many other data types. One can scan the code via applications on mobile phones to capture a URL or import contact information.
For example, the code below encodes the address of the LibreOffice website:

Encoding LibreOffice website’s URL in a QR code
In LibreOffice, it is possible to create different barcodes, either 1D or 2D, via extensions, or LibreOffice’s internal functionality.

QR code dialog
For QR codes, it is possible to use the internal functionality via Insert > OLE Object > QR and Barcode:
The implementation in LibreOffice is using ZXing QR code library:
If you take a look at the source code in cui/source/dialogs/QrCodeGenDialog.cxx, there is ConvertToSVGFormat() function which creates the SVG output. In the recent versions of ZXing library (we use v1.4 right now), there is a function that does that, ZXing::ToSVG(). The task here is to replace the our function with the one from ZXing library.
Unfortunately, only recent versions of ZXing provide ZXing::ToSVG() functions. It is not available in 1.3, but is added in 1.4. Looking into the packaging of the library in different distributions, it becomes obvious that this package version is not available yet in many distributions:
Therefore, a solution should check the ZXing library version, and use the new function if the library version is >= 1.4. In other words, limiting the change to where the new version of the library is present is necessary. This is possible using compiler conditionals. It is important where one configures the LibreOffice compilation to use system provided ZXing library, using --with-system-zxing while invoking autogen.sh.
EasyHacks are good starting points for someone who wants to get started in LibreOffice development. This specific issue for improving QR code is filed as tdf#153328 in TDF’s Bugzilla. To understand how to get started with LibreOffice development, you can refer to our getting involved page in the TDF Wiki, or our video tutorial for getting started with LibreOffice development.

FOSDEM 2023 is back home in Brussels. Meet the Collabora Productivity team at Europe’s largest gathering of open-source developers and have a chat, some fries or a beer with us (also: make sure to grab some stickers!). As usual, our engineers will be giving talks about the latest developments in Collabora Online, Collabora Office and LibreOffice at the LibreOffice Technology devroom. Here’s the schedule!
Most of the easy tasks are already done. This talk covers several improvements to LibreOffice, that required lots of preparational work and interesting challenges to introduce improvements into a massive (and messy) codebase.
In the talk, Pranam Lashkari will explain and demonstrate how feature locking and restrictions work in Collabora Online. Using such methods, integrators can control which features to deliver to which user or group.
Sarper Akdemir tells the story of an interoperability bug fixing adventure where the problem turned out to be deeper than it appeared at first glance, showcasing how there are multiple approaches to a single interoperability problem.
LibreOffice was capable of handling form filling in Writer for a while already. In the meantime, the competition introduced Structured Document Tags. Writer Content Controls are meant to perform a great handling of this third type of form filling. See Miklos Vajna‘s talk about what we have done to bring themes to LibreOffice, hear what still needs doing and find out how you can help.
Szymon Klos gives a short introduction into integrating LibreOffice using LibreOfficeKit with external software. He will describe the most important code pieces and show, where to look for information. Furthermore, he’ll demonstrate how to add new features, which API we provide, and what can be done with tiled rendering.
Come and hear how Collabora Online (COOL) has improved over the COVID-19 era, not only in core feature-function, but also in ease of access and deployment for everyone. See how we can deliver scalable, secure, on-premise editing of your documents with a simple, easy to deploy office for the free world.
Collabora Online is quite flexible in the means that you can alter to your personal taste without the need to change other core components. Pedro Pinto Silva shows how to make Collabora Online yours. Discover all the shining new additions to the user interface and learn how to customize and integrate it everywhere.
Come hear Tor Lillqvist‘s talk about a new approach to enabling browser deployment of rich office functionality – built on top of allotropia’s investment in enabling the core LibreOffice technology to compile to Web Assembly (WASM) – combined with the Collabora Online front-end. Hear about how this can be used to provide a fall-back (non-collaborative) editing mode for when you lose network connectivity for a while, and about the plans to re-synchronize documents on the return from such a tunnel.
Collabora Online 22.05 is our latest enterprise release. It’s suitable for large-scale deployment, and comes with SLA, enterprise support with signed security updates as well as interaction with product management, helping to direct our development priorities. Collabora Online integrates flawlessly into Nextcloud, ownCloud, Seafile, and many of the major file sync & share, groupware and hosting solutions. It’s ideal for organizations that want to collaborate on documents, without losing control over them or compromising on privacy. With the ability to host it on your own hardware or to integrate it into a trusted environment, Collabora Online is the ideal online office suite for digital sovereignty. Enterprises interested in using Collabora Online can check out our home page for more information on partner integrations and online demos. Hosting and Cloud businesses that wish to add Collabora Online to their product portfolio can become a partner. For any questions or tailored solutions, do not hesitate to contact hello@collaboraoffice.com.
The post Collabora Productivity at FOSDEM 2023 appeared first on Collabora Office and Collabora Online.
You may already know that LibreOffice uses its internal GUI toolkit, named VCL (Visual Class Library). This library is responsible for creating the GUI widgets for LibreOffice, providing abstraction from the operating system including the basic rendering. To see more details, you can read its documentation page:
VCL has the nice feature of being able to work with different GUI libraries on different platforms. For example, if you are on Linux, you can use X11, Gtk3/4, Qt, or KDE back-ends for the VCL applications like LibreOffice. You can easily switch between them by using the environment variable SAL_USE_VCLPLUGIN. For example, you can use the old style X11 GUI in this way:
SAL_USE_VCLPLUGIN=gen instdir/program/soffice
Or, by passing it to the LibreOffice program itself:
instdir/program/soffice -env:SAL_USE_VCLPLUGIN=gen
In addition, there are other GUI backends, or plugins which are as follows:
| UI Plugin | UI Backend |
qt5 |
Qt 5 |
qt6 |
Qt 6 |
kf5 |
KDE KF5 |
gtk3 |
GTK 3 |
gtk4 |
GTK 4 |
gtk3_kde5 |
GTK 3 KDE 5 |
win |
Windows UI (Windows only) |
osx |
macOS X UI (macOS only) |
You can read more about the related environment variables here:
The code for the library is available in the vcl/ folder inside core source code. Also, beside the main source code and tests, there is a folder named workbench. Inside this folder, you can find several standalone VCL applications:
vcldemo: This is a showcase of some of the VCL rendering abilities including the lines, shapes, internationalized text, pictures and more! You can see run this demo by invoking this command, after you could be able to build LibreOffice:
./bin/run vcldemo

vcldemo
minvcl: This is possibly one of the smallest example application that can be created with VCL. Basically, It creates a window and draws a simple text inside it. Likewise, you can run it by invoking:
./bin/run minvcl

minvcl
icontest: This bitmap image testing is used by some of the developers to test VCL bitmap rendering capabilities. It can be invoked this way:
./bin/run icontest <image>
mtfdemo: This is a small application for displaying and dumping the structure of EMF/EMF+/WMF files, which is a vector image format from Microsoft. This is previously discussed in another blog post here:
Similarly, it can be run in this way:
./bin/run mtfdemo <emf|wmf image>
listfonts: This utility lists the current list of fonts installed in the system, and the features of each font. To display the information on the screen, you can invoke it this way:
./bin/run listfonts --
listglyphs: This utility lists the current glyphs in a font that is already installed on the system. You should provide the font name to it, in this way:
./bin/run listglyphs FreeMono --
Beyond the above applications and tools, there are many other platform specific tools that are not available on each and every platform. Also, there are many fuzzers ans testing tools that are helpful for fuzz-testing the library. You can find the complete list of executables using this command:
ls vcl/Executable_*.mk
As can be seen in the output, many of them are fuzzers. To use the fuzzers, first you have to setup the oss-fuzz via ./bin/oss-fuzz-setup.sh script. Then, you may be able to build the fuzzers using ./bin/oss-fuzz-build.sh script. Make sure that you have $OUT, $SRC and $WORK environment variables to set the fuzzer build environment. Be ready for several tarballs and archives downloads at first. You will need curl and svn to continue.
These tools and small applications and their source code are good for testing and getting to understand the VCL library better. As a suggestion, you can start from the minvcl.cxx to understand how to create a GUI application that can work across various platforms with different GUI toolkits. Hopefully, I will discuss the source code of some of these examples in the later blog posts.
LibreOffice 7.5 will be released as final at the beginning of February, 2023 ( Check the Release Plan ) being LibreOffice 7.5 Release Candidate 2 (RC2) the forth and final pre-release since the development of version 7.5 started in mid June, 2022. Since the previous release, LibreOffice 7.5 RC1, 89 commits have been submitted to the code repository and 39 issues got fixed. Check the Release Notes to find the new features included in this version of LibreOffice.
LibreOffice 7.5 RC2 can be downloaded for Linux, macOS and Windows, and it will replace 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!!
Kudos to Ilmari Lauhakangas for helping to elaborate this list.
437 bugs, 53 of which are enhancements, have been reported by 260 people.
583 bugs have been triaged by 65 people.
534 bugs have been set to RESOLVED.

Check the following sections for more information about bugs resolved as FIXED, WORKSFORME and DUPLICATE.
146 bugs have been fixed by 31 people.
List of high severity bugs fixed
List of crashes fixed
List of performance issues fixed
List of old bugs ( more than 4 years old ) fixed
Numbering and bullet list are a core feature of every word processing application, and naturally LibreOffice Writer has gazillion options in that area. Of course, Writer can also handle multilevel lists:
Now, how are these lists stored in ODF? Each level defines a num-prefix (what will be written before numbering), a num-suffix (same as prefix, but appended after the number), and display-levels – determining how many previous levels will be in list:
<text:list-level-style-number
text:level="3"
style:num-prefix=">>"
style:num-suffix="<<"
style:num-format="1"
text:display-levels="3">
In this example, we define a format for the third list level (in a numeric format), with displaying of all 3 levels and >> & << as a prefix/suffix. The output in Writer then looks like this: “>>1.2.3<<”
This is a nice and concise representation for many Western use-cases. But what can we do in this example:

Or in this case (https://bugs.documentfoundation.org/show_bug.cgi?id=116883):

One possible simple solution: we add a configurable number delimiter. In most cases, we would separate level numbers by “.” (and this was hard-coded in LO previously). For other cases, we should use “-” or “/”.
But before getting ahead of ourselves, lets first take a look what Word and DOCX does here:

Hmm, so Word does something completely different here: instead of a prefix/suffix, it uses an elaborate formatting string for numbers, where we can define any random prefix and suffix, plus arbitrary delimiters between different level numbers! We can even omit some numbers or worse, change their order of appearance (it is unclear how much sense that makes, but surely someone is now (mis)using that feature out there in documents).
And this is stored in DOCX in a rather simple xml attribute:
<w:lvlText w:val="%1-%2-%3-%4-"/>
Instead of prefix, suffix, display-levels and some additional separators, this has just one property, which at the same time provides much more flexibility.
Since LibreOffice 7.0, we are now using this lvlText (list format string) as an internal representation for documents (https://git.libreoffice.org/core/+/7459b9ecb54a298f02d19089620149718f8d8d48). This is enough to correctly load and save DOCX/DOC/RTF files, like the one from the screenshot above.
But we need to go further. If we save such DOCX files to ODT, more complex list level formattings will be lost.
Starting with LibreOffice 7.2, and with commit https://gerrit.libreoffice.org/c/core/+/117156/16, LibreOffice now features something quite similar to the DOCX properties: a new loext:num-list-format, which is obsoleting the older, less expressive num-prefix, num-suffix and text:display-levels attributes.
Unlike in DOCX instead of placeholders like “%1”, “%2”, this new ODF property is using “%1%”, “%2%”, etc. So why is that? Well in Word you can define up to 9 levels of list numberings, and %1 – %9 are enough for this representation. In LibreOffice, there are at least 10 levels, but even more ODF strives to be implementation-independent – so any hard limits here are anathema. Since format strings like “%10” are ambiguous (is it the “%1” placeholder with a “0” suffix, or is it the “%10” placeholder?) – the ODF specification uses the “%” delimiter on both sides of the placeholder.
Further improvements here include incorporating also style:num-format, to define numbering types for each level independently, in a way similar to the classical printf() format strings, in use with many programming languages.
The new num-list-format property is proposed for inclusion in ODF 1.4, but while this standard update slowly proceeds towards ratification, LibreOffice is meanwhile using its own namespace for it.
Work in this area is ongoing. Further efforts are needed:
Number portions generated when using lists/numberings/bullets in Writer now can have formatting which is preserved in ODT files as well.
First, thanks Docmosis for funding this work by Collabora.
Word and DOCX files support explicit character properties for the paragraph marker, and these are also used for the formatting of a number portion if the paragraph has one. This was already loaded from / saved to DOCX, but it was lost when saving to ODT.
First, we got a bug document, where the reference rendering and our rendering differed:

In this case, what happened was that part of the heading text was covered by a bookmark, so we first created multiple character ranges (outside the bookmark, inside the bookmark), then as an optimization we even unified them to be a single formatted character range, covering the entire paragraph. This was a document model that is different from the bookmark-free version, where the character formatting was set on the paragraph itself.
This was fixed at render time and at DOCX export time to consider both full-paragraph character ranges and in-paragraph character properties. For a while, this looked like the entire story, since this now looks good in Writer:

A bit later another, related bug was discovered. Given a reference document:

Just opening this DOCX file in Writer, it looked like this:

Note how the first number portion turned into bold! This was expected after the above layout change to consider full-paragraph formatted character ranges, but it also meant that Word can have one set of character formatting for the entire character range of a paragraph, and another for the paragraph marker.
To make the problem worse, this second document was showing that even the ODT export/export feature had problems, still:

The fix to solve all of the above was to undo the previous render / DOCX export change, then teach the ODT export to explicitly save the paragraph marker formatting (as an empty span at the end of the text node) to ODT, and also to load it back.
This means that now Writer can render the second document correctly, without breaking the first document:

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:
You can get a snapshot / demo of Collabora Office 22.05 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 (7.6).
by Popa Adrian Marius (noreply@blogger.com) at December 08, 2022 12:15 PM
Similar to the questionnaires about LibreOffice Draw (see first and second blog post) and LibreOffice Calc (see this post) we now run a survey on LibreOffice Impress to learn how the program is utilized, what features are used most frequently, and what users see as positive and negative and what they expect of the future.…
by caolan (noreply@blogger.com) at November 24, 2022 03:39 PM
Bruce Byfield and Jean Hollis Weber announce the second edition of Designing with LibreOffice. The book is available as an .ODT or .PDF file under the Creative Commons Attribution/Sharealike License version 4.0 or later from https://designingwithlibreoffice.com/
The first edition was published in 2016, and was downloaded over thirty-five thousand times. Michael Meeks, one of the co-founders of LibreOffice, described the first edition as “an outstanding contribution to help people bring the full power of LibreOffice into their document.” Similarly, free software author and journalist Carla Schroder wrote, “Designing With LibreOffice teaches everything you need to know about document production…. suitable for beginners to wizened old pros, who will probably discover things about LibreOffice that they didn’t know.”
The second edition updates the original, removing outdated information and adding updated screenshots and new information about topics such as Harfbuzz font shaping codes, export to EPUB formats for ereaders, the Zotero extension for bibliographies, and Angry Reviewer, a Grammarly-like extension for editing diction. In the future, the writers plan to release other editions as necessary to keep Designing with LibreOffice current.
For more information or interviews, contact Bruce Byfield at bbyfield@axion.net.