One of the most popular syslog-ng destinations is Elasticsearch. Humio, a log management provider, supports a broad range of ingest options and interfaces, including an Elasticsearch-compatible API. Last week, Humio announced Humio Community Edition, which provides the full Humio experience for free, with some limitations on daily ingestion and retention time. I tested the Community Edition, and it works perfectly well with syslog-ng.

If you come from the Humio side, you might wonder what syslog-ng is. It is an application for high performance central log collection. Traditionally, syslog messages were collected centrally and saved to text files. Nowadays, syslog-ng acts more like a log management layer: collects log messages from hosts, saves them for long term storage, but also forwards them to multiple destinations, like SIEMs and other log analysis solutions. This way, it is enough to collect log messages only once, and syslog-ng delivers the right log messages to the right destinations in the right format, after some initial processing.

Humio is available as a cloud service or self-hosted, where you can send all your logs for storage and analysis. It has an easy-to-use interface to query log messages which can be extended with further analytics possibilities from the Humio marketplace.

From this blog, you can learn how to get started with Humio and syslog-ng. While Humio provides many other APIs for log ingestion, I focus on the elasticsearch-http() destination of syslog-ng, demonstrating that there is no vendor lock-in: the same driver works equally well for Elastic’s Elasticsearch, AWS’s OpenSearch and for Humio.

Read more at https://www.syslog-ng.com/community/b/blog/posts/sending-logs-to-humio-using-the-elasticsearch-http-destination-of-syslog-ng

October is being a busy month for the YaST Team. We have fixed quite some bugs and implemented several features. As usual, we want to offer our beloved readers a summary with the most interesting stuff from the lastest couple of development sprints, including:

• Improved handling of users on already installed systems
• Progress in the refactoring of software management
• Better selection of the disk in which to install the operating system
• More robust handling of LUKS encrypted devices
• Fixes for libYUI in some rare cases
• Improvements in time zone management (affecting mainly China)

Improved Handling of Users

Let us start by quoting our latest report: “regarding the management of users, we hope to report big improvements in the next blog post”. Time has indeed come and we can now announce we brought the revamped users management described in this monographic blog post to the last parts of YaST that were still not taking advantage of the new approach. The changes are receiving an extra round of testing with the help of the Quality Assurance team at SUSE before we submit them to openSUSE Tumbleweed. When that happens, both the interactive YaST module to manage users and groups and its corresponding command line interface (not to be confused with the ncurses-powered text mode) will start using useradd and friends to manage users, groups and the related configurations.

There should not be big changes in the behavior apart from the improvements already mentioned in the original blog post presenting the overall idea. But a couple of fields were removed from the UI to reflect the current status:

• The password for groups, which is an archaic and discouraged mechanism that nobody should be using in the era of sudo and other modern solutions.
• The fields “Secondary Groups” and “Skeleton Directory” from the tab “Default for New Users”, since those settings are either gone or not directly configurable in recent versions of useradd.

There is still a lot of room for improvements in YaST Users, but we will postpone those to focus on other areas of YaST that need a similar revamping to the one done in users management.

Refactoring Software Management

One of those areas that need a bit of love and would benefit from some internal restructuring is the management of software, which goes much further than just installing and removing packages. We have just started with such a refactoring and we don’t know yet how far we will get on this round, but you can already read about some of the things we are doing in the description of this pull request, although it only shows a very small fraction of the full picture.

New Features in the Storage Area

We also improved the way YaST handles some storage technologies. First of all, we instructed YaST about the existence of BOSS (Boot Optimized Storage Solution) drives in some Dell systems. From now on, such devices will be automatically chosen as the first option to install the operating system, as described in this pull request with screenshots. As a bonus for that same set of changes, YaST will be more sensible regarding SD Cards.

On the other hand, we adapted the way YaST (or libstorage-ng to be fully precise) references LUKS devices in the fstab file to make it easier for systemd to handle some situations. Check the details in this other pull request (sorry, no screenshots this time).

Fixes for libYUI

As usually revealed by our posts, YaST is full of relatively unknown features that were developed to cover quite exceptional use-cases. Those characteristics remain there, used by a few users… and waiting for a chance to attack us! During the recent sprints we fixed the behavior of libYUI (the toolkit powering the YaST user interface) in a couple of rare scenarios. Check the descriptions of this pull request and this other one for more details.

Fun with Flags… err Time Zones

For reasons everybody knows, being able to work from home and to coordinate information with people from different geographical locations has become critical lately. That scenario has increased the relevance of properly configured time zones in the operating system. And that made us realize the time zones handled by YaST for China weren’t fully aligned with international standards. This pull request explains what was the problem and how we fixed it, so applications like MS Teams can work on top of (open)SUSE distributions just fine… everywhere in the globe.

That’s All… Until we Meet Again

As you know, YaST development never stops. And, although we only report the most interesting bits in our blog posts, we keep working in many areas… from very visible features and bug fixes to more internal refactoring. In any case, we promise to keep working and to keep you updated in future blog posts. So stay tuned and have a lot of fun!

You can see five segments:

• The center (5,5) is the "worker" who has a set of balanced of attributes, no extremes. These team members are extremely important because they tend to just get stuff done.
• The top left (9,1) is the "expert" who is focused on the task and its details but doesn't consider people that much. You need these to get the depth of work which is necessary to create great results.
• The bottom right (1,9) is the "facilitator" who is something like the soul of the team, focused on social interactions and supports the team in creating great results.
• The top right (9,9) is the "leader" who is strong on task and people and is giving direction to the team. You need these but you don't want to have more than one or two in a team otherwise there are conflicts of leadership.
• The bottom left (1,1) is the "submarine" who floats along and tries to stay invisible. Not strong on any account. You don't want these in your team.

The test can provide some insight into the balance of the team. You want to have all but the submarine covered with an emphasis on the workers.

How does your team look like on this diagram?

In the past months I’ve set up LDAP at home, to avoid having different user accounts for the services that I run on my home hardware. Rather than the venerable OpenLDAP I settled for 389 Directory Server, commercially known as Red Hat Directory Server, mainly because I was more familiar with it. Rather than describing how to set that up (Red Hat’s own documentation is excellent on that regard), this post will focus on the steps required to enable encryption using Let’s Encrypt certificates.

The problem

Even the LDAP server (they’re actually two, but for the purpose of this post it does not matter) was just operating in my LAN, I wanted to reduce the amount of information going around in clear, including LDAP queries. That meant setting up encryption, of course.

The problem was that Red Hat’s docs only cover the “traditional” way of obtaining certificates, that is obtaining a Certificate Authority (CA) certificate, request a server certificate, obtain it and set it up in the server. There is (obviously) no mention of Let’s Encrypt anywhere. I’ve found some guides, but they were either too complicated (lots of fuzzing around with certutil) or they weren’t clear for some steps. Hence, this post.

NOTE: I’ve focused on 389-ds version 2.0 and above, which has a different CLI set of commands than the venerable 1.3 series. All of the steps shown here can also be carried out via the Cockpit Web interface as well, if your distribution carries it (spoiler: openSUSE doesn’t).

Importing the CA

This is arguably one of the most important steps of the process. 389-ds needs also to store the CA for your certificates. As you may (or may not) know, Let’s Encrypt’s CA certificates are two:

• The actual “root” certificate, by Internet Security Research Group (ISRG);
• An intermediate certificate, signed by the above root, called “R3”.

Let’s Encrypt certificates, like the one powering this website, are signed by R3. But since you have to follow a “chain of trust”, to validate the certificate you follow these steps (excuse me, security people; this is probably a bad semplification):

1. Check the actual certificate (e.g. the one on dennogumi.org)
2. The certificate is signed by “R3”, so move up the chain and check the R3 certificate
3. The R3 certificate is signed by the ISRG root certificate, so move up the chain and check the ISRG root
4. The ISRG certificate is trusted by the OS / application using it, so everything stops there.

If any of the steps fails, the whole validation fails.

This long winding explanation is to tell you that 389-ds needs the whole certificate chain for its CA (so ISRG root + R3) in order to properly validate the Let’s Encrypt certificate you’ll use. If you don’t do that, chances are that some software which uses the system CA will work (for example ldapsearch) but others, like SSSD will fail with “Unknown CA” errors (buried deep into debug logs, so at the practical level they’ll just fail and you won’t know why).

Let’s get to business. Access the Chain of Trust page for Let’s Encrypt and download the relevant certificates. I’m not sure if 389-ds supports ECDSA certificates, so I downloaded the RSA ones: ISRG Root X1 and Let’s Encrypt R3 (both in PEM format). Put them somewhere in your server. Then, as root, import the two CA certificates into 389-ds (substitute LDAP_ADDRESS with the LDAP URI of your server):

# ISRG Root

dsconf -v -D "cn=Directory Manager"  LDAP_ADDRESS security ca-certificate \
    add --file /path/to/certificate --name "ISRG"

# Let's Encrypt R3

dsconf -v -D "cn=Directory Manager"  LDAP_ADDRESS security ca-certificate \
    add --file /path/to/certificate --name "R3"

NOTE: This step may not be necessary if you use Let’s Encrypt’s “full chain” certificates, but I did not test that.

Importing the certificates

Then, you have to import a Let’s Encrypt certificate, which means you have to obtain one. There are hundreds of guides and clients that can do the job nicely, so I won’t cover that part. If you use certbot, Let’s Encrypt’s official client, you will have the certificate and the private key for it in /etc/letsencrypt/live/YOURDOMAIN/fullchain.pem and /etc/letsencrypt/live/YOURDOMAIN/privkey.pem.

You need to import the private key first (substitute LDAP_ADDRESS and DOMAIN with the LDAP URI of your server and the Let’s Encrypt domain, respectively):

dsctl LDAP_ADDRESS tls import-server-key-cert \
    /etc/letsencrypt/live/DOMAIN/fullchain.pem \
        /etc/letsencrypt/live/DOMAIN/privkey.pem

Note that you pass the certificate as well as the key to import it (in doubt, check’s Red Hat documentation).

Once the key is done, it is time to import the actual certificate:

dsconf -v -D "cn=Directory Manager" LDAP_ADDRESS security certificate add \
    --file /etc/letsencrypt/live/DOMAIN/fullchain.pem \
        --primary-cert \
        --name "LE"

--primary-cert sets the certificate as the server’s primary certificate.

Then, we switch on TLS in the server:

dsconf -v -D "cn=Directory Manager" LDAP_ADDRESS config replace \
	nsslapd-securePort=636 nsslapd-security=on

And finally, we restart our instance (replace INSTANCE with your configured instance name):

systemctl restart dirsrv@INSTANCE

Testing everything out

You can use ldapsearch to check whether the SSL connection is OK (I’ve used Directory Manager, but you can use any user you want):

# STARTTLS

ldapsearch -H ldap://your.ldap.hostname -W -x -D "cn=Directory Manager" -ZZ "search filter here"

# TLS

ldapsearch -H ldaps://your.ldap.hostname -W -x -D "cn=Directory Manager" "search filter here"

If everything is OK, you should get a result: otherwise, you’ll get an error like “Can’t contact the LDAP server”.

Alternatively, you can use openssl:

openssl s_client -connect your.ldap.hostname:636
[...]
---
SSL handshake has read 5188 bytes and written 438 bytes
Verification: OK

Don’t forget to adjust your applications to connect via ldaps rather than ldap after everything is done.

Renewing the certificates

To renew the certificates you repeat the steps outlined above for the certificates (without the CA part, of course). Make sure you always import your private key: if there is a mismatch between it and the certificate, 389-ds will refuse to start.

If you use certbot you can use a post-renewal hook to trigger the import of the certificate into 389-ds. This is what I’ve been using: bear in mind it’s customized to my setup and does a few more things than needed. Also it does only import the certificate, and not the full chain.

I messed up and 389-ds won’t start! What do I do?

You can disable encryption by editing /etc/dirsrv/slapd-INSTANCE/dse.ldif and changing nsslapd-security to off, then start 389-ds again. Then you can review everything and see what went wrong. But if you can, I recommend the Cockpit Web UI: it makes the first-time setup a breeze.

Wrap up

Importing the certificates is surprisingly simple, but my Internet searches have been frustrating because at least half of what I found was either not applicable, incomplete, or did not work. I hope this small tutorial can be useful for those who want a bit more security in their LDAP setup.

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.

Profiling the code

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 changes (even besides the cropping, as said before). So there's a lot of repeated processing of usually the same rectangles over and over again.

One of the functions prominently taking place in CPU costs is SwRegionRects::Compress(), which ironically is supposed to make things faster by compressing a group of rectangles into a smaller set of rectangles. I guess one of the cases in OpenOffice where the developer theoretically heard about optimizations being supposed to make things faster, but somehow the practical side of things just wasn't there. What happens here is that the function compares each rectangle with each other, checking if they can be merged ... and then, if yes and that changes the set of rectangles, it restarts the entire operation. Which easily makes the entire thing O(n^3). I have not actually found out why the restarting is there. I could eventually think of a rather rare case where restarting makes it possible to compress the rectangles more, but another possibility is that the code dates back to the time when it was not safe to continue after modifying whichever container SwRegionRects was using back then, and it has stayed there even though that class has been using to std::vector since a long time ago.

Another kind of interesting take on things is the SwRegionRects::operator-= in there. Would you expect that rectangles would be collected by simply, well, collecting them and then merging them together? Maybe you would, but that's not how it's done here. See, somebody apparently thought that it'd be better to use the whole area, and then remove rectangles to paint from it, and then at the end invert the whole thing. The document area is limited, so maybe this was done to "easily" crop everything by the area? It works, except, of course, this is way slower. Just not slow enough to really notice when n is 1.

Other code that works fine with small numbers but fails badly with larger ones is VCLEventListeners, a class for getting notified about changes to VCL objects such as windows. It's simply a list of listener objects, and normally there aren't that many of those. But if LO core gets overloaded, this may grow. And since each listener may remove itself from the list at any point, the loop calling all of them always checks for each of them if the listener is still in the list. So, again, O(n^2). And, of course, it's only rarely that any listener removes itself, so the code spends a lot of time doing checks just in case.

But so that I do not talk only about old code, new code can do equally interesting things. Remote rendering uses LOK (LibreOfficeKit), which uses text-based messages to send notifications about changes. And the intuitive choice for writing text are C++ iostreams, which are flexible, and slow. So there will be a lot of time spent in creating text messages, because as said above, there are many changes happening, repeatedly. And since there are so many repeated messages, it makes sense to write extra class CallbackFlushHandler that collects these messages and drops duplicates. Except ... for many of the checks it first needs to decode text mesages back to binary data, using C++ iostreams. And in most cases, it will find out that it can drop some message duplicates, so all these string conversions were done for nothing. Oops.

And there are more ways in which things can get slower rather than faster. CallbackFlushHandler uses an idle timer to first process all data in bulk and flush the data at once only when idle. Except if it gets too busy to keep up, and it can easily get too busy because of all the things pointed out above, it may take a very long time before any data is flushed. To make things even worse, the queue of collected messages will be getting longer and longer, which means searching for duplicates and compressing it will get longer. Which in turn will make everything even slower, which again in turn will make everything even slower. Bummer.

All in all, if unlucky, it may not take that much for everything to slow down very noticeably. Online's perf-test, which simulates only 6 users typing, can easily choke itself for a long time. Admitedly, it simulates them all typing at the same time and rather fast, which is not very a realistic scenario, but typing hitting the keyboard randomly and quickly is exactly how we all test things, right? So I guess it could be said that Collabora Online's perf-test simulates users testing Collabora Online performance :). Realistic scenarios are not going to be this bad.

Anyway. In this YT video you can see in the top part how perf-test performs without any optimizations. The other 5 simulated users are typing elsewhere in the document, so it's not visible, but it affects performance.

Improved performance

But as you can see in the other two parts, this poor performance is actually already a thing of the past. The middle part shows how big a difference can even one change make. In this specific case, the only difference is adding an extra high-priority timer to CallbackFlushHandler, which tries to flush the message queue before it becomes too big.

The bottom part is all the improvements combined, some of them already in git, some of them I'm still cleaning up. That includes changes like:

• SwRegionRects::Compress() is now roughly somewhere at O(n*log(n)) I think. I've fixed the pointless restarts on any change, and implemented further optimizations such as Noel's idea to first sort the rectangles and not compare ones that cannot possibly overlap.
• I have also changed the doubly-inverted paint rectangles handling to simply collecting them, cropping them at the end and compressing them.
• One of the things I noticed when views collect their paint rectangles is that often they are adjacent and together form one large rectangle. So I have added a rather simple optimization of detecting this case and simply growing the previous rectangle.
• Since it seems each Writer view really needs to collect its own paint rectangles, I have at least changed it so that they do not keep telling each other about them all the time in LOK mode. Now they collect them, and only once at end they are all combined together and compressed, and often thousands of rectangles become just tens of them.
• Another thing Writer views like to announce all the time in LOK mode are cursor and selection positions. Now they just set a flag and compute and send the data only once at the end if needed.
  
• VCLEventListeners now performs checks only if it knows that a listener has actually removed itself. Which it knows, because it manages the list.
  
• Even though LOK now uses tiled rendering to send the view contents to clients, LO core was still rendering also to windows, even though those windows are never shown. That's now avoided by ignoring window invalidations in LOK mode.
• Noel has written a JSON writer which is faster then the Boost one, and made non-JSON parts use our OString, which is faster and better suited for the fixed-format messages.
  
• I have converted the from-message conversions to also use our strings, but more importantly I have changed internal LOK communications to be binary rather than text based, so that they usually do not even have to be converted. Only at the end those relatively few non-duplicated text messages are created.
• Noel has optimized some queue handling in CallbackFlushHandler and then I have optimized it some more. Including the high-priority timer mentioned above.
• There have been various other improvements from others from Collabora as part of the recent focus on improving performance.
  
• While working on all of this, I noticed that even though we have support for Link Time Optimization (LTO), we do not use it, probably because it was broken on Windows. I've fixed this and sorted out few other small problems, and releases in the future should get a couple percent better performance across the board from this.
  

This is still work in progress, but it already looks much better, as now most of the time is actually spent doing useful things like doing the actual document changes or drawing and sending document tiles to clients. LOK and Collabora Online performance should improve noticeably, recent (Collabora) versions 6.4.x should include already some improvements, and the upcoming Collabora Online 2021 should have all of them.

And even though this's been an exercise in profiling LibreOffice performance for something nobody thought of back when the original OpenOffice code was written, some of these changes should matter even for desktop LibreOffice and will be included starting with LO 7.3.

Dear Tumbleweed users and hackers,

This week has been overshadowed a lot with Snapshots that did not pass openQA – in total, we have had 6 snapshots in QA – of which only 2 made it through and have been published. Of course, all the issues identified have resulted in relevant bug reports which the maintainers will be working on, fixing, resubmitting the packages that needed to be reverted, and then we move forward. After all, openQA does exactly what we want it to do: it protects you, the users, from getting broken snapshots.

So, as said, we published two snapshots (1016 and 1019), containing those updates:

• KDE Gear 21.08.2
• KDE Plasma 5.23.0
• KDE Frameworks 5.87.0
• Apparmor profile update for Samba printing subsystem
• Gimp 2.10.28
• Linux kernel 5.14.11 (5.14.12 was responsible for one of the snapshots being blocked)
• Mesa 21.2.4

The staging projects are currently filled with:

• KDE Plasma 5.23.1
• Systemd 249.5
• Linux kernel 5.14.14
• Bison 3.8.2: breaks gdb
• RPM 4.17: one fix for suse-hpc missing (Fix submitted to devel prj)
• Coreutils 9.0
• gpg 2.3.x: some openQA issues detected, https://progress.opensuse.org/issues/101358
• openSSL 3.0.0: no active progress

The past week produced two openSUSE Tumbleweed snapshots and both included a lot of updates for users of KDE.

Plasma, Gear and Frameworks weren’t the only packages to update in the snapshots.

Snapshot 20211019 offered quite a bit of updated packages. Remote access package remmina 1.4.21 provided updates for the GNOME 40 runtime and made some backward compatibility with WebKit versions under 2.32.0. The refreshable braille display package brltty updated to version 6.4 and made sysusers.d a new package while also removing some old SUSE RPM constructs. The PDF rendering library poppler 21.10.0 fixed the rendering of some odd splash patterns and added support for setting custom stamp annotations. Mesa 21.2.4 had several fixes and rolled out patches for both PowerPC and LLVM i386 compiling. A package to get a major update in the snapshot was rdma-core 37.1, which focuses on userspace components for the Linux Kernel’s drivers/infiniband subsystem; this new major version fixed cmake flags to correct paths for pkg-config. KDE’s 5.87.0 Frameworks version had an enormous amount of updated packages in the snapshot. Among the updates was the removal of defunct Python and Ruby script engines with Plasma Framework. The 5.87.0 Breeze Icons package added 22px variants of the preferences icons and the same version of the UI framework package Kirigami fixed Breadcrumb Control on mobile when using layers.

The previous snapshot this week, 20211016, updated the 25th Anniversary Edition of KDE’s Plasma; the 5.23.0 version dives into a cool blue default color scheme and provides System Settings that lets users pick accent colors to make their system pop out with a personal touch. The Kickoff launcher for Plasma, which is located in the bottom left-hand corner of the screen, had some large rewritten code to make it faster and easier to use. Plasma also made changes to let users drag-and-drop stuff between native Wayland and XWayland apps. KDE’s 21.08.2 version of Gear restored the ability to quickly switch between “Zoom to Fit” and “Actual Size” with a keyboard shortcut for the App Gwenview and video editing app Kdenlive made a minor timing delay for startup crash detection. The sound editing app Audacity updated to version 3.0.5 had a single bug fix and gimp 2.10.28 improved the dark theme by adding a white border on the mouse-hover. The graphics editor also set a light background for selected text in layers and removed a 3D shadow box. The updated version of git 2.33.1 fixed git pull and git rebase -r for various corner cases and bugs. LibreOffice 7.2.2.2 updated translations and the container command-line utility package skopeo updated to version 1.5.0, which introduced an --ignore option to allow sync command to continue syncing even after a particular image sync fails. Other packages to update in the snapshot were GNOME’s video player totem 3.38.2, python-kiwi 9.24.0 and several 4.2.17 versions of the widget abstraction library libyui.

Up to now, text support in librsvg has been fairly limited. The text chapter in the SVG spec is pretty big and it contains features that are very much outside of my experience (right-to-left languages, vertical text). But now I think I have a plan for how to improve the text features.

Bidirectional text

Bidirectional text, or "bidi" for short, happens when one has a right-to-left language like Arabic or Hebrew intermixed with things like Arabic numerals, or Latin text.

This is an interesting little example from the SVG spec:

<?xml version="1.0" encoding="utf-8"?>
<svg xmlns="http://www.w3.org/2000/svg"
     width="100%" height="100%" viewBox="0 0 600 72"
     direction="rtl" xml:lang="he">

  <title direction="ltr" xml:lang="en">Right-to-left Text</title>
  <desc direction="ltr" xml:lang="en">
    An example for using the 'direction' and 'unicode-bidi' properties
    in documents that predominantly use right-to-left languages.
  </desc>

  <text x="300" y="50" text-anchor="middle" font-size="36"> כתובת MAC:&#x200F;
    <tspan direction="ltr" unicode-bidi="embed">00-24-AF-2A-55-FC</tspan> 
  </text>

</svg>

It is supposed to render like this; it says "MAC address: xxx-yyy-zzz":

However, until librsvg 2.52.2 this did not work correctly. You see, librsvg takes each piece of text inside a <text> and creates a Span for it. If there is a <tspan> element, it also gets a Span created. However, librsvg did not handle the case where an inner <tspan> changes the direction property from its parent <text> element.

Another bug:

<?xml version="1.0" encoding="utf-8"?>
<svg version="1.1" xmlns="http://www.w3.org/2000/svg" xml:lang="fa" direction="rtl" width="200" height="100">
    <g font-family="Dana-FaNum" font-size="16">
        <text x="50%" y="50%"><tspan font-weight="bold">نام: </tspan><tspan>مهدی</tspan></text>
    </g>
</svg>

It is supposed to render more or less like this (the line says, "Name: Mehdi"):

This was broken, too!. I did not realize that within <text>, the spans need to be laid out exactly in the text direction, in this case rtl. I thought that it was sufficient to let Pango deal with each group of characters within a span.

Together with that, I fixed text-anchor for right-to-left text. This is what one uses to align a text block with respect to its start, middle, or end. It was also broken for RTL languages before.

One remaining bug is that there should be a space to the left of the :, but librsvg is eating it. I think it needs to implement the SVG2 white-space behavior, which replaces the ambiguous definition of xml:space from SVG1.1.

A test that makes me exceedingly happy

This family of images from Wikimedia Commons has been broken for many years. Someone has been painstakingly making SVG2 maps of German rail by writing SVG code by hand; they use features that became available only after Madds Holland's Outreachy internship from last Summer. Also, the maps use text offsetting features that were just broken.

The little arrowheads were broken because librsvg didn't support orient="auto-start-reverse" in markers (arrowheads get done with SVG's "marker" feature). Madds added support for that during their Outreachy internship.

Then, most of the the multi-line text objects in there were laid out incorrectly. Librsvg was laying out spans inside text chunks incorrectly when they had dx/dy offsets and the text also had text-anchor different from the default.

Previously:

Now:

One last detail which I haven't figured out is that the positioning of glyphs is a bit off. If you look at the slanted label for the LU-Rheingönheim station, the "heim" at the end looks a bit misaligned with the rest of the label. Firefox renders it correctly. Advice is appreciated!

Future plans

All those fixes will appear in librsvg 2.52.3, due in a few days.

I want to add more tests for right-to-left and bidi text; they can be affected by many properties for which there are no tests right now.

After bidi text works reasonably well, I want to add support for positioning individual glyphs with the x/y/dx/dy properties. People from Wikimedia Commons really want this, to be able to lay out equations and such.

Once individual glyphs can be positioned independently, maybe textPath support, which cartographers really like for curved labels.

A handy tool

I recently discovered the Ahem font. It is part of the CSS fonts tests, and consequently part of the Web Platform Tests. Quoting from its description:

The font’s em-square is exactly square. Its ascent and descent combined is exactly the size of the em square; this means that the font’s extent is exactly the same as its line-height, meaning that it can be exactly aligned with padding, borders, margins, and so forth.

That is, you can typeset something with the Ahem font and it will appear as contiguous squares. If you render the string ABCD, it will appear as a rectangle four-ems wide by one-em tall. This is wonderful for reproducible tests!

<?xml version="1.0" encoding="utf-8"?>
<svg xmlns="http://www.w3.org/2000/svg" width="600" height="300">
  <rect x="0" y="0" width="100%" height="100%" fill="white"/>
  <line x1="50%" y1="0" x2="50%" y2="100%" stroke-width="2" stroke="blue"/>
  <line x1="0" y1="100" x2="100%" y2="100" stroke-width="2" stroke="blue"/>

  <text x="50%" y="100" font-family="Ahem" font-size="20" text-anchor="end"><tspan dy="-1em">A</tspan><tspan dx="-40" dy="1em">BC</tspan></text>
</svg>

That renders like this:

Text rendering clearly means spending days trying to get three black squares to draw in the correct position.

NUREMBERG, Germany, Oct. 20, 2021 - Thousands of patients in the coastal area of Kribi, Cameroon, are set to gain enhanced health-care delivery as a hospital in the city expands with the use of energy efficient open-source solutions.

The Ebomé Hospital, which is on the southern coast of central Africa, has 24-hour emergency services, an operating room, radiology, maternity, a laboratory, a pharmacy and other services. The hospital treats thousands of people every year.

As the facility expands, it will use the Hospital Information System GNU Health to manage patient records, laboratory information and administrative services. The system will be running openSUSE Leap 15.3 on several Raspberry Pi 4 computers.

“The excellent, long time relationship among openSUSE and GNU Health communities have resulted in a solid infrastructure that delivers state of the art technology all while delivering outstanding performance and protecting the privacy of the patients and health professionals,” said computer scientist, physician and Free Software advocate Luis Falcón. “From Single Board Computers to enterprise grade servers, to mobile phones. Our communities will continue pioneering and delivering state-of-the-art technology in the areas of public health, hospital and laboratory management, bioinformatics and personal health tech like MyGNUHealth.”

Patients can access personal health records through MyGNUHealth running openSUSE on the PinePhone; or running KDE’s Plasma Mobile, XFCE or their favorite desktop environment. The hospital, which is managed by a Spanish Non-Governmental Organization called Ambala, will be using GNU Health’s 4.0 version on the single board devices with all the hospital- and laboratory-management components.

Half of the 40 Pi workstations in the facility are donated by GNU Solidario, which is an NGO founded by Falcón, and openSUSE.

“The donation of Raspberry Pi and other single board computers helps us a lot to achieve our mission of Universal Health,” he said. “We ship GNU Health embedded on these devices to any health institution around the globe. They don’t have to worry about installation or any technical details, and focus on what is most important, the well-being of their population and patients.”

The 62-bed facility has 65 health professionals and covers an estimated population area of 180,000 people.

The collaboration with the hospital will be discussed at GNU Health Con 2021 from Dec. 10 - 11.

People interested in supporting the project and donating boards like a Raspberry Pi 4 can send an email to info@gnuhealth.org or view the GNU Health donations page.