 Hello, my name is Khalid, I'm a frontier developer in LibreOffice and I work mostly in text layout. This year we have a Google Summer of course for in fine low-level text layout in LibreOffice. Supposed to be a co-presentation with Akash but he didn't make it to the presentation. So how does LibreOffice do text layout? So we have a VCL module where all the work happens. There's a bot device class that provides the interface for other parts of LibreOffice. Trotex, Trotex.reg, it takes layout, stuff like that. Out device in itself does not do text layout. It uses another class called cell layout. I have no idea what cell is. Softer abstraction something. And cell layout itself does not do text layout either. It uses subclasses for each platform, for each font technology, even for each writing system. So that is the current structure. We have like 10 sub-alimentations of cell layout. I don't even know what many of them do. So we have graphite layout for graphite fontus. We have generic cell layout, not so generic actually. It's used only in Unix. And we have server font layout. And we don't do server fontus for like several decades or something. And we have PSB for boss scripted printing. And we also have PSB server layout for boss scripted printing. I don't know what is the difference between the two of them. And we have graphite layout, graphite server font layout. That is for graphite fontus on Unix as well. So like five classes on Unix just to do text layout. On Windows we have symbol layout. That is for so-called symbol scripts. English, Greek, really stuff like that. And we have Unix script in scribe. That is for complex scripts. Arabic, dictionary, Thai. And we also have graphite for Windows. On macOS we have only one layout class that uses course tickets that does not do graphite fonts. So only on... Graphite is not supported on Mac support. Only on Windows and Unix. And we have multi-cell layout. It took me actually like five years to understand multi-cell layout. It does font fallback. It's... Only verb is doing font fallback. And it is used only on Unix. Not used on Windows or on course tickets. Course tickets does its own fallback. We don't control it. I think it's obvious how much complexity do we have to just do the very low-level text layout. Taking some tickets, font file, and determining graph indices and positions. That is nothing fancy at all. We have all these classes to just do this. So we have complexity supporting all of this. Three classes on Windows, four classes on Unix. To just do post-script printing, which we do not actually use by default. We use BDF printing by default. And one class on Mac, but we don't do graphite fonts on Mac. I think the complexity is obvious. If you just do something same like adding user-controllable features. Something very basic. Should be 10 lines of code or something. But we need to modify all these eight classes, at least. But the biggest problem is the inconsistency. We use different engines on Windows, on Unix, on macOS. Different platforms have different levels of support. Windows XP supports some script, some version. Funicode, Windows Vesta supports new R1. Windows 8 supports even new R1. Windows 10 supports much newer R1. So a leper office user in Windows XP will not get the same supported language and writing system as the user on Windows 10. And the same between Windows and macOS. Open-type support in macOS have been historical very weak. Newer versions of macOS does better open-type support, but older versions was much weaker. We also don't have graphite fonts on Mac, so if someone uses a minority language and needs graphite fonts, graphites are mainly for minor to complex scripts that cannot be done as open-type. No luck on Mac. You can't use it. And also, different platform APIs give us different levels of flexibility. So for example, core-texture on macOS is very high-level. Then we need does bi-directional-texture, does font-fold-pack, and all stuff we don't need. We need to coerce it into a low-level library to do what we need. And this is not very successful integration. We do not control font-fold-pack on macOS, unlike other platformers. When does Unixcribe and Direct Drive provide low-level APIs that we can use? Unix is a fair game. So the solution. We just need one more class. So we had this year a whole summer of good project to unify the low-level text layout. We based our... Okay, so Akash, Jane did the work, and he did a very great job. We wish you would hear. It was my idea, and it is also part of a tender project by TDF to support cross-platform reliable text layout testing, because we currently cannot do reliable layout testing across platforms, because you might get different line breaks, different breaks even between different platforms for the same text and same font. So it is one class. It uses half-bars for everything, even for graphite fonts, because half-bars can do graphite fonts and even 8080 is an Apple-advanced text layout technology specific for Apple. There is no open source implementation for it, and half-bars can call core text ABI for 80 font max. We don't even need to care about it. We will just use half-bars ABI for all our layout. Font loading, like locating, which mapping font names to font files and loading files in memory is still done by platform APIs because it provides better compatibility with font installation and font loading across platforms. So half-bars does only shaping. Shaping is taking a string of text and font files are returning which glyphs at which positions should be shown. Half-bars is a well-tested cross-platform library actively maintained used by many big projects like Google Chrome, Mozilla Firefox, Android, and even on some other small projects. It tracks the latest versions of OpenType and Unicoot, so if Unicoot 10, Unicoot, what's the current version, Unicoot 6 or 7, supported a new language, a new writing system, half-bars will support it very quickly. We do not need to wait for Windows 11 or Windows 17 or whatever because it's very limited or macOS. OpenType introduced a new thing called Universal Shaping Engine last year and half-bars supported it a few weeks after the specification was published, which is only supported in Windows ABI Windows 10. So with using half-bars, we get the latest and greatest versions of OpenType and Unicoot support in whatever platform we use, whatever the native support by the platform is. So the current distance, we have a new common SLE outclass. We have a generic SLE out and a commenter. Anything that is hard. Good is integrated on Windows, mac and Unix platforms and we can do layout and rendering all these platforms using single class. We have still some issues to be solved with. There's some performance regressions, but I think we nailed most of it. FontFallback does not work currently on macOS because we never did FontFallback on macOS. We relayed on Cortex to do it. There's some small pieces missing to do font layout. Some complex Graphite Fonts are currently broken in our implementation because we based our code on the NX implementation which was never used for Graphite Fonts. Graphite had its own layout engine, so we have some smaller bugs we need to fix and apply it, et cetera. Yes, slight performance regression in the new code. I think we nailed most of it. We just need to do some filing and see if the new class itself is slightly slower than the older implementation. All the formats like Type 1 Fonts or Bitmap Fonts are not currently supported. They can be supported, but I think LibreOffice should drop Type 1 Fonts because Type 1 is very ancient format, like it was killed 15 years ago or something, and we have lots of arcane code to support Type 1 Fonts, so we are better off just killing it. But it can be supported, but it would not be too much of a change to support Type 1 Fonts. We still do not use user-control features that should be done at some point in the future. We had to use DirectWrite API for loading Fonts because GDI API is very printed, and so we currently do not support NXP, but it shouldn't be too hard for someone to understand this when there's GDI plus API to fix this because it's just a very small function that needs DirectWrite. Not so much would depend on it. Code is currently in a feature branch, but we should lend it a master soon. So soon on our master, we will have a few members or one we had this. Now we just made it even more complicated. We just added one more comment to say that. But if things went right and no big regressions and no one complained very loudly, we would start killing old classes and just have common Sally out which inherits from generic Sally out and turns inherits from Sally out. So we can just fold common Sally out into generic Sally out or even more the dreaming just have one Sally out class. So that is our, hopefully, the goal. So at this point we will just have one single class so we can start actual refactoring of the code. So the plan is to lend the code and master and have it off by default. We can currently switch between the old implementation and new one at runtime using environment variable. So after lending in master and making sure it builds on all platforms and there is no build problems, we can switch the new code on by default. Allow for some testing, even at least for the next release, keep the two versions. And if no one complains very loudly, we can start killing the code for 5.4 release. So thank you.