The 46th annual meeting of the International TeX Users Group (TUG 2025) will take place in Thiruvananthapuram (aka Trivandrum), Kerala, India, on 18–20 July, 2025. The Indian TeX Users Group and TeXFolio (STMDocs) with support from International TeX Users Group and sponsors are organizing the event this time as it comes back to India after a long hiatus of 14 years (the last two instances hosted were in 2011 and 2002).
Details about the registration, venue, travel, accommodation, programme, deadlines and important dates etc. are available at the conference page https://tug.org/tug2025/.
Call for participation
TUG conferences always enjoyed excellent presentations and talks about TeX, Typefaces/Fonts, Typesetting, Typography and anything related. Please submit interesting papers — see call for papers and speaker advice. Note that a visa is required for participants from most countries and it is a non-trivial undertaking. Please register and contact the program committee for a visa invitation letter as soon as possible.
The drawings for TUG 2025 are made by notable cartoonist E.P. Unny and the flyer is typeset by CVR.
Krita can now be compiled (MR!2306) and run (Mastodon post) with Qt6 on Linux, a major milestone on the long road of porting from the outdated Qt5 framework. However, it's still a long way to go to get things working correctly, and it will be some time before any pre-alpha builds are available for the far-off Krita 6.0.
For the February Art Challenge, @Mythmaker has chosen "Fabulous Flora" as the theme, with the optional challenge of using natural texture. See the full brief for more details, and bring some color into bloom.
Featured Artwork
Best of Krita-Artists - December 2024/January 2025
Nine images were submitted to the Best of Krita-Artists Nominations thread, which was open from December 14th to January 11th. When the poll closed on January 14th, these five wonderful works made their way onto the Krita-Artists featured artwork banner:
Krita is Free and Open Source Software developed by an international team of sponsored developers and volunteer contributors.
Visit Krita's funding page to see how user donations keep development going, and explore a one-time or monthly contribution. Or check out more ways to Get Involved, from testing, coding, translating, and documentation writing, to just sharing your artwork made with Krita.
The Krita-promo team has put out a call for volunteers, come join us and help keep these monthly updates going.
Notable Changes
Notable changes in Krita's development builds from Jan. 16 - Feb. 12, 2025.
Unstable branch (5.3.0-prealpha):
Bug fixes:
Blending Modes: Rewrite blending modes to properly support float and HDR colorspaces. (bug report) (Change, by Dmitry Kazakov)
Brush Engines: Fix Filter Brush engine to work with per- and cross-channel filters. (Change, by Dmitry Kazakov)
Filters: Screentone: Change default screentone interpolation type to Linear. (Change, by Emmet O'Neill)
Scripting: Fix Node.paint script functions to use the given node instead of active node. (Change, by Freya Lupen)
Features:
Text: Load font families as resources and display a preview in the font chooser. (Change, by Wolthera van Hövell)
Filters: Random Noise: Add grayscale noise option and improve performance. (Change, by Maciej Jesionowski)
Blending Modes: Add a new HSY blending mode, "Tint", which colorizes and slightly lightens. It's suggested to be used with the Fast Color Overlay filter. (Change 1, Change 2 by Maciej Jesionowski)
Nightly Builds
Pre-release versions of Krita are built every day for testing new changes.
This will be a boring one, sorry. Basically a “JFYI” for people interested in Plasma’s release administration.
A while back, there was a discussion about moving Plasma to a twice-yearly release model, to better align with discrete release distros that also have two yearly releases — mostly Fedora KDE and Kubuntu.
We discussed this at last year’s Akademy and decided not to do it yet, based on the reason that a faster release schedule would help get important Wayland improvements to users more quickly, given that we’re trying to polish up our Wayland session at high speed. We agreed that once the Wayland Known Significant Issues wiki page is empty, we can re-evaluate.
Until that re-evaluation happens, we decided to instead lengthen our beta release periods from four weeks to six weeks, with new beta releases every two.
Plasma 6.3 will be released very soon, yay! For this release, we remembered to push out the extra new beta releases, but forgot about adding on an extra two weeks to its duration. Oops.
Interestingly, we haven’t gotten many bug reports from users of the Plasma 6.3 beta, which is historically unusual. I’m not totally sure what to make of this. The optimistic assessment is that the release was already great even by the time we shipped the beta! The pessimistic one is that few people showed up to QA it, so lots of bugs got missed (I’m less sure it’s this, but anything’s possible). Either way, it seems like an extra two weeks of beta time wouldn’t have made much difference, so we’re not considering a great loss.
As a result, we’ve decided to try this same approach for 6.4: a four-week beta period, with new releases every two weeks. We’ll see how it goes! If it’s fine, we can keep it, and if it’s not, we can return to the original plan of six-week beta periods. Until then, enjoy Plasma 6.3!
One year on, with the teething problems a major new release inevitably brings firmly behind us, Plasma’s developers have worked on fine-tuning, squashing bugs and adding features to Plasma 6 — turning it into the best desktop environment for everyone!
Read on to discover all the exciting new changes landing in this release…
A script element has been removed to ensure Planet works properly. Please find it in the original post.
A script element has been removed to ensure Planet works properly. Please find it in the original post.
Highlights
Clone Panels
Duplicate your setup with one click
KWin Zoom
Pinpoint individual pixels
Drawing Tablets
Fine tune your art hardware
Digital Art
We want to make Plasma the best platform for creativity, and Plasma 6.3 takes the next step in that direction by providing features that help artists optimize and customize their graphics tablets to their liking.
The System Settings’ Drawing Tablet page has been overhauled and split into multiple tabs to improve how things are organized, and new configuration options have been added to each section:
You can map an area of a drawing tablet’s surface to the entire screen area
We have refined the tablet calibration feature so that it produces more accurate calibrations
The stylus testing feature shows information about tilt and pressure
You can customize the pressure curve and range of a stylus to chop off the high and/or low parts
You can also re-map or swap the functions of the stylus’s buttons
After finishing configuring your tablet, you’ll be able to see what changed thanks to System Settings’ “Highlight changed settings” feature, which works for most of the Drawing Tablet page.
Graphics
The most important news regarding graphics is a huge overhaul of how fractional scaling works. In Plasma 6.3, KWin makes a stronger effort to snap things to the screen’s pixel grid, greatly reducing blurriness and visual gaps everywhere and producing sharper and crisper images.
This works at very high zoom levels as well, as KWin’s Zoom effect switches to a sharp pixel-perfect representation and overlays a grid on top of the screen. You can actually see how individual pixels look relative to other ones. Very useful for artists and designers.
In the color department, screen colors are more accurate when using the Night Light feature both with and without ICC profiles, and KWin offers the option to choose screen color accuracy — although this can sometimes affect system performance.
A smaller but still nice detail is that widgets placed on the desktop are very slightly translucent, just like the popups of widgets placed on the panel:
Hardware Monitoring
System Monitor monitors CPU usage more accurately, and consumes vastly fewer CPU resources while doing it! If you’re using Plasma 6.3 on FreeBSD, you’re in luck: the System Monitor app and widgets can now collect GPU statistics on your system too.
Info Center also provides more information, exposing data about all of your GPUs as well as your batteries’ cycle counts.
Monitoring printers is equally easy, as each printer’s print queue is shown directly in the widget. The widget also shows a little spinner on any printers that are currently printing, so you can see at a glance which ones are in use.
Plasma already includes a variety of background services that let you know when something has gone wrong and what to do about it. New in Plasma 6.3 is a service that detects when the kernel terminated an app because the system ran out of memory. The service shows a notification explaining what happened, and suggests ways of avoiding this issue in the future.
Tools
Moving on to specific tools, Plasma 6.3’s KRunner (the built-in search tool that also does conversions, calculations, definitions, graph plotting, and much more), Discover (Plasma’s software management/app store application), and the Weather Report widget all come with new features and improvements:
KRunner
KRunner and KRunner-powered searches now let you jump between categories using the Page Up/Page Down keys and Ctrl+Up/Ctrl+Down key combinations.
Discover
A security enhancement landing in Discover highlights sandboxed apps whose permissions will change after being updated. This allows you to check on such changes in case you suspect any shady behavior.
In a similar vein, you can now see whether apps are packaged directly by their developer, or verified by a trusted third party.
Weather Widget
If you’re a fan of the forecasts provided by Deutscher Wetterdienst, you’re in luck: Plasma 6.3’s weather widget allows using this source for weather data.
Usability
Plasma 6.3 makes things easy without ditching flexibility. If you prefer using a mouse with your laptop, you can now configure its built-in touchpad to switch off automatically, so it doesn’t interfere with your typing. Also, if you set up your machine as a network hotspot, Plasma generates a random password for the network so you don’t have to think one up.
Finding help is easier in Plasma 6.3. A “Help” category has been added to the launcher (the menu that tends to live on the left hand side of your panel), and we have removed the Settings category entirely. Its contents have been merged into the System category, reducing the number of categories that don’t offer meaningful grouping.
Speaking of menus, the default Kickoff launcher menu now switches categories only when you click on them, matching the behavior of all other sidebar lists. However, if you preferred the old switch-on-hover behavior, it’s still available too.
We have made things clearer by adding a Show Target item to the desktop context menu for symbolic links, the digital Clock widget displays all events on days with more than five of them (giving you a complete view of upcoming commitments), and when you want to reboot into the bootloader menu the next time your machine reboots, the logout screen now indicates this.
To avoid overwhelming you with too much information, when notifications arrive while Plasma’s “Do Not Disturb” mode is engaged, exiting that mode shows the number of missed notifications, rather than sending them all in one giant torrent.
Additionally, a subtle but important change: when you drag a file out of a window that’s partially below other windows, it no longer jumps to the top, potentially obscuring what you wanted to drag it into!
Customization
Finally, what would Plasma be without customization? To begin with, panels can be cloned! You can also use scripting to change your panels’ opacity levels and what screen they appear on.
In Plasma 6.2, we introduced symbolic icons in Kickoff’s category sidebar. Some people didn’t like that, so in 6.3 you can undo the change yourself: we modified the implementation to pull icons from the standard data source, allowing you to set them to whatever you want using the Menu Editor app.
Speaking of the Menu Editor app, editing desktop files for apps from the “Edit Application…” menu item in Kickoff (and other launcher menus) opens the app in the editor, rather than showing you file properties. This lets you easily edit the entire applications list!
If you have ever lost a widget in the process of customizing your system, you’ll love this new feature: in Plasma 6.3, the Widget Explorer gives you the opportunity to remove every instance of a widget, including those that got lost or are only present on unplugged screens.
Moving KDE's styling into the futureImage
Four applications, four different ways of styling.
Last year during Akademy I gave a talk called Union: The Future of Styling in KDE?!. In this talk I presented a problem: We currently have four ways of styling our applications. Not only that, but some of these approaches are quite hard to work with, especially for designers who lack programming skills. This all leads to it being incredibly hard to make changes to our application styling currently, which is not only a problem for something like the Plasma Next Initiative, but even smaller changes take a lot of effort.
This problem is not new; we already identified it several years ago. Unfortunately, it also is not easy to solve. Some of the reasons it got to this state are simply inertia. Some things like Plasma's SVG styling were developed as a way to improve styling in an era where a lot of the technologies we currently use did not exist yet. The solutions developed in those days have now existed for a pretty long time so we cannot suddenly drop them. Other reasons are more technical in nature, such as completely different rendering stacks.
Introducing Union
Those different rendering stacks are actually one of the core issues that makes this hard to solve. It means that we cannot simply use the same rendering code for everything, but have to come up with a tricky compatibility layer to make that work. This is what we currently do, and while it works, it means we need to maintain said compatibility layer. It also means we are not utilizing the rendering stack to its full potential.
However, there is another option, which is to take a step back and realise that we actually may not even want to share the rendering code, given that they are quite different. Instead, we need a description of what the element should look like, and then we can have specific rendering code that implements how to render that in the best way for a certain technology stack.
This idea is at the core of a project I called Union, which is a styling system intended to unify all our separate approaches into a single unified styling engine that can support all the different technologies we use for styling our applications.
Image
The three separate parts of Union
Union consists of three parts: an input layer, an intermediate layer and an output layer. The input layer consists of plugins that can read and interpret some input file format containing a style description and turn it into a more abstract desciption of what to render. How to do that is defined by the middle intermediate layer, which is a library containing the description of the data model and a method of defining which elements to apply things to. Finally, the output layer consists of plugins that use the data from the intermediate layer and turn it into actual rendering commands, as needed for a specific rendering stack.
Implementing Things
This sounds nice on paper, but implementing it is easier said than done. For starters, everything depends on the intermediate layer being both flexible enough to handle varying use cases but at the same time rigid enough that it becomes hard to - intentionally or unintentionally - create dependencies between the input and output layers. Apart from that, replacing the entire styling stack is simply going to be a lot of work.
Image
Plasma's SVG styling uses specially-marked SVG items for styling.
To allow us to focus more on the core we needed to break things down into more manageable parts. We chose to focus on the intermediate layer first, by using Plasma's SVG themes as an input format and a QtQuick Style as output. This means we are working with an input format that we already know how to deal with. It also means we have a clear picture of what the output should look like, as it should ultimately look just like how Plasma looks.
At this point, a lot of this work has now been done. While Union does not yet implement a full QtQuick style, it implements most of the basic controls to allow something such as Discover to run without looking completely alien. Focusing on the intermediate layer proved very useful, we encountered and managed to solve several pretty tricky technical issues that would have been even trickier if we did not know what things should look like.
Image
Plasma Discover running using Union.
Union Needs You!
All that said, there is still a lot to be done. For starters, to be an actual unified styling system for KDE we need a QtWidgets implementation. Some work on that has started, but it is going to be a lot harder than the QtQuick implementation. We also need a different input format. While Plasma's SVG styling works, it is not ideal for developing new styles with. I would personally like to investigate using CSS as input format as it has most of what we need while also being familiar to a lot of people. Unfortunately, finding a good CSS parser library turns out to be quite hard.
However, at this stage we are at a point where we have multiple tasks that can be done in parallel. This means it is now at a point where it would be great if we had more people developing code, as well as some initial testing and feedback on the systen. If you are interested in helping out, the code can be found at invent.kde.org/plasma/union. There is also a Matrix channel for more realtime disucssions.
Kasts polishing, progress on Krita Qt6 port and Kdenlive fundraising report
Welcome to a new issue of "This Week in KDE Apps"! Every week we cover as much as possible of what's happening in the world of KDE apps. This issue contains change from the last two weeks.
Much happened the past two weeks, we had a successful KDE presence at FOSDEM, we now have a location and date for this year's edition of Linux App Summit (April 25-26, 2025 in Tirana, Albania) and also continued to improve our apps. Let's dive in!
KStars 3.7.5 is out with mostly bugfixes and performance improvements.
GCompris 25.0 is out. This is a big release containing 5 new activities.
Krita 5.2.9 is out. This is a bug fix release, containing all bugfixes of our bug hunt efforts back in November. Major bug-fixes include fixes to clone-layers, fixes to opacity handling, in particular for file formats like Exr, a number of crash fixes and much more!
We made it possible to rename tabs in Dolphin. This action is available in each tab's context menu. This is useful for very long tab names or when it is difficult to identify a tab by a folder's name alone. (ambar chakravartty, 25.04.0. Link)
We also improved the keyboard based selection of items. Typing a letter on the keyboard usually selects the item in the view which starts with that letter. Diacritics are now ignored here, so you will for example be able to press the "U" key to select a file starting with an "Ü". (Thomas Moerschell, 24.12.3. Link)
We changed the three view buttons to a single menu button. (Akseli Lahtinen, 25.04.0. Link)
We made the "Empty Trash" icon red in conformance to our HIG as it is a destructive operation. (Nate Graham, 25.04.0. Link)
We improved getting the information from supported version control systems (e.g. Git). It is now faster and happens earlier. (Méven Car, 25.04.0. Link)
We added input methods hints to input fields. This is mostly helpful when using different input methods than a traditional keyboard (e.g. a virtual keyboard). (Juraj Oravec. Link)
We continued to improve the coverage of Itinerary in Poland. This week we added support for the train operator Polregio, fixed and refactored the extractor for Koleo and rewrote the extractor for PKP-app to support the ticket layouts. (Grzegorz Mu, 24.12.3. Link 1, link 2, and link 3)
We also added support for CitizenM hotel bookings. (Joshua Goins, 24.12.3. Link)
We also started working on an online version of the ticket extractor. A preview is available on Carl's website.
Volker also published a recap of the past two months in Itinerary. This contains also some orthogonal topics like the free software routing service Transitous.
We fixed the vertical alignment of the queue header. (Joshua Goin, 25.04.0. Link)
We are now using Kirigami.UrlButton for links and Kirigami.SelectableLabel for the text description in the podcast details page to improve visual and behavior consistency with other Kirigami applications. (Joshua Goins, 25.04.0. Link)
We also improved the look of the search bar in the discovery page. It's now properly separated from the rest of the content. (Joshua Goins, 25.04.0. Link)
We added the ability to force the app to mobile/desktop mode. (Bart De Vries, 25.04.0. Link)
We fixed the sort order of the podcasts episodes. (Bart De Vries, 24.12.3. Link)
Finally we made various improvements to our usage of QML in Kasts to use newer QML constructs. This should improve slighly the performance while reducing the technical debt. (Tobias Fella, 25.04.0. Link 1, link 2, link 3, link 4, link 5, and link 6)
We fixed some issues with the list of commits displayed in Kate. The highlight color is now correct and the margins consistent. (Leo Ruggeri, 25.04.0. Link)
We improved the diff widget of Kate. The toolbar icon sizes are now the same as other toolbars in Kate. (Leo Ruggeri, 25.04.0. Link)
The Krita team continued porting Krita to Qt6/KF6. The application now compiles and run with Qt6, but there are still some uni tests not working. Link to Mastodon thread
We implemented the dynamic resolution mode from the remote desktop protocol (RDP). This means we now resize the remote desktop to fit the current KRDC window. This works for Windows >= 8.1. (Fabio Bas, 25.04.0. Link)
We added support for the domain field in the authentication process. (Fabio Fas, 25.04.0. Link)
We adapted the code to work with FreeRDP 3.11. (Fabio Bas, 25.04.0. Link)
We added a way to filter the list of certificate to only show certificates for "Qualified Signatures" in the certificate selection. (Sune Vuorela, 25.04.0. Link)
We are now using more fitting icons for the "Embed" and "Open in Browser" actions in Tokodon's context menu. We also removed the duplicated "Copy to Clipboard" action from that context menu. (Joshua Goins, 24.12.3. Link and link 2)
Following the improvements from two weeks ago, we did even even more accessibility/screen reader improvements to Tokodon. (Joshua Goins, 24.12.3. Link)
For a complete overview of what's going on, visit KDE's Planet, where you can find all KDE news unfiltered directly from our contributors.
Get Involved
The KDE organization has become important in the world, and your time and
contributions have helped us get there. As we grow, we're going to need
your support for KDE to become sustainable.
You can help KDE by becoming an active community member and getting involved.
Each contributor makes a huge difference in KDE — you are not a number or a cog
in a machine! You don’t have to be a programmer either. There are many things
you can do: you can help hunt and confirm bugs, even maybe solve them;
contribute designs for wallpapers, web pages, icons and app interfaces;
translate messages and menu items into your own language; promote KDE in your
local community; and a ton more things.
You can also help us by donating. Any monetarnky
contribution, however small, will help us cover operational costs, salaries,
travel expenses for contributors and in general just keep KDE bringing Free
Software to the world.
To get your application mentioned here, please ping us in invent or in Matrix.
If you don’t know what Fast Sketch Cleanup plugin is, here’s a blog post describing it in detail: https://krita.org/en/posts/2024/fast_sketch_background/.
In short, it’s a neural network-based filter similar to Edge Detection or Engrave that is supposed to clean up a sketch and create lines that can be used as a base for a lineart or help with coloring.
The old GUI was relatively difficult to use and quite limited. For example, there was no way to use a custom model outside of the main directory, you’d have to manually put the model files into the main directory of the plugin. There was also no pre- or post-processing, and the resolution of the input image was fixed, which didn’t allow for fine-tuning the result.
The new GUI looks like this:
Model
In this section you can select the model in the File combobox, or you can switch to another folder using either the button with the folder icon (for a custom folder) or the “Reset to default” button (which resets the path to the default path for the plugin). The combobox with models gets updated to show the models from the currently selected folder.
“Note about the model” presents some notes or hints about usage that were saved into the model information file.
Device to use
Here you can choose whether to use CPU, GPU or NPU. NPU is a new type of device that is only available on some computers, on Windows you should have all the drivers already installed, but if you’re on Linux, you would need to install them manually. CPU is typically the slowest, so if any other is available, use the other one. Unavailable devices should be greyed out.
Preview images
Those are small cutouts of the image on different stages of the processing. First image shows the original sample; the second one shows the result of the pre-processing; third shows the result of the inference (processing through the model) applied to the pre-processed image; and the last one shows the final result.
Preview size determines how big the preview is. The sample is cut out of the center of the image, with the width and height being equal to the Preview Size * Model Input Size (usually 256) / Scale. That means that a Preview Size of 8 would update roughly 16x slower than Preview Size of 1, no matter the Scale, and assuming the same model. That might make the dialog less responsive, so be careful with higher values. Sometimes it is useful though to see a bigger preview though.
If you click on one of the images, it will bring out a dialog showing the same image in a bigger size, and you can click on the buttons or use arrows to navigate to the other images. You can resize that dialog to see even more detail if needed.
Pre-processing
Defines the pre-processing. It’s performed in the order of the widgets in the dialog.
Levels widget: it’s a quick way to increase contrast in the input image.
Scale: every model has a specific size of its context window, which means it’s sensitive to resolution. Using Scale you can quickly decrease or increase the resolution of the input image, changing the result in a very significant way. Be careful, it’s a scale for one dimension, meaning that the processing time will increase or decrease exponentially.
Post-processing
Scale: it’s just a widget showing the reversal of the scaling in pre-processing. You can’t change it. It ensures that the result has the same size as the input image.
Levels widget: it works just like in the pre-processing.
Sharpen filter: it sharpens the result, with the strength equal to the number from the slider. Zero means input = output, every higher value sharpens the result. One means the exact result you’d get from Krita’s normal Sharpen filter.
Advanced options
Invert: usually you don’t need to change this option, because whether it needs to be checked or not is embedded in the model information file (the same one that contains the note). Most models do require this checkbox checked.
Run
Press the button to start processing. It takes the projection (think: “New Layer From Visible”) of the canvas, puts it through all the processing, and then creates a new layer with the result.
The Run button changes into a Progress Bar to show you progress. When the image is processed, the dialog closes automatically.
Note that it’s not possible to cancel the processing, unfortunately.
Best workflow
The ultimate best workflow I found to get the best result is to first use SketchyModel.xml with low scale (either 1.0 or often even below that), then either decrease the opacity of the result or put a white semi-opaque layer on top, and then use InkModel.xml. The first model removes unnecessary lines and smoothes the lines out, and the second model creates nice, crisp lines. The only problem with using them one after another is that SketchyModel produces pretty dark lines, while InkModel is sensitive to values and requires the input to be light grey, otherwise it doesn’t work properly, hence the additional white layer.
You can also use InkModel.xml directly, if the sketch is clean enough already.
Example 1.
The following examples are derivatives of David Revoy’s sketch “Pepper Sketch”, with the only editing being the FSC plugin or Engrave G’MIC filter (used for comparison).
Workflow:
Use SketchyModel, Levels: (0.3, 1.0)
Add a white layer, opacity = 40%
Use the mentioned model or G’MIC filter.
Results:
Original sketch:
Result of SketchyModel, with Preprocessing: Levels (0.30, 1.00), and then with a white 40% transparent layer on top:
Results of the workflow with, in order of appearance: a) SoftInkModel, scale 4.0, b) InkModel, scale 4.0, c) InkModel, scale 6.0:
Result of G’MIC’s filter Engrave, in order of appearance: a) over the original sketch, b) over the version smoothed out by SketchyModel:
rajeesh
Basically a “JFYI” for people interested in Plasma’s release administration.
@ahiemstra:kde.org
