Tuesday

I arrived at Nuremberg after a very long travel and nearly no sleep, so I didn’t go to the “warming up” party in the bar, but instead met up with C. and we went to a Balkan restaurant (Balkan Spezialitäten) for dinner. We got Cevapcici sausages with some kind of bell pepper sauce (called ajvar) and some sort of sour cream (kaymak, which confused me greatly since in Poland it’s a name for a sort of caramel) on the side, with some very nice bread (börek). The food was fine, but not amazing. But the restaurant was pretty quiet, probably because it seemed to be more focused on locals than tourists and it was pretty small, so we could talk.

Wednesday

State of Libre Graphics by MABarbe

The first actual day of LGM started a bit late, at 1 pm, but I used all that time in the morning just to sleep. First item on the agenda was the State of Libre Graphics, which is always exciting since you can learn about many small projects you don’t know existed.

Some of the projects that are quite interesting:

• Blockbench – a simpler 3D modeling tool, made for low poly models, with painting tools and even animation. They have a partnership with Mojang, which uses Blockbench for models for Minecraft, and with Hytale so it becomes the main modeling tool for the modding community.
• Coollab, Processing, p5.js and OpenRndr – they all seem to do roughly the same thing, which is procedurally generated 2D graphics. Coollab seems to be a software with a node editor, while others seem to be libraries you can use to code the graphics. I haven’t explored them enough to know for sure what would be differences in how they work; I have only seen how OpenRndr works, and it seems like it’s a coding library in Kotlin which spawns a window with the graphics you coded. It also has some capabilities to make a GUI in that window.
• Friction – a motion grahics software, I believe that’s an alternative to Natron and Adobe AfterEffects.
• Glaxinmate – a 2D vector animation tool. It’s still in version 0.6.0, and it’s part of KDE.
• Graphite – a software for vector graphics and animation. It provides morphing between shapes, it has both layers-based compositing and node-based generation of graphics. And it’s supposed to release 1.0.0 version really soon. (Seems already more advanced than Glaxinmate).
• Pixiv – another node-based pixel art and animation, both frame-by-frame and generated
• OurPaint – a digital art software, it has some elaborate pigment implementation.
• Hyper 8 – if I understand correctly, it’s a static page generator (like Hugo, which is what Krita’s website is built on), except focused on videos. It has browsing, searching, playlists, localisation, collaborative editing, and interactive searchable transcripts, and all that while promising the setup to be really easy, not requiring any database, programming nor maintenance, and compatible with all webhosts.
• Ladron de Flores – that’s actually a movie that uses lots of FOSS software like Inkscape, Krita, Opentoonz, Kdenlive, Audacity and Aegisub (a subtitling tool).
• Ossia Score – a software for live art installation
• Stellarium – desktop planetarium, it is used now in Vera C. Rubin Observatory
• TiXL – realtime/live motion graphics (which I guess makes it similar to Ossia Score?)

Trying out Blockbench

After the LGM I went through different projects to check them out; I already made a voxel lamp in Blockbench and imported it into Blender. It took very little time to achieve this result. With polygonal editing, I had a bit more trouble, especially since Blockbench has alt-clicking for some shortcuts, and that of course causes trouble on my Linux. I really hope I’ll get a hang of the polygonal editing too, since voxel editing is still a bit tedious (especially since I don’t really see a way to merge the cuboids together), but if not, it’s still great.

Trying out PixiEditor

I also checked out PixiEditor. Not gonna lie, the website and the software itself looks really fancy and modern. You can clearly see the modern web influences in the design. The Steam page looks pretty good too. You can see that the people working on it know what they’re doing. There are also some fun quirks of the interface; there is for example a mushroom guy who’s giving you tips like the old Clippy, but more adorable, and some text in GUI that clearly shows that it was written by a Polish person that is also not the overly formal language you see in Krita (for example “Ale tu pusto!”, which means roughly “wow, how empty is this space!” on the empty list of projects). It also has quizes on the documentation page to check your understanding of the topic. Makes learning the software more fun and makes the software itself look more casual as opposed to formal and stiff.

For painting it’s still a bit limited because it doesn’t have many ready-made brushes; I think there is only six of them. I knew there is some node-based engine within so I duplicated a brush, edited it, and finally found a way to the node editor, and I have a bit of mixed feelings about it. Obviously it’s amazing to get nonlinearity, but I have this impression every time I actually try to do something with nodes that it’s a very inefficient system of writing that nonlinearity. In PixiEditor it’s of course still a new system, so you can’t expect it to be already perfectly adjusted for optimal use and I’ve never actually used any node system extensively, so I’m not a good judge of it. It looked promising, though, so I want to try to make some of my favourite brushes there to test the painting side of it properly. Layers system is also node-based (more specifically, a proper directional graph, instead of a tree like in Krita with Clone layers introducing a bit of nonlinearity). I haven’t really explored the full potential of the software yet.

Freeze+Press – talk by Christoph Haag

Freeze+Press seems to be a small printing workshop of sorts that is focused on experimental printing and using FOSS and CC. Currently they have a website where you can buy some stickers (ImageMagick’s wizard, git’s logo, broken image logo, the Canonical tiger), posters and books. A portion of the talk in the beginning was about Christoph’s own story in FOSS and graphics design and how Freeze+Press was created.

The elephant in the room: who owns the rights to an image? – talk by Eylul Dogruel

After the coffee break, there was a talk by Eylul with a title “The elephant in the room: who owns the image?” which was, how you can guess, about AI generated images. I highly recommend you to watch the recording on the Chaos Computer Club website: https://media.ccc.de/v/lgm-2026-110662-the-elephant-in-the-room-who-owns-the-image.

At first, she changed the question into “Who owns the monkey-generated photo?”, and I understand that it might be similar from a legal standpoint, but for me, that’s not a good analogy, because monkeys are sentient. It would be more comparable to a baby taking a photo, or maybe a intellectually disabled person (since a baby would grow up to become an adult with all the rights and capabilities), taking a photo. From that standpoint, imho the owner of the image is that person or that monkey, and since they can’t represent themselves, then the guardian should represent them and control the copyrights. That’s of course all completely not applicable to an AI… Monkeys aren’t trained on stolen images, monkeys also aren’t blindly generating average photos out of all the photos they’ve been trained on. In case of AI, the AI is the combination of all that stolen data. A monkey might have an owner or a conservation organisation that should handle their copyrights; but AI was created by the company that owns it, from all the pieces of stolen data. There is, unsurprisingly, a lot of differences between a monkey and an AI.

It’s a shame the time for questions was so short; I could imagine quite a long discussion about it. I also noticed that, in general, there is a bit of disconnect between the way artists and programmers see AI; and since LGM is sort of a mix of both (when some days layer someone asked who is an artist and who is a programmer, nearly all people raised hands to both questions), you could see voices from both sides. Artists are usually (not always) very against AI on ideological basis, while programmers often just see it as more of a tool.

ctx vector desktop — rasterizing as late as possible – talk by Øyvind Kolås

The next talk was about a ctx vector desktop. I’m still not exactly sure what it is, but it might be because it seems to be many things at once. The main part is a software rasterizer for vector graphics, and everything else seems to be something on top. There is a terminal that is capable of ctx vector graphics and also audio (the terminal itself also written to use ctx), there is a protocol that you use in the terminal to draw the vector shapes, and of course the vector rasterizer itself that later combines it into raster so the downstream (a display server?) can render it as it usually renders all windows. I might be wrong though. If it seems interesting, go watch the talk, Øyvind surely explains it better and without the confusion I have.

Beginner-friendly shader programming in p5.js v2 – talk by Kit Kuksenok

P5.js is a Javascript library that is used for making procedural art, but also focused on teaching users how to code. For the 2.0 version they want to simplify the API for shaders even more so that the user can start coding and making art with as little previous knowledge as possible.

The part of p5 for shaders is, I believe, called p5.strands. The user doesn’t have to define their shader completely, doesn’t have to know how the lights work or anything, instead they can add modifications over a default shader. It’s also written in a way that is familiar to users who used p5.js sketches (which art programming still on CPU). The point of it is that users get familiar with shader programming concepts while still using more familiar syntex. P5.js also supports proper GLSL shaders, so they are also available for more ambitious students.

Phosphor for Tectonic Typefaces – talk by Émile Greis

The last talk was about Tectonic Typefaces in Phosphor. If you are, like me, unfamiliar with font-specific lingo, a tectonic typeface is a kind of typeface that’s composed out of usually same-shaped small elements, usually dots. It gives the typeface this blocky appearance. I think all pixel-art typefaces could be defined as tectonic typefaces. The main point is that it can be defined as a table with some cells being filled and some not. Then the rendering can be more creative, you can add slopes and rounded edges and different sizes for different cells. Looks pretty interesting, though I can imagine that it’s pretty niche.

Dinner time

After the talk there was a photowalk planned, but I was at the (very brutal) photowalk the previous year, and I knew going to the castle meant quite a lot of workout, because it’s on a steep hill, and that would probably just be a part of the attraction, so I decided to skip it.

For dinner we went to Tucher Mautkeller on the Mauthalle street, hoping for better food and maybe some space to talk as well, but it was unfortunately very loud (and quite expensive). I ordered the salmon trout on spinach with rosemary potatoes, and a side salad. The side salad was definitely not a side salad, and not very great either, but the fish was great.

Thursday

Re:WIRE workshop

On Thursday there was a workshop focused on the past and future of the LGM. I made some notes about the past. The future was still discussed later on BoF and the workshop on Friday.

(This was a place where I wanted to include a photo of a page of the first issue of the LGM magazine, because it contained some funny information about Krita and Gimp I think; unfortunately, I couldn’t take the photo at the moment I saw it, and then I forgot. I also took some notes about the history of LGM, but maybe I’ll write about it next time).

Lunch

For lunch we went to grab something easy to eat from the main train station. I found an amazing chicken wrap in one of the stores in the food court there (place called Dean & David, the wrap was called “Chicken & pesto”, 4.95 euros, I bought two more for my travel back and it was so worth it).

Soldering workshop with Simon Budig

Later we went to the soldering workshop. I signed myself as intermediate, even though I’ve never held a soldering iron in my hand before (but how hard can it be, right?). The theory is relatively easy, but we started from the resistors, which are incredibly tiny and finnicky to solder onto the board. First you had to heat up the tiny pad on one side, and then put solder on it so a tiny bit of melted solder stays there; then, using tweezers, put the tiny resistor in between the two tiny pads, and finally heat up the other pad and add some solder to it. The next step was adding LED bulbs; they had a much longer “legs”, so you in theory didn’t need to be as precise anymore, but they had a tendency of bouncing off of the board when you weren’t looking, and keeping both legs flat on the board wasn’t that trivial. Unlike the resistors, they also had a correct and an incorrect orientation: you had to make sure to solder the shorter one to the pad marked with L. Thankfully I didn’t make that mistake. For the “spider” with a switch, the only difficulty was that you can only heat up one pad and one drop of solder at once, so preparing all three pads on one side is a mistake. But it was still managable. The last part was the battery holder, which wasn’t really complicated, though for that you needed an inside knowledge that you can heat the holder’s pad up from inside of the holder after putting the solder on the pad, which binds them together. I think I did it correctly the first time, actually, but I wasn’t sure, so I redid that part (and getting a battery was tricky, so I only checked with battery after everything was done). I also had to redid one of the LED bulbs since one of the legs jumped out of the solder. But all the lights worked correctly the first time I put the battery in. Hurray! Full success. (Just don’t look at the finished board).

The soldering workshop was located in a reception area of a local theatre, because the venue didn’t have appropriate fire safety certification or something. We did have to remove some carpets from the floor though. After the workshop, I tried to teach M. and C. how to play Star Realms with Polish cards; we were sitting among all the chaos, so it was of course a disaster. The main rules were explained though. No one won, because we had to finish abruptly when the workshop ended and there was time for cleaning up the space.

There was a group photo made during the coffee break.

Gimp: A community, free software – a talk by Jehan

Last year I could see for myself how Inkscape works and organizes themselves, so I hoped to learn the organisational structure of Gimp this year as well; the talk was good, but I hoped it would go a bit more into details. Then, of course, I spent a whole day with Inkscape (which was delightful) and Gimp only had 20 minutes to describe themselves. One of the things I noticed is that they have a lot of success with their GSOC students, with most students becoming regular contributors after the project ends. I think we can still improve on that aspect in Krita.

Dinner time

Later me and some others went to a burger place near the main road in the Old Town. I got a classic one, it was pretty nice. We talked about so many things — definitely a bit about AI, about an illustrator, who lost nearly all of their commission work (presumably to AI), about more ethical AI projects, and then of course NFTs, and then finally stumbled upon pigments mode for digital art software (and color management in general). And that lasted the next two hours. There are three separate topics in it: one for proper color management and what is really even is, one for HSX “models” which are just coordinate systems for the RGB color space (so they change depending on the RGB profile you’re using, but there are better and worse ones for different purposes), and the last one, for the pigment mode.

Friday

Counterpunch Font Editor: Faster, Safer Complex-Script Design – talk Yanone

Counterpunch is a font editor with a great name. And it was made by a person who designed font that Krita uses for its logo. It’s browser-based and I can’t really tell you much about it, because I haven’t made a font in my life, but it’s in alpha and apparently it fixes some issues that other font editors often have.

ReWiring the Video Editor – Timeline as a Node, a talk by MABarbe

MABarbe did an amazing talk about a new concept for a video editor, node-based, but also with timeline (or more precisely, timelines, since it is a node and you would be able to have multiple of them at once). It would have some auto-adjusting capabilities so if you want to just reorder clips, even if they are not the same length, you can just switch them around and the rest of the timeline will be adjusted to the new state automatically. MABarbe also said that the common workflows should all have their own nodes with GUI instead of requiring users to fight the node system for something it wasn’t meant for. I was very impressed with this idea; I have tried to use Kdenlive, and even when I knew exactly what I wanted to do, it was not that trivial to use it with the rigid timeline system. Of course I’m not really a video editor and I don’t even know Kdenlive that well, but the system M. was talking about just seemed more suited for the way I’m thinking about video editing (my internal paradigm).

It’s all still in the idea phase, there isn’t even any proof of concept, but I (a layman) was convinced. I wonder if it would be possible to implement it into Friction or Natron instead of a brand new software; but that of course depends on many things.

Lunch

On lunch we went to a falafel place. I got a classic falafel sandwich, while C. got the Arabic one, which turned out to be cut into 6 or 8 pieces and served in a takeaway salad bowl. It was fine, though I felt like it would benefit from more tomatoes. At the end of the break, I tried to rehearse my lightning talk, but I didn’t manage to say it in full. It was very nice that people wanted to listen to it, though, since they were bound to hear it again very soon.

Live Coding for Artists and Designers – workshop by Abe Pazos Solatie

The workshop about OpenRndr was very interesting. Such a shame I didn’t bring my laptop. M. was sitting next to me though, so we were sort of coding together. To get OpenRndr to work, you need to install IntelliJ Idea (to get Kotlin), and then just downloading the template project from the git repository of OpenRndr. The full guide is here: https://guide.openrndr.org/setUpYourFirstProgram.html. The language looked quite alien to me at the first glance, but I had to be brave and act as an expert to M. (who doesn’t know much programming at all) and explain what things mean when I still wasn’t exactly 100% sure yet. But, ultimately, it’s just a bit different syntax, that’s all. You just need to know what to put where, and having an example source file, you could guess quite a lot. (Turned out that most of the confusing syntax was just lambdas over lambdas with brackets being an unnecessary part of the syntax in those cases, therefore omitted, therefore nothing looked like normal functions).

What’s interesting about OpenRndr is that apparently unlike other live coding projects, when you create shapes, you can take them in vector form and apply all sorts of transformations and calculate more things from them. For example when you create a contour from a set of points, you don’t just get to draw that contour, you can get the vector shape characterised by that contour and for example add arrows representing normal vectors to it. The program is also interactive, so you can make it listen to mouse clicks and for example change colors. It also knows the passage of time, so you can animate the shapes. There is a lot of different packages it can use, most notably you can also make a GUI for your graphics to, for example, control the thickness of the lines while the program is running. Overall it looked a bit like a game engine, just with a way more 2D vector graphics options. I was considering using it for prototyping some things like a gradient editor for Krita I’ve been thinking of (with defined curved lines across the HSY space).

Which also reminded me of Seexpr library in Krita. Such a shame it’s so user-hostile and so limited. I hope that I could someday get into it and implement two important features: being able to output opacity, and using Seexpr as a filter, using the projection of the layer below as a base. If those two things are done, then we’d have to make the GUI less user-hostile. Maybe someday we could have an easy-to-use shader layers in Krita.

Lightning talks

I won’t be describing each lightning talk, but there was one that caught my attention. It was an ad-hoc talk about mental health. Started very well, encouraging the atendees to take care of their mental health. I totally agree, that’s a very important topic, something that everyone needs to pay attention to. But then it went downhill, towards, I’m sad to say, pseudoscience; the speaker mentioned that we have no evidence that the consciousness is formed in the brain (which is untrue, we definitely do have evidence of that) and discouraging people from taking psychiatric medication (which is straight up dangerous).

Especially the last one bothered me, because there are several different disorders that improve greatly from being treated with medication, and many kinds of those medication is proven to work really well. We have good anti-psychotic medication and schizophrenic people really need it. We have good mood stabilizers and people with bipolar really need it. We have good ADHD meds and people with ADHD, maybe for different reasons than people from groups mentioned above, really need it too. And sure, there is a lot of people with depression and anxiety and our antidepressants and anti-anxiety medication isn’t as effective as some other medication, but it is still proven to work in a decent percentage of people, and there are multiple kinds if one of them doesn’t work on you; and encouraging those people to not take medication is also harmful: especially if someone is easily influenced and stops taking it abruptly. Depression can be deadly and stopping taking medication like that increases the risk even more.

And sure, psychiatry and psychology is still in infancy when compared to standard medicine, because it only started being treated seriously way later. But it’s still the best we have, and it contains only and all the things that we know about human psychology. We can’t just say “oh but it’s not perfectly advanced yet” and discard *the only thing we know for sure* for some feel-good notes and “common sense” theories or “spiritual healing”. Discouraging people from seeking evidence-based help can, in my opinion, lead to all kinds of adverse effects. Spiritual healing can always be applied on top of actual medicine.

Of course, that was just a lightning talk, improvised just that day. Still, I think it’s an important topic that requires quite a bit of care and foresight applied when talked about.

I also talked about putting your FOSS application on Steam if you’re so inclined. If you know a few basic rules on how to do it and follow them, you’re going to have a much greater success than if you just used Steam as if it was any other storefront. Unlike any other, Steam will promote you if you gain its trust (or blessing). The main point is that launch on Steam is something you need to prepare for for months, gathering wishlists and polishing the Steam page. Since Steam is a closed platform, you might not want to do that, but if the fact that you can distribute software without DRM there (like Krita and other open source software does; like Blender, Godot, OBS, PixiEditor and probably more I don’t know about) is enough, it can be a properly valid source of funding (of course actual amounts depend on so many things… but it might be worth a try).

Liblast 3D asset pipeline – talk by Tobiasz ‘unfa’ Karoń

The talk about Liblast was mostly showcasing the pipeline for creating assets for the Liblast game (which is a 3D shooter) that allows them to create decent-looking 3D assets pretty fast. I wrote more about the pipeline further down, when talking about the workshop.

Tixl Skill Quest – talk by Thomas Mann

TiXL has an interesting idea for onboarding new users: they created a whole tutorial series in the software itself. TiXL is a software for real-time motions graphics, I believe it’s purpose is the same as ossia score. The tutorial seems to be sort of kid wheels for the software, you are guided to do tasks that use more and more advanced features. It reminded me of the Godot’s GDQuest’s tutorial series.

Design Students Experimenting with Free Software – talk by Lila Pagola

This talk was really interesting. Lila is a teacher in some kind of design school and she tries to open the minds of her students to FOSS software in a pretty creative way. She gives them an assignment to choose one FOSS software that seems like it could be useful for one of their typical design or graphical projects (since they are on very different paths, their typical projects differ significantly, so each student just chooses the one that fits their work), do that task in that software, and then evaluate the software, and I think even the feedback was supposed to be divided into two different categories: actual problems with the software, and issues caused by their lack of familiarity with the software. She said that in the past she just wanted them to evaluate the software on its own, without having a project they have to do in it, and she said it didn’t bring much success: students actually using the software was crucial. She also said that after her classes, some students do start to use FOSS software. They are often surprised that it is possible to do things in free software, while up to that point the only thing they knew was one specific “industry standard” program they were required to use for some other classes.

Evening

Before dinner me, C. and M. played Star Realms again, this time successfully, in an empty community area. I was also showing the good quality black pens you can buy in Poland that are perfect for drawing.

Later for dinner me and M. went to the burger place again, taking C. with us. This time I ordered some weird burger with potato chips. It was way too big to eat it the normal way, so I had to split it horizontally in half and eat it with a fork and a knife. I wanted to try it to understand the reasoning for potato chips on a burger, unfortunately, this experience didn’t enlightened me. Maybe if I added them myself, they’d add crunch, but that way it didn’t really do anything, and the flavour was somewhat lost among all others. So I think it’s just a gimmick.

Saturday

Imposition methods for bookbinding – talk by Tom Lechner

Tom Lechner has this very interesting software called Laidout, which is a desktop publishing tool with some vector graphics capabilities. The talk was mostly about various methods of imposition, meaning arranging pages onto physical paper sheets. There are several different usecases, for example when you want to print a sewn together book, you need to print text pages in specific order so when you fold and sew together all the pages, what the reader sees is actually all pages in order. You might want to print a big poster or maybe a sewing pattern on a home printer which only prints up to A4, so you’d want to arrange pages first so you only print the parts you need. Or you might want to print a folded pamphlet, or maybe a sphere-like polyhedron with a map of Earth. It can also be any other 3D shape (from what I can tell), as long as it consists of polygons.

Learnings from Our first 3D Game in Godot – talk motion ensemble (an animation studio) and Alexander Lehmann

I’m writing this part more than two months later, so I don’t remember the details, but I couldn’t just omit this talk. Or rather, this game. The studio was tasked to make a game for an organisation or institution whose whole job is asking the government for information and bothering them until they give that information. Just paperwork after paperwork. So, they made an incremental game (think cookie clicker, but better) in 3D in Godot (see the screenshot below) where first you gotta write the letter, then print it out, then send it, stuff like that, and each stage is shown with this low poly 3D in a very organic way – you can see every letter, everything. Later of course you can advance and get more funding and buy stuff that makes you faster, and what’s best, at the end you can hire more employees, and each and every employee you can hire is a direct representation, with a face, of an employee of that organisation. I really loved this idea. And the game looked fun (at least for the first hour, hard to tell how complex it can really get. The screenshot below is just a small part of of it, of course, but it shows the process of writing, and the stamping).

Lunch

During lunch me and C. stayed in the community area in the venue. We intended to play the game again, but somehow talked through the whole time. For sure we were talking about the Welcome Page widget, and C. was trying to prove to me that converting a 8bit/int image to 16bit/int image in Krita creates incorrect results. Turned out the conversion works fine, but the dialog for the conversion is a bit user-hostile — I believe it’s the same widget that’s used for creating a new image, and when you switch from 8bit/int to 16bit/int, the default colorspace switches from sRGB-trc to a linear sRGB. That caused difference in rendering. Switching it manually back to sRGB-trc in the dialog and only then converting solved the problem.

Liblast 3D asset pipeline – workshop by Tobiasz ‘unfa’ Karoń

Later I went to the Liblast 3D asset pipeline workshop. Liblast is a libre multiplayer 3D game. There is an older legacy version and a newer one, with rewritten codebase, still not yet feature-complete comparing to the old one, but much faster. The workshop is about the tools they use to create relatively good using assets in a short amount of time.

The basic idea is relatively simple: use pre-made normal map, automatically applied onto the mesh, for as much of the content as possible. When unwrapping, the script in Blender compares the faces with areas on the normal map and assigns the UVs in a way to add bevels to the edges of the faces. The normal map includes a few different sizes, both square and rectangular, and there are both vertical and horizontal rectangular shapes, so if you later want to for example add dripping paint to the material, the unwrapped UVs are consistent with the orientation of the face in the world (the bottom is always in the same direction). There are two types of bevels, square and rounded, and there are multiple other additions and some space if you want to add something more. You can change the scale between the normal map and the mesh so it fits your mesh best. Sometimes you need to adjust the UVs, either because it’s a more difficult framgent (not perfectly rectangular), or for other reasons, and of course you also need to mark the seams. Besides normal maps, there are also some dirt maps and common markings textures (warning markings, metal plaque, this sort of things, because the game itself has an artstyle with a industrial, brutalist vibe).

Tech-wise, the key element of the pipeline is a Blender addon called DreamUV by Braam Eulaers. It requires an atlas. The atlas in liblast case is called “hardsurface_atlas_0“. A TexTools addon is also recommended. There are some more maps as well, not just normals.

To test it yourself, first you should watch the talk, then go to Liblast repository: https://codeberg.org/liblast, and download a runnable project here at branch devel-unfra: https://codeberg.org/Liblast/liblast-framework/src/branch/devel-unfa (or maybe specifically at hash https://codeberg.org/Liblast/liblast-framework/commit/a2781c6726255ac026cc8cc5c67ff04c84d5f262). You gotta use it with Godot 4.6.2. For the atlas, go to liblast-assets at branch feature-hardsurface: https://codeberg.org/Liblast/liblast-assets/src/branch/feature-hardsurface or even more precisely, https://codeberg.org/Liblast/liblast-assets/commit/4ca78bd5501f49811c61125f4b5f42632d318aad (they are at textures/hardsurface_atlas_01/export).

UpStage – talk Helen Varley Jamieson

Upstage is a sort of a video call application where you can do a lot of things to the way the main screen is presented. You can add images, text and other elements, you can scale things down, add a background, add a video stream with green screen applied. It can be used for artistic and theatrical installations.

Evening

After the ending we went to the hotel to switch some things up (I wanted to leave the card game there, and get all the warm clothes I could get, and I also made myself a hot tea as well in a thermos cup), and then we went to look for something to eat. We walked past the talafel place, saying that the sandwiches were pretty small, but as we went into the Old Town, I think we, or at least me, started regretting it, not seeing anything suitable to grab to eat on the go.

Finally found a street with many different options. Some people opted for a kebab, but me and K. went for an unsuccessful search for some different kind of wrap. After a few failures, we decided to step into a fast food place with fried chicken. I got a long sandwich and a round sandwich, knowing one fast food sandwich would be too little. There was an option for Polish in the self-order kiosks, but it was clear from the first screen that you should only use it for amusement and not for actual ordering, since the first question, takeout or for eating in the restaurant, had takeout translated to “Podnieść” (which sure, means “picking up” literally, but not only it’s a wrong grammar, but also the word is only used for literally lifting things up in the air; the appropriate translation would be “Na wynos”. There were several other funny mistakes later, as K. noticed).

The meetup place was a small plaza next to the castle, with a café and many restaurants around. The only trouble was that the floor was paved with a big, uneven, slippery rocks, and the filling in between them didn’t reach the top of the rocks, so you couldn’t really sit comfortably on it. But it had nice a view, there was a lightened up tree over us, so we spent all time until half past eleven talking. After that we returned to the hotel and, after saying goodbye to M., the rest of us decided to play the game in the hotel lobby. C. really wanted to explain the game, and then he was of course winning again, but with a few carefully directed “a selected enemy discards a card from their hand” cards I took the lead and it started to seem like I might win, but then we had to stop playing since we were all a bit too tired to finish it properly.

Sunday

On Sunday we ate breakfast together and got to the station. I bought my favourite wraps at the station food court (amazing decision). Travel went pretty smooth, despite the fact that I had to use a replacement bus for part of the train journey; thankfully it was sufficiently marked, I got there in time, and I also got to the later train station way before the departure as well. After two trains and one bus I also hopped onto two trams and finally, very late in the evening, got home.

Note: I wanted to write about and describe every single talk, but it was just too much. It’s already pretty long.

Kaidan 0.16.0 is out now! This release adds a media viewer, improves the emoji picker, and got a button to try another XMPP provider during registration. In addition, it adds support to record voice messages via long press. As always, it includes several smaller improvements and fixes.

Most of the work has been funded by NLnet via NGI Zero Commons Fund with public money provided by the European Commission.

Media Viewer

Kaidan now opens a media viewer when you press an image, video, or audio file. That viewer allows to browse all media within a chat in chronological order. You will not need to scroll through the whole chat history anymore just to find a specific file.

The viewer displays information that only Kaidan is aware of, such as the description or the corresponding message’s body. Furthermore, you can jump to the message, open the containing folder, or delete the file. Music and videos can be directly played without opening them in an external app.

Voice Messages

If you often send voice messages, you will enjoy the new voice message enhancement. With this new version, Kaidan makes it much easier for you to record and send a voice message.

Instead of pressing a button to start recording and pressing another button once you are finished, you can now simply press and hold the record button. As soon as you release the button, the voice message is sent. You can cancel the recording by swiping to the left.

Of course, the regular behavior is still available. You can always decide when to use which way to record your voice messages. Just start a regular recording with a normal press or the new one with a long press.

Emoji Picker

The improved emoji picker matches the look of the remaining app. It opens at the current cursor position while composing a message to quickly choose an emoji. You also can navigate through the emoji picker via keyboard and search emojis.

Automatic Registration

If you opt for creating an account automatically, a suitable XMPP provider is chosen depending on your system’s settings. But it can happen that the automatically chosen provider requires an unsolvable CAPTCHA or information you do not want to hand over, such as an email address.

Formerly, you needed to go back and open the automatic registration again to request an account from a different provider. Since that took some time, there is now a button to directly try another XMPP provider.

Changelog

There are several other improvements. Have a look at the following changelog for more details.

Features:

• Add button to try another XMPP provider during automatic registration (@melvo)
• Display avatars in notifications (@pehg, @melvo)
• Allow to reply to message via its notification on supported systems (@pehg)
• Handle pressing Down/Escape button in chats (@melvo)
• Apply new look to emoji picker with consistent interactive background (@melvo)
• Add search field for emojis as message reactions (@melvo)
• Open emoji/participant picker at cursor position while ensuring picker’s width fits best (@melvo)
• Allow to navigate through emoji picker via keyboard to select emoji (@melvo)
• Play notification sounds (@pehg)
• Show more tooltips (@melvo)
• Add viewer for opening/browsing media within a chat (@fazevedo)
• Add support to record voice messages via long press (@melvo)
• Rework user interface for consistent and smoother look/behavior including buttons, fields, and fading opacity of icons (@melvo)
• Focus message input field on starting/canceling reply (@melvo)
• Allow to zoom via mouse wheel in location map and move map by dragging (@melvo)
• Allow to share selected location via Return button (@melvo)

Bugfixes:

• Ignore incoming call requests from other own devices (@melvo)
• Fix recognizing video calls (@melvo)
• Hide contact name/avatar and adapt stop button’s background if video playback is active in calls (@melvo)
• Maintain last focused user interface elements in various uses cases (@melvo)
• Fix quitting calls (@melvo)
• Fix highlighting contact invitation hint in groups (@melvo)
• Fix wrong highlighting on opening group participant picker in some cases and ensure that highlighted item is not changed as long as count does not change (@melvo)
• Fix opening chat in all cases (@melvo)
• Fix displaying full sender names of message reactions (@melvo)
• Ensure account avatar’s background color is updated if system colors change (e.g., on switching between light/dark mode) (@melvo)
• Fix position of chat name/date in chat list (@melvo)
• Fix showing multiple notifications for media (@melvo)
• Fix saving new draft after sending draft (@melvo)
• Fix highlighting referenced message after loading from database (@fazevedo)
• Fix behavior of toggle buttons on release after long press (@melvo)
• Ensure icons in media viewer and message context menu are always sharp (@melvo)
• Fix displaying notifications for personal data (e.g., availability and device info) sharing requests even if no chat is open (@melvo)
• Update chat list filtering on availability changes of contacts (@melvo)
• Fix sound behavior for subsequent messages (@melvo)
• Fix message input field overlapping messages if its height increases (@melvo)
• Keep zoom level within bounds while zooming in location map (@melvo)
• Fix displaying avatar after canceling selection (@melvo)
• Fix location displaying/sharing including proper location markers (@melvo)
• Allow entering credentials to log in (@fazevedo)
• Fix displaying marked message area (@melvo)

Notes:

• Kaidan requires KItemModels now
• Kaidan requires Qt 6.9 now
• Kaidan requires QXmpp 1.16 now

Download

• Source code (.tar.xz) (sig signed with 04EFAD0F7A4D9724)
• Linux (Flatpak on Flathub)

Or install Kaidan for your distribution:

The Qt folks have taken inspiration in our successful KDE Goals and are starting the Qt Project Goals.

The idea is to select goals that help focus on activities that we believe to be the most crucial for the near Qt future.

Since KDE uses Qt extensively some of you probably have good goals ideas for Qt.

Announce email: https://lists.qt-project.org/pipermail/interest/2026-July/040479.html

Wiki: https://wiki.qt.io/Category:Goals

TL;DR https://codeberg.org/cryptomilk/crane-wyoming

Where I started

I use Home Assistant, and for text-to-speech (TTS) I’ve been running Piper through Wyoming Piper.

Piper is a fast, local neural TTS engine originally built for the Rhasspy project and now maintained by the Open Home Foundation. It’s designed to run entirely offline, even on modest hardware like a Raspberry Pi.

Wyoming is the open protocol Home Assistant uses to talk to voice components like TTS, speech-to-text, wake word, voice activity detection (VAD, which decides when someone has started or stopped speaking) over the network, so any service that speaks Wyoming can be plugged in as a satellite. Wyoming Piper just wraps Piper so it can be served this way.

Both work well and I have no complaints about reliability. My issue is quality: the German voices aren’t great. Piper depends on open datasets for training, and good open German speech data is scarce, so the German models lag behind the English ones. I also run TTS locally on my desktop for event reminders, so voice quality matters to me beyond just Home Assistant.

Looking for something better

I wanted better output quality, so I started looking at alternatives and found Crane, a Rust inference
framework built on Candle.

An “inference model” is a trained neural network used to actually produce output like text, speech, an image, rather than to learn from data (that’s “training”). An “inference framework” is the software that loads such a model and runs it efficiently: managing GPU/CPU memory, batching requests,
and exposing an API around it. Piper and Crane are both inference frameworks.

Crane already had Qwen3-TTS support, and its Serena voice’s German output sounded noticeably better. I also wanted to try Voxtral-4B-TTS-2603, Mistral’s open-weight TTS model, so I added support for it. Voxtral TTS produces expressive, natural-sounding speech across 9 languages including German, with low time-to-first-audio and streaming support. It is a good fit for a voice assistant that needs to start speaking quickly.

Adding Wyoming support

Once Voxtral was working in Crane, I built crane-wyoming, a standalone Wyoming protocol server, so Home Assistant could use these models as its TTS service. To make that possible, I added the Tts trait and the surrounding TTS abstractions to Crane, since there was no stable interface for driving a TTS model on its own, separate from Crane’s full inference engine (tokenizer/LLM/VLM machinery). Those abstractions have since been merged upstream: lucasjinreal/Crane#44.

crane-wyoming depends on Crane only for that Tts trait and the concrete model types it needs to construct, not Crane’s engine crate. So it carries its own small TTS-only model runtime (one dedicated worker thread per loaded model) and its own on-disk response cache.

The project grew into a small Cargo workspace. Besides the Wyoming server
itself, it now has cw-say, a standalone CLI client for scripting.

It also has sd_crane_wyoming, an output module for speech-dispatcher. speech-dispatcher is the common Linux TTS abstraction layer that screen readers like Orca, and other accessibility tooling, talk to. It launches output modules as subprocesses and speaks to them over stdin/stdout, using its own line-oriented, SMTP-style protocol. sd_crane_wyoming translates that into Wyoming requests against a running crane-wyoming server. That way, the same server process and cache serving Home Assistant can also serve the desktop. After registering it in speechd.conf, spd-say -o crane "..." works. So does anything else built on speech-dispatcher, like Firefox’s “Read Aloud” or Orca itself. All of it gets the same voice quality as Home Assistant, without running a second TTS backend.

What’s next

• Speech-to-text. I’ve added Qwen3-ASR support for utomatic speech recognition (ASR) into Crane. This needs to be wired in crane-wyoming next. Also Voxtral-Mini-4B-Realtime-2602 is interesting.
• VAD. Crane already has a Silero VAD implementation. Adding it for STT is straight forward.
• Wake word. Once VAD is in place, add Open Wake Word support or similar.

With all of that implemented, you’d have a complete self-hosted Wyoming voice stack with no cloud dependency.

Current limitations

The catch is that you need a GPU to run it well.

If you only need TTS for occasional things like reminders, short announcements, running it on CPU with caching is enough, since repeated phrases just get served from cache instead of resynthesized.

All of this is for advanced users and hackers right now. There’s no polished packaging yet. Systemd units exist for both system and user services, including socket activation, but you still have to build from source.

However testing and feedback are welcome.

https://codeberg.org/cryptomilk/crane-wyoming

Read on for a look at development news and the Krita-Artists forum's featured artwork from last month.

Development Report

Developments in Krita Plus

Dependencies have been updated in the Qt5 builds (Krita 5.3.x). This updates many libraries Krita depends on for things like file format support. (change)

Luna and Agata have continued improving the Selection Actions Bar. Now it remembers the distance from the selection on restart, and there's a button to pin it to the bottom of the canvas widget instead of next to the selection. (change)

In the Python scripting API, the View class now has signals for 'currentToolChanged', 'currentBrushPresetChanged', 'foregroundColorChanged', and 'backgroundColorChanged'. (change by Moritz Staudinger)

Developments in Krita Next

Wolthera and Dmitry continued working on HDR improvements. CICP values can now be read from and written to ICC profiles, and a "Krita Rec. 2100 Perceptual Quantizer (80cd/m²)" profile has been added (change). PQ reference white can now be read from ICC profile (change).

The Line Tool nows show the angle alongside the length in the floating message popup. (change by Moritz Staudinger)

Future Developments

Testing Needed: Android Animation Export

Last month's new feature of rendering timelapses using Android's built-in MediaEncoder is now being brought to animation export. But it needs testing before it can be merged to the main builds, so so check out the animation export on Android forum topic for test packages if you want to help!

Community Report

June 2026 Monthly Art Challenge Results

The winner of the "Something Unexpected" challenge is…

Join This Month's Art Challenge!

For July's theme, last month's winner passed the choice of topic to runner-up Paint4Thought, who has chosen "An Imaginary Friend". The optional challenge is to place the character(s) in a well-developed environment that contributes to telling the story. Show us what lurks in the depths of your imagination!

Featured Artwork

This month's featured forum artwork, as voted in the Best of Krita-Artists - May/June 2026:

Nominate and Vote For Next Month's Featured Artwork!

Participate in next month's nominations and voting to voice your opinion on the Best of Krita-Artists - June/July 2026.

Krita is Free - But You Can Contribute!

Krita is free to use and modify, but it can only exist with the contributions of the community. A small sponsored team alongside volunteer programmers, artists, writers, testers, translators, and more from across the world keep development going.

If this software has value to you, consider donating to the Krita Development Fund. Or Get Involved and put your skills to use making Krita and its community better!

Additional Changes

Krita Plus (Stable, 5.3.3/6.0.3-prealpha):

• Text: Fix various font loading issues. Use default vertical caret in non-variable fonts. Fix Regular font style not showing and defaulting to Italic. Fix duplicate fonts causing fonts not to load. (bug 1, bug 2, bug 3; change by Wolthera van Hövell)
• Animation Timeline: Switching between frames should always complete, rather than sometimes showing the new frame while leaving the old frame active. (bug; change by Elena Sagalaeva)
• Edit Shapes Tool: After splitting a path, allow moving the new point immediately instead of needing to move the cursor to change state. (change by Luna Lovecraft)
• Toolbars: Add icons for 'Quick Group', 'Quick Clipping Group', and 'Quick Ungroup' actions. (change by Arkady Flury)
• Qt6: Transform Tool: Fix perspective transform getting stuck waiting to complete when the transform became concave. (bug; change by Luna Lovecraft)
• Qt6: Windows: Fix the canvas widget being transparent and letting other open documents show through. (bug; change 1, change 2 by Dmitry Kazakov)

Krita Next (Unstable, 5.4.0/6.1.0-prealpha):

• Toolbars: Add widgets for the 'Choose Foreground Color', 'Choose Background Color', 'Swap Foreground and Background Colors', and 'Reset Foreground and Background Colors' actions. (change by Arkady Flury)
• General: Allow choosing any installed application style instead of only Fusion, macOS (on macOS), Haiku (on Haiku), and Breeze (on Linux distribution builds). This unrestricts using Windows style (not just on Windows), windowsvista/windows11 (on Windows), and styles available on Linux distro builds. (change by Halla Rempt)

Nightly Builds

These pre-release versions of Krita are built every day.

Note that there are currently no Qt6 builds for Android.

Get the latest bugfixes in Stable Krita Plus (5.3.3/6.0.3 prealpha): Linux Qt6 Qt5 — Windows Qt6 Qt5 — macOS Qt6 Qt5 — Android arm64 Qt5 – Android arm32 Qt5 – Android x86_64 Qt5

Or test out the latest Experimental features in Krita Next (5.4.0/6.1.0-prealpha). Feedback and bug reports are appreciated!: Linux Qt6 Qt5 — Windows Qt6 Qt5 — macOS Qt6 Qt5 — Android arm64 Qt5 – Android arm32 Qt5 – Android x86_64 Qt5

Consider this hypothetical:

An operating system (OS) ships version 1.5 of a piece of software.

Meanwhile, the latest version of that software is 3.0.

A user on that OS experiences an issue in version 1.5, or has an idea for a new feature. Who should they contact?

This hypothetical becomes concrete due to the existence of discrete-release OSs, like Ubuntu, Debian, openSUSE Leap, and Linux Mint. These intentionally freeze on certain versions of the software they ship for a certain period of time — even if newer versions have already been released upstream of them.

It’s in the news right now because of a recent kerfuffle over in Linux Mint specifically; a developer of GNOME Calendar asked Linux Mint to patch out support links and change the branding, and later followed up with a fairly inflammatory blog post after the issue was locked for understandable reasons.

This saddens me because the miscommunication was preventable, and now a good portion of the discussion surrounding the topic is about tone rather than the topic itself — a predictable outcome of not caring about tone. But I digress.

I think it’s an important topic, so I thought I’d share my take on the situation.

Are software developers responsible?

Software devs wrote the software. The software broke. End of story.

If only life were that simple!

Having been on the receiving end of thousands of un-actionable bug reports about old versions of KDE’s software in discrete-release OSs for issues that were fixed months or years ago (but not backported by the OS distributor!)… I can tell you it’s very frustrating.

But we in the free, open-source software (FOSS) world make our software available via free software licenses; we need to be prepared for OSs distributing our software in ways we didn’t anticipate or aren’t thrilled about, and bug reports from their users. That’s life.

Our solution in KDE is a bot that automatically closes bug reports for versions of Plasma that are out of support, and we may eventually broaden the system to cover our apps and frameworks, too.

It’s not perfect, but it mostly works out. I can tell because most of the new Plasma bug reports I see these days are from users of rolling-release OSs like Arch, OpenSUSE Tumbleweed, and Fedora KDE (which is not truly rolling, but it’s close enough), and I’d say most are actionable.

It kind of stinks for users of discrete-release OSs, who get a robot telling them that the work they just put in to report the bug was useless. But they also benefit from rolling-release users effectively being their free quality assurance (QA). Trade-offs.

Are distributors responsible?

If my car breaks, I blame the car company — not the vendor who sold them the part that broke.

(well, maybe I blame them too if I’m a car nerd, but that’s the exception!)

Ultimately OS distributors are the car company here, assembling the final product. It’s their job to do adequate QA and work with their vendors (upstream software devs) to make sure that final product sparkles.

Of course, a new car costs many months’ salary and includes a multi-year warranty, while most FOSS OSs don’t and are distributed for free. So expectations need to be tempered a bit.

This is where I think communication breaks down. A lot of free-of-charge FOSS OSs advertise themselves really positively, promising the sun, the moon, and the stars. Whereas the truth for many is that they’re assembled by a small team with a shoestring budget (or none at all) from years-old software offered by grumpy developers they don’t have a great relationship with.

Users then don’t understand the full picture of who’s responsible for what, or the level of support they should expect and from whom.

This is the reason why KDE Linux includes tons of qualifiers and provisos in its marketing material. We don’t want to over-promise! It’s a small project built by a small team. I think every piece of free software should be clear about who should use it… and who shouldn’t. Don’t over-promise! It’s a recipe for frustration and disappointment on all sides.

And if you want an OS with professional backing, you’ll likely need to pay for it.

So what’s the solution?

As a distributor, I think you need to sort out what kind of relationship you want to have with the developers of the upstream software you ship.

Do you want to be able to have a distant relationship? Then I recommend abandoning discrete releases and adopting the rolling release approach.

In this model, you take upstream software the moment it’s released — or at least soon afterwards. Then the conflict disappears! Almost all bugs become upstream bugs, and you can direct users to upstream devs without getting any push-back from them. Everything remaining is an issue that you can fix in your OS.

Rolling release OSs can still have good relationships with their upstreams, of course. But it isn’t as critical.

Don’t want to be a rolling release? That’s fine. Then you need to work closely with your upstreams.

Communicate your users’ complaints and bugs upstream, help drive fixes, and then ship them. Many software developers already release bug-fix versions in addition to feature versions. If they do… ship them! Don’t ignore them; this will make your upstreams grumpier.

If any of your upstreams release a “long-term support” version of their software, ship that. If they don’t, you can even work with them to create one if they’re amenable to the idea, and help to support it.

This is more work, obviously. So if your team is small, it may not be feasible to do for every piece of software you ship. But you can try for the most important ones: the Linux kernel, systemd, Mesa, Libinput, PipeWire, NetworkManager, BlueZ, udisks, CUPS, and KDE or GNOME.

But that’s the important point: shipping a high-quality discrete release OS is more work than producing a competent rolling release. No way around it.

So a way to make this approach more feasible is to reduce your OS’s scope of concern.

For example, you can delegate app distribution to a third party like Flathub, the Snap store, AppImageHub, etc. This lets you focus on just the base OS and its desktop environment, while apps are rolling, which means they’ll accept bug reports about them. Personally, I think there’s a lot to like about this model.

It also helps if you don’t let the software get too out of date. Up to 6 months old? Your upstreams are likely fine with this, and will accept bug reports. 12 months? Mostly fine. 2 years? That starts to get painful for your upstream developers if users are still reporting bugs to them. 3 year or more? Very painful. We pretty much have to direct them to their OS vendor.

What’s not the solution?

Package 2+ year-old frozen releases of as much upstream software as you can, and then ignore the upstreams, their bug-fix releases, and their complaints about this.

This is the worst of all worlds!

• Users get outdated software that’s full of bugs and security holes fixed long ago
• Software developers get un-actionable bug reports from angry and confused users
• Distributors get frustrated communications from software developers that damage or destroy important relationships

Please don’t do this. It isn’t sustainable over time, and will cause a leak of the most desirable users who make an active choice to use your OS.

How do I know this?

Well, I don’t, but I can make an educated guess based on some of the few statistics we do have. A big one is the OS market share on ProtonDB as compiled by BoilingSteam, which counts Linux gamers:

In 2019, the “rolling and rolling-ish (e.g. Fedora)” OSs made up a little over 36% of the total users.

In 2026, they’re up to 71%.

This isn’t everyone, of course; only gamers using ProtonDB. But still, it’s quite a change. Clearly gamers believe rolling-release OSs cater to their needs better than discrete-release OSs do.

So, if you ship a discrete release OS, and you don’t want to or can’t switch it to a rolling or semi-rolling release cadence, please please please work with your upstreams! As a (sadly now only merely occasional) upstream KDE software dev, I can tell you my favorite distributors to work with are the ones who engage with KDE and help get problems solved. It’s a lot of fun when all parties focus on problem-solving.

Last weekend I joined an in-person workshop at HTW Berlin for discussing topics around mapping indoor spaces in OpenStreetMap.

Indoor mapping

Mapping indoor spaces is a somewhat niche topic in the OSM community still, but something that is quite relevant for projects I’m involved in:

• Transitous, for routing transfers through train stations.
• Itinerary, for displaying detailed maps of train stations or airports.
• Kongress, for venue maps for conferences as described here.

The term “indoor” isn’t strictly referring to “in a building” here, there’s many gray areas e.g. at train stations. What’s usually more important is that this introduces a third dimension into the originally mostly two-dimensional OSM data. Another challenge is the need for a very high level of detail, for wheelchair routing every single step matters for example.

Since the last workshop four years ago we had quarterly online meetups to discuss modeling and tagging questions, but for some topics an hour or two in an online meeting is just not enough to properly cover this, it needs locking people in a room for a day or two instead.

Balancing requirements

While it’s often not hard to find a solution for a modeling problem at hand, finding one that works well for all use-cases is hard:

• Easy to explain, use and maintain. Don’t require deep domain knowledge of railway operations or civil engineering for mapping.
• (Backward) compatible with existing data and existing semantics. OSM is a database with billions of objects built up over more than two decades, with countless users.
• Usable for 2D rendering.
• Usable for 2.5D or 3D rendering. This specifically benefits from a higher spatial resolution in the third dimension (which currently is essentially floor levels, compared to the centimeter resolution in the other dimensions), but also from the ability to map visuals of vertical features.
• Usable for tactile rendering. This one is challenging as it’s actively harmed by a higher level of detail. On dynamic tactile displays you have to work with as little as 100 “pixels” in each direction, and possibly just one 1 bit of “pixel depth”, which requires very aggressive abstraction and simplification. 3D printed tactile maps have a higher spatial resolution and allow for some basic textures and symbols, but still way below the options you have with a visual display.
• Usable for routing, both with graph-based and area-based algorithms. The main challenge here is completeness of the data, every barrier has to be there to avoid the router taking clever shortcuts.
• Being able to model all accessibility-relevant properties. See the discussion on directional door attributes below, for example.
• Compatibility for importing BIM data, ie. digital engineering models of buildings. That’s on the extreme end of the level of detail usually, and needs to be significantly reduced/simplified. But it’s an attractive source of high quality building geometries for say an entire university campus.

Fortunately we had people familiar with all those aspects present at the workshop, which helps to avoid easy one-sided compromises.

What even is a door?

There’s detailed notes on the discussion in the wiki, I’ll just pick one topic here to show how even seemingly easy and obvious things are surprisingly complicated when digging into the details, doors.

• Is a door frame with the actual door removed still a door?
• Is a multi-segment foldable door as e.g. found in shop fronts or between conference rooms a door? If so, does that mean doors can contain doors?
• Doors are 0-dimensional features (ie. points) in OSM. That’s a useful simplification, but how do we define directional attributes in that case, e.g. in which direction does the door open?
• Inside/outside is an intuitive way to do that, but that fails in more complex buildings. It would also mean evaluating door attributes requires determining an “inner-ness” hierarchy of all areas in a building, extremely unwieldy, if that would even be well-defined.
• Modeling doors as 1-dimensional features (ie. lines) brings in an inherent direction, but that is perpendicular to the intuitive direction of standing in front of a door, requiring some mental gymnastics to make this work (“I am the door”).

This might seem pointlessly abstract and theoretical, but for e.g. wheelchair routing this is quite relevant. The opening mechanism and opening direction of a door have quite some impact on how easily you can get through.

Outlook

Indoor mapping will probably also be a topic at State of the Map 2026 in a few weeks in Paris. I’ll be speaking about Transitous there, one of the consumers of this data.

I spent the last 2 weeks mostly on fixing the bugs that were breaking font subsetting for annotations.

One such bug was about deleting the original font which we talked about in the last blog.
And there were some more edge-cases and type bugs.

For eg: An object could be a ref but I directly do obj->getStream() instead of obj.fetch(xref).getStream() which crashed the code.

I spent 3-4 days on writing some tests for the font subsetting. I just test 2 things for now.

1. Single annotation test: Here we test if subsetting behaves well for a single annotation. We load a file, add an annotation, save it, re-open it, and check if the annotation is using a properly subsetted font which has glyphs only for the characters we added.

2. Linked annotation test: We try to check if subsetting for a particular annotation leaves all the other annotations intact. So, we load a PDF file which has 2 annotations that use the same font, modify the 1st annotation, save and re-open, check if the subsetting works well for the 1st annotation, and check if the font binary data for the 2nd annotation is intact.

These tests required approximately 400 lines of code which is slightly surprising. This is almost the same amount of code as the subsetting logic in FontSubsetter.cc

I also used core poppler code for these tests and not an API like poppler-qt5 or poppler-qt6 because I needed a lot more control to test these things.

I also switched from Vim + terminal coding workflow to QtCreator. This was basically because I am not very good at GDB right now and wanted a visual debugger to make work easier. Switching to CLion just for it's debugger felt weird.

So I started using QtCreator and it feels okayish right now. I use it with it's FakeVim plugin.

Now, I need to work on:

1. The extra font bug in poppler: Basically, when poppler tries adding fonts for a text, it seems to be including an extra wasteful font such as Cantarell in my case. I need to investigate why this happens.

2. Make our own splitTextByFont: Right now, I just save the font-string mappings when the AP stream is generated in an annotation. This ensures consistency between what is being written to the AP stream and what is visible to the subsetter.
   However, this is not very good both performance-wise and code-wise. We store the mappings for annotations that we might never subset. And it requires change in the internal code.
   Therefore, I have to create my own splitTextByFont function inside my FontSubsetter class which takes the font and returns the appropriate font-string map.
   We need to be careful that we don't cause inconsistencies between what's visible to the subsetter and what actually gets added to the AP stream because that might cause rendering issues.

3. Fixing more bugs: Because bugs never end in moving software, do they?

Thanks for reading! Have a great day ☺️