- Catch up with Caolan, 1:1's with Kendy & Cor, call with an old acquaintance, call with an interesting older ex-customer to get useful product feedback (much of it already implemented thankfully). Monthly management meeting.
This is a feed aggregator that collects what LibreOffice and Document Foundation contributors are writing in their respective blogs.
To have your blog added to this aggregator, please mail the website@global.libreoffice.org mailinglist or file a ticket in Redmine.
Two weeks ago, we started the Month of LibreOffice, giving thanks to all contributions across our projects. Everyone who takes part can claim a sticker pack – and at the end of the month, we’ll award some extra merchandise to ten lucky winners as well!
So, how’s it looking so far? Well, so far we’ve awarded 277 sticker packs! If you see your name (or username) on that page, check this blog when the month ends with details. And if you’re not there yet, read on to find out how you can join in…
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…
Sophie Gautier reports from the recent Open Source Experience event in Paris:
It’s been a long time since we had a LibreOffice booth at a live event, so we really appreciated having the opportunity to meet again in in early November! Jean-Michel Coste, Régis Perdreau, Christophe Cazin, Italo Vignoli and I were present at the booth to answer questions from visitors and companies from the ecosystem. A big thank you to the team for their presence!
Our discussions with other FLOSS associations were fruitful, and the ambiance in the FLOSS Village was full of joy and events (there was a quick where people could win books and even a scooter).
We look forward for the next OSXP in 2022!
Thanks to Sophie and the French-speaking community for taking part! And indeed, hopefully we’ll be able to meet at more in-person events early next year…
Word allows linking paragraph and character styles together, which means only the paragraph one will be present on the UI. Such a split has benefits if you customize the character properties on the UI and later you want to update the paragraph properties from a template, for example.
This is frequent markup in DOCX files, because Word defaults to splitting out the character
properties of a Test paragraph style into a Test Char character style on editing.
Saving the document in Writer and then viewing it in Word lead to loosing these links, so their
style pickers started to show unwanted Test Char rows.
We used to preserve such linking information when doing DOCX → DOCX conversion for a while, since about 2013. But such preservation was in-memory, so if you saved the document to ODT, then such information was lost. This approach also lacked a real document model, which is necessary to incrementally build this feature into a complete solution.
Here is how the style picker in Word looks like now, after a DOCX → ODT → DOCX pipeline:
Here is how this used to look like before the new changes (note the Heading 1 Char line between
Heading and Index):
And here is how the input document looks like:
If you would like to know a bit more about how this works, continue reading… :-)
sw: paragraph styles: add doc model & UNO API for a linked character style added the document model and API support
sw: paragraph styles: add DOCX filter for a linked character style added the DOCX filter
sw: paragraph styles: add ODT filter for a linked character style added the ODT filter
Just to set expectations, this is currently an invisible feature, but unlike the old approach from 8 years ago, this one can be extended into a full feature, incrementally. It also survives ODT roundtrips.
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 (7.3).
LibreOffice 7.3 will be released as final at the beginning of February, 2022 ( Check the Release Plan ) being LibreOffice 7.3 Alpha1 the first pre-release since the development of version 7.3 started in mid June, 2021. Since then, 4764 commits have been submitted to the code repository and more than 760 bugs were set to FIXED in Bugzilla. Check the release notes to find the new features included in this version of LibreOffice.
LibreOffice 7.3 Alpha1 can be downloaded from here 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 Telegram.
LibreOffice is a volunteer-driven community project, so please help us to test – we appreciate it!
Happy testing!!
…
Software-Update: CIB und die allotropia software haben die Produktpalette LibreOffice powered by CIB auf die Version 6.4 LTS aktualisiert. Dieses Update enthält eine komplette Desktop-Produktivitätslösung für Unternehmen und Organisationen jeder Größe, die LibreOffice in einer stabilen Umgebung einsetzen können – Support inklusive. Die Produktpalette von LibreOffice powered by CIB umfasst: 1. LibreOffice powered by CIB … LibreOffice powered by CIB: jetzt mit aktualisierten LTS-Versionen weiterlesen
Der Beitrag LibreOffice powered by CIB: jetzt mit aktualisierten LTS-Versionen erschien zuerst auf CIB Blog.
Have you ever edited a document in LibreOffice in more than one window? Right, neither have I. Who'd think about LibreOffice and more than one user at the same time, right? Except ... somebody did and that's how collaborative editing based on LibreOffice works. For whatever strange reason, somewhen in the past somebody thought that implementing multiple views for one document in OpenOffice (StarOffice?) was a good idea. Just select Window->New Window in the menu and you can edit your favourite document in 50 views that each show a different part of the document and update in real time. And that, in fact, is how collaborative editing such as with Collabora Online works - open a document, create a new view for every user, and there you go.
But, given that this has never really been used that much, how well did the original relevant code perform and scale for more users? Well, not much, it turns out. Not a big surprise, considering that presumably back when that code was written nobody thought the same document could be edited by numerous users at the same time. But I've been looking exactly into this recently as part of optimizing Collabora Online performance, and boy, are there were gems in there. You thought that showing the same document in more views would just mean more painting also in those views? Nah, think again, this is OpenOffice code, the land of programming wonders.
When running Online's perf-test, which simulates several users typing in the same document, most of the time is actually spent in SwEditShell::EndAllAction(). It's called whenever Writer finishes an action such as adding another typed characters, and one of the things it does is telling other views about the change. So here LO spends a little time adding the character and then the rest of the time is spent in various code parts "talking" about it. A good part of that is that whenever an action is finished, that view tells the others about it happening, and then all those views tell all other views about how they reacted to it, making every change O(n^2) with the number of views. That normally does not matter, since on the desktop n generally tends to be 1, but hey, add few more views, and it can be a magnitude slower or more.
Redrawing, for example, is rather peculiar. When a part of the document changes, relevant areas of the view need redrawing. So all views get told about the rectangles that need repainting. In the desktop case those can be cropped by the window area, but for tiled rendering used by Online the entire document is the "window" area, so every view gets told about every change. And each view collects such rectangles, and later on it processes them and tells all other views about the changes. Yes, again. And it seems that in rare cases each view really needs its own repaint …
We got a PPTX document, which has a table shape with pink background and a blurry shadow. Impress rendered a red background, making the text hard to read.
The request was to improve the shadow rendering to be PowerPoint-compatible and in general correctly support transparency when it comes to table cell fills and table shadows.
The table shadow now looks like this:
Matching the reference rendering:
While background was red previously:
You can see that not only the background in the top center cell is pink now, but the blurry table shadow is still correct.
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 fixes:
With these, it’s now possible to add transparency to both table cell fills and to table shadows, and the rendering will take both into account, correctly.
You can get a snapshot / demo of Collabora Office and try it out yourself right now: try 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.3).
Marina Latini, en nombre del Comité de Membresía, escribe:
El 18 de octubre anunciamos oficialmente las próximas elecciones para la próxima Junta Directiva de The Document Foundation, la entidad sin ánimo de lucro que está detrás de LibreOffice.…
Earlier this year we run a survey on LibreOffice Calc. It was inspired by a similar questionnaire for LibreOffice Draw (see first and second blog post). The Calc survey was used to learn about how Calc is being used, what features are most important to users and where they expect to see the improvements to the software.…
In programming, we usually face bugs that we should fix to maintain or improve our software. In order to fix a bug, first we should find the source of the problem, and there are tools like “Automated bibisect” are available to help, specially when the bug is a regression. You probably know what a regression is:
Regression bugs are special kinds of bugs. They describe a feature that was previously working well, but at some point a change in the code has caused it to stop working. They are source of disappointment for the user, but they are easier to fix for the developers compared to other bugs! Why? Because every single change to the LibreOffice code is kept in the source code management system (Git), it is possible to find that which change actually introduced the bug.
But, how to find where (in which commit) the bug has actually introduced? The answer is provided by the Git; the source code management system that most of us use, and is used in LibreOffice development. Git provides a command named bisect.
Using git bisect, you can find the exact commit where the bug was introduced with the minimum number of tries possible using binary search. After invoking git bisect start, you should mark the last bad commit you know using git bisect good, and then the first bad commit you know using git bisect bad. Then you are told what is the number of estimated steps you need to go. You should compile each commit that is checked out, and then test to see if the problem is there.
But wait! Isn’t it true that compiling LibreOffice takes a while? Is git bisect for LibreOffice is something usable, in a short period time? The answer is no, but there is a solution called binary bisect or bibisect. Binary builds of all commits within certain periods of time are available as git repositories, and you can do git bisect on these repositories.
You can read more about bibisect here:
https://wiki.documentfoundation.org/QA/Bibisect
First, you have to find a suitable repository. If the bug is reproducible on every platform, you can choose among the repositories according to your OS:
For example, consider tdf#141049. It is about bad rendering of an EMF figure, which is wrongly displayed as blank. It was OK in LibreOffice 6.2, but in newer versions of LibreOffice 6.2, the problem appeared. So, if you are working on Linux, bibisect-linux-64-6.3 would be the right choice, because it provides “libreoffice-6-2-branch-point to libreoffice-6-3-branch-point and then libreoffice-6-3”.
(GOOD)
(BAD)
Figure 1: The good, and the bad!
We start by downloading the repository bundle from TDF repo: (Warning: The bundle is ~8GB, and you need more space to extract and work with it)
$ wget --continue https://bibisect.libreoffice.org/linux-64-6.3.git-bundle
$ git clone -o bundle …
If you use Windows 7 and LibreOffice 7.1 doesn't start there, then possibly you have Windows 7 without update. For fixing that issue please install Windows 7 update as it wrote in LibreOffice 7.1 Release Note:
Because of updated Python's change bpo-36085, LibreOffice now requires KB2533623 on Windows 7. The mentioned update is not directly available from Microsoft anymore, but KB3063858 (32-bit / 64-bit) may be used, that superseded the older one (details in tdf#144902).
Please accept YouTube cookies to play this 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.
Presentation: Getting Started with LibreOffice Development – Hossein Nourikhah
This talk was recorded presented in the LibreOffice Conference 2021 (LibOCon 2021) Slides
LibreOffice Conference 2021
This is the first post of the LibreOffice Development Blog!
To know more about what is going on in LibreOffice, you can refer to the main Document Foundation blog. Also, if you want to learn more about the LibreOffice design, you can refer to the LibreOffice Design Team blog. And now, we have created a new blog, dedicated to the LibreOffice development!
Here is a good place to get more information about ongoing development efforts. Alongside the Document Foundation Wiki and #libreoffice-dev IRC, we will provide development related information here. We will talk about LibreOffice internals, and modules, how to fix bugs, write tests, and many other things! If you want to start LibreOffice development, this is a good place familiarize yourself with LibreOffice code, tools and developers.
Do you know C++, Java, Python, SQL, or other programming languages? If so, you can find useful information about the latest development related news and other up-to-date information here. Although we emphasize using these programming languages, you may find some areas that you can help and contribute, even without being an expert in programming.
LibreOffice core, a mix of many modules used in LibreOffice development
We will focus on LibreOffice core development, which contains many modules that are listed in LibreOffice modules documentation. LibreOffice applications like Writer, Calc, Impress, Draw, Math and Base that any user interact with will be part of our focus. Additionally, there are modules like VCL (UI toolkit for LibreOffice) that normal users may not fully understand. As a developer, you should know a lot about the LibreOffice internals, so we will discuss these modules.
Additionally, we will also talk about git, Gerrit, Jenkins, Bugzilla, compilers, IDEs and many other tools and techniques.
Above all, you can improve your development skills here, so stay tuned for interesting contents soon. We hope to see your name in the list of LibreOffice developers, here!
On macOS (but not on Windows or Linux), in versions 7.1.x and 7.2.x of LibreOffice, a bug in Base causes the Memo (LONGVARCHAR) field type to have a dark background, so the contents are not visible. Other field type [date, number, TEXT (VARCHAR), and so on] have a normal white background. When clicked, the black fields turn white and I can type into them, but when I click or Tab to another field, they return to black. When I use a form to enter data, the form fields are normal, but the results in the database itself have the black field background. The database otherwise works as it should.
This behaviour has been reported as Bug 140854. The workaround is to use an older version of LibreOffice, such as 7.0.x, where the bug does not occur. You can find a link to version 7.0.6 near the bottom of the download page.
Fortunately, it is easy to install more than one version of LibreOffice on macOS, so you don’t have to completely give up the latest version if you want to use it for other components. Simply rename the existing version to something else; I usually change “LibreOffice” to “LibreOffice721” or similar. Then install a second version as usual by double-clicking the downloaded DMG file. Both versions will share the same user profile, so it’s easy to switch among them. Note: You can set up separate user profiles (for example, for testing purposes), but that’s beyond the scope of this article; see this wiki page if you want to go there.
A paragraph might have an associated list in Writer and that list can have multiple levels. This is direct formatting. When it comes to paragraph styles, referring to a list was already possible, but defining a custom list level was not.
Loosing this information in Word documents was quite annoying, and it turned out that ODF also has markup for this, just LibreOffice didn’t implement it.
This work is currently done for the document model, scripting API and file filters: style previews & UI still needs finishing.
Writer can at the moment preserve list level info from ODT and DOCX files. Here is how a file written by Writer looks like in Word:
You can see that the style preview in Word takes the list level into account. Doing the same and applying the list level as part of applying the paragraph style on the Writer UI is still future work.
Thanks to Justin Luth who did the follow-up work to adapt the DOC filter accordingly, and also doing other related fixes.
If you would like to know a bit more about how this works, continue reading… :-)
tdf#137363 DOCX filter: don’t loose <w:ilvl w:val="…"> of paragraph styles added document model, API and DOCX import/export support
Related: tdf#137363 ODT import: handle style:list-level="…" for para styles added ODT import/export support
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 (7.3).
El 28 de septiembre de 2010 LibreOffice fue anunciado al mundo. Luego de 11 años, el proyecto y su comunidad global se encuentran entre los más grandes del ecosistema FLOSS, y LibreOffice Technology marca el camino del desarrollo para la …
Eleven years ago, on 28 September 2010, a new chapter in the history of free office suites started: the creation of the LibreOffice project and the start of The Document Foundation as independent entity. Thanks truly to everyone who made this amazing journey possible. <3 Happy birthday!
(In 2016, I wrote some personal thoughts about this in German.)
La aplicación móvil con la programación de la Conferencia LibreOffice 2021 está disponible en Google Play y F-Droid. Desde la página de F-Droid también es posible descargar el APK, aunque al instalarlo así no se recibirán notificaciones de …
Earlier this year, allotropia software GmbH was awarded a tender to fix a number of problems around the master document feature (Tender to implement master document fixes (#202106-02)) by The Document Foundation (TDF).
We have finished implementing the necessary changes, and all fixes will be available for testing in LibreOffice 7.2.2.
Using master documents is a somewhat hidden, but extremely useful feature of LibreOffice Writer, when producing longer documents (like books, or the help guides the LibreOffice documentation team is maintaining). With it, users can split a larger document into a number of smaller pieces, to work on independently. If this feature sounds interesting to you, the excellent Writer Guide has a chapter about it.
We’ve worked on the following bug reports:
It turned out that the problem here was that one of the confusingly many flags that determine whether a document section is hidden was copied erroneously to a different one of these flags when copying a child section of a hidden parent section. We have removed the offending line of code, improved the in-line documentation of these flags in the class declaration, found 2 more places in the code that appeared to check the wrong hidden flag, and added a unit test (so any further changes in this area cannot break this feature again):
https://git.libreoffice.org/core/commit/91b0024965908c692bea40f47c58ea9d1bf8a596
Here the problem was that the function that splits the source document into multiple chapter document forgot to copy bookmarks out of the source document. So we took an ambitious approach and changed the function to call CopyWithFlyInFly() instead, which is the same function that is used during copying to the clipboard – and that one happens to copy bookmarks as well, among other things. We also added a unit test:
https://git.libreoffice.org/core/commit/3608de9a3647294361c64b923b1ae413ad9755df
This fixed retaining references to ordinary bookmarks, but then it turned out that the selection from which the chapter documents are copied hits a corner case in the bookmark copying code for the heading cross-reference bookmarks. This is because their position is exactly at the start of the selection, so they were not copied. So we figured out how to handle this tricky corner case so that the cross-reference bookmarks are copied:
https://git.libreoffice.org/core/commit/4bf04dea9afb30a9395e80b07a81d1908937ee8b
Bug 128106 before: screenshot with broken references
Bug 128106 fixed: screenshot with working referencesUnfortunately we were unable to reproduce this bug anymore. Fortunately it turned out that another developer had meanwhile already fixed it (thanks, Sweetshark). We resigned ourselves to at least adding a non-trivial unit test for the bug, which uses VCL’s PDF import features to read the outline of the exported PDF file:
https://git.libreoffice.org/core/commit/c591008a27be24f5d9ba27f9b9acceecc610f9a2
We would like to thank The Document Foundation, and their countless …
Earlier this year, allotropia software GmbH was awarded the Tender to finish transition of LibreOffice to ODF 1.3 (ODF 1.3 delta) (#202010-01) by The Document Foundation (TDF).
The implementation is now finished, has received quite a bit of polishing and testing, and is available for production use in the LibreOffice 7.2 release.
While ODF 1.3 support is widely available across the LibreOffice ecosystem since the beginning of this year, there was a number of improvements now possible, after the ODF TC cleaned up and improved the standard.
We have implemented the following features:
Writer showing various indexes, and the mouse-over tooltip for a hyperlink to a document index entry mark
Writer showing pages with BackgroundFullSize on and offPreviously, the situation in Writer was that some types of background were always covering the entire page, others only within the margins, which required some work on the ODF import for compatibility with existing files (https://git.libreoffice.org/core/commit/e9c6fd6b4d09ee59b6a86942cbf001f2ba9782e6).
Impress dialog showing new “Background covers margins” checkboxSince this feature adds a new checkbox on a dialog, we also added some UITests (https://git.libreoffice.org/core/commit/8a859cdecdd49e186b95a051ee31756770d50e9c).
Before: No data labels
After: Data Labels visibleWith this feature, you can now show the data series name in the chart on each data label, which makes reading a chart easier and also improves interoperability with Microsoft Excel (https://git.libreoffice.org/core/commit/b99f310d3b24dc45e3d84751e810c0bbff1d991b).
LibreOffice Calc 7.2 showing the trend line dialogue and a moving average of type “Averaged Abscissa”. It is now possible to choose from three types: Prior (the default), Central, and Averaged Abscissa.This allows to calculate the trend line with different algorithms, and gives more flexibility to the chart creator (https://git.libreoffice.org/core/commit/4141533a3fb984fbaefe87b15fceeda7f2082061) (https://git.libreoffice.org/core/commit/a9b71098845edcb4f6b4629795168d174f28ef70).
As a bonus, this enabled us to fix a very long-standing bug of the text frame/shape duality in Writer not maintaining its invariants (https://git …
 |
| Figure 1: Search "proof of concept" web application |
 |
| Figure 2: Search "proof of concept" web application … |
The latest user guide from the LibreOffice documentation team is Getting Started with LibreOffice 7.2, available in free PDF, ODT, or to read in a browser. Visit the Documentation page on the LibreOffice website for links.
Low-cost printed copies are available from Lulu.com.
Por Italo Vignoli
La accesibilidad, o el acceso universal, es una pieza clave para el carácter integrador de la transformación digital, pero no muchas personas están capacitadas para hablar al respecto. En aras de conocer más sobre esta materia, hemos …
The OutputDevice class is what we use for rendering a whole host of different things, and other classes inherit from it to do their rendering. Notably a little while ago Noel Grandin separated OutputDevice from Window, which is a huge boon for the codebase!
In an attempt to further separate the concerns of OutputDevice, I noticed a long time ago that not only does it do rendering, but it records actions in a metafile. These are two related and yet quite separate things. My goal is to shift out the rendering into a RenderContext class. I have already got a PoC on GitHub, which has already done much of the work, albeit in a messier way (basically it was a test to see if this was even feasible).
Obviously migrating rendering functionality into its own class is not something to take lightly, so I have been writing smaller patches that test out the code. When I say "small", I really mean this. Currently I am testing out a bunch of code that sets state in OutputDevice, which can be found in the outdevstate topic branch in gerrit.
Along with test the state functions of OutputDevice, I am also adding some tests to the bitmap functionality of OutputDevice. I recently landed a patch to move GetDownsampledBitmap() out of OutputDevice and into BitmapTools.cxx because it really didn't need to completely rely on OutputDevice. This bit of code will hopefully one day migrate it's way into the VCL backend modules. You can monitor the progress I'm making via the bitmap topic branch in gerrit.
I have to say that writing tests is not always easy. Often there is no easy way of accessing the functions, especially if they are private, but luckily most of the functions are protected so I can at least write a mock class to expose these functions without having to modify the code.
Currently I have the following topic branches:
| Imprint Privacy Policy | |
|
The Document Foundation is not responsible for the content on planet.documentfoundation.org. However - if you have any concerns about content please contact act Uwe Altmann for moderation. Copyright information: Unless otherwise specified in the author's blog, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the "Mozilla Public License v2.0". "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy. |
 |
| this site runs a modified version of planet.opensuse (https://github.com/openSUSE/planet.opensuse.org) © 2010 Pascal Bleser and the openSUSE Community. | |