Graphics Archive

It’s taken a Herculean seven-year effort, but GIMP 3.0 has finally been released. There are so many new features, changes, and improvements in this release that it’s impossible to highlight all of them. First and foremost, GIMP 3.0 marks the shift to GTK3 – this may be surprising considering GTK4 has been out for a while, but major applications such as GIMP tend to stick to more tried and true toolkit versions. GTK4 also brings with it the prickly discussion concerning a possible adoption of libadwaita, the GNOME-specific augmentations on top of GTK4. The other major change is full support for Wayland, but users of the legacy X11 windowing system don’t have to worry just yet, since GIMP 3.0 supports that, too. As far as actual features go, there’s a ton here. Non-destructive layer effects is one of the biggest improvements. Another big change introduced in GIMP 3.0 is non-destructive (NDE) filters. In GIMP 2.10, filters were automatically merged onto the layer, which prevented you from making further edits without repeatedly undoing your changes. Now by default, filters stay active once committed. This means you can re-edit most GEGL filters in the menu on the layer dockable without having to revert your work. You can also toggle them on or off, selectively delete them, or even merge them all down destructively. If you prefer the original GIMP 2.10 workflow, you can select the “Merge Filters” option when applying a filter instead. ↫ GIMP 3.0 release notes There’s also much better color space management, better layer management and control, the user interface has been improved across the board, and support for a ton of file formats have been added, from macOS icons to Amiga ILBM/IFF formats, and much more. GIMP 3.0 also improves compatibility with Photoshop files, and it can import more palette formats, including proprietary ones like Adobe Color Book (ACB) and Adobe Swatch Exchange (ASE). This is just a small selection, as GIMP 3.0 truly is a massive update. It’s available for Linux, Windows, and macOS, and if you wait for a few days it’ll probably show up in your distribution’s package repositories.

Ah, PuTTY. Good old reliable PuTTY. This little tool is one of those cornerstone applications in the toolbox of most of us, without any fuss, without any upsells or anti-user nonsense – it just does its job, and it has been doing its job for 30 years. Have you ever wondered, though, where PuTTY’s icons come from, how they were made, and how they evolved over time? PuTTY’s icon designs date from the late 1990s and early 2000s. They’ve never had a major stylistic redesign, but over the years, the icons have had to be re-rendered under various constraints, which made for a technical challenge as well. ↫ Simon Tatham The icons have basically not changed since the late ’90s, and I think that’s incredibly fitting for the kind of tool PuTTY is. It turns out people actually offer to redesign all the icons in a modern style, but that’s not going to happen. People sometimes object to the entire 1990s styling, and volunteer to design us a complete set of replacements in a different style. We’ve never liked any of them enough to adopt them. I think that’s probably because the 1990s styling is part of what makes PuTTY what it is – “reassuringly old-fashioned”. I don’t know if there’s any major redesign that we’d really be on board with. ↫ Simon Tatham Amen.

Twenty-five years. A quarter century. That’s how long we’ve been working on Krita. Well, what would become Krita. It started out as KImageShop, but that name was nuked by a now long-dead German lawyer. Then it was renamed to Krayon, and that name was also nuked. Then it was renamed to Krita, and that name stuck. I only became part of Krita in 2003, when Krita was still part of KDE’s suite of productivity applications, KOffice, later renamed to Calligra… And I became maintainer of Krita in 2004, when Patrick Julien handed over the baton. That means that I’ve been around Krita for about twenty of those twenty-five years, so I’ll hope you, dear reader, will forgive me for making this a really personal post; a very large part of my life has been tied up with Krita, and it’s going to show. ↫ Krita website While it may not be as popular as something like LibreOffice due to fewer people needing it, Krita is a cornerstone application of the Linux desktop (it’s also available for Windows and macOS), and I honestly can barely believe it’s been around for this long. I’m about as far removed from being an artistic painter as a squirrel’s tail is from being a functioning propeller engine so I don’t have need for Krita, but I’m always surprised by how many people mention using it for their painting endeavours. I wish the project and its developers another successful 25 years, and they’re going to need it – Krita 5.3 is coming soon(ish), and the much more involved Krita 6.0, which makes the jump fro Qt 5 to Qt 6, is also in the works. On a personal note, I’m online acquainted with the lead maintainer of Krita, and as she alludes to at the end of the article, COVID hit her hard, and maintaining such a huge open source project isn’t easy to begin with. Much respect for keeping it up, and of course, to everyone else contributing to the project.

A few times a year, a claim will make the rounds that the largest PDF you can make is a square covering about the middle section of Germany – 381 km × 381 km. Turns out, this is only the maximum size Acrobat Reader can display, and not the limit of the format itself at all. So, how big can you go? Very big: If you’re curious, that width is approximately the distance between the Earth and the Moon. I’d have to get my ruler to check, but I’m pretty sure that’s larger than Germany. I could keep going. And I did. Eventually I ended up with a PDF that Preview claimed is larger than the entire universe – approximately 37 trillion light years square. Admittedly it’s mostly empty space, but so is the universe. If you’d like to play with that PDF, you can get it here. Please don’t try to print it. ↫ Alex Chan Don’t worry, I’m out of magenta anyway.

Adobe has announced that it’s acquiring Figma, a popular design platform, for around $20 billion in cash and stock. After rumors surfaced early on Thursday about a potential acquisition, Adobe made it official in a press release shortly afterward. It’s big news in the design and development world, particularly as Figma has been competing heavily with Adobe’s XD products in recent years. I had never heard of Figma before, but it seems it’s actually quite popular – for example, Microsoft uses it to design Office and Windows. This seems like a big catch for Adobe, but a competitor less, too, and that’s not exactly great for the market.

Last week, we mentioned that the extremely popular open source video player VLC is getting a brand-new interface in its upcoming 4.0 release, expected to debut later this year. VLC 4.0 isn’t ready for prime time use yet—but because the program is open source, adventurous users can grab nightly builds of it to take a peek at what’s coming. The screenshots we’re about to show come from the nightly build released last Friday—20210212-0431. VLC is an incredibly popular application, so any major user interface overhaul like this is sure to lead to a lot of bikeshedding.

If you have used tools like Google’s PageSpeed Insights, you probably have run into a suggestion to use “next-gen image formats”, namely Google’s WebP image format. Google claims that their WebP format is 25 – 34% smaller than JPEG at equivalent quality. I think Google’s result of 25-34% smaller files is mostly caused by the fact that they compared their WebP encoder to the JPEG reference implementation, Independent JPEG Group’s cjpeg, not Mozilla’s improved MozJPEG encoder. I decided to run some tests to see how cjpeg, MozJPEG and WebP compare. I also tested the new AVIF format, based on the open AV1 video codec. AVIF support is already in Firefox behind a flag and should be coming soon to Chrome if this ticket is to be believed. Spoiler alert: WebP doesn’t really provide any benefits, and since websites generally use JPEG as a fallback anyway, you end up with having to store two images at the same time, defeating the purpose entirely.

I am a programmer. I do not deal with digital painting, photo processing, video editing. I don’t really care for wide gamut or even proper color reproduction. I spend most of my days in a text browser, text editor and text terminal, looking at barely moving letters. So I optimize my setup to showing really, really good letters. A good monitor is essential for that. Not nice to have. A MUST. And in “good” I mean, as good as you can get. These are my thoughts, based on my own experience, on what monitors work best for programming. There’s a lot of good advice in here. We all know higher pixel densities make our user interfaces and text crisper, but a surprising number of people still don’t seem to know just how much of a gamechanger high refresh rates can be. If you’re shopping around for a new monitor, and you have to choose between higher pixel count or a high refresh rate, you should 100% without a doubt go for the higher refresh rate. The difference 120Hz or 144Hz will make in just how smooth and responsive a UI can be is astonishing. I think the sweet spot is 1440p at 144Hz, preferably with FreeSync or Gsync. Both Windows and Linux support high refresh rates out of the box, but as the linked article notes, macOS basically has no clue anything above 60Hz exists, and you’ll have to be very careful about what display you buy, and be willing to jump through annoying hoops every time you load up macOS just to enable high refresh rates.

Today, it seems we’re on another track completely. Despite being endlessly fawned over by an army of professionals, Usability, or as it used to be called, “User Friendliness”, is steadily declining. During the last ten years or so, adhering to basic standard concepts seems to have fallen out of fashion. On comparatively new platforms, I.E. smartphones, it’s inevitable: the input mechanisms and interactions with the display are so different from desktop computers that new paradigms are warranted. Worryingly, these paradigms have begun spreading to the desktop, where keyboards for fast typing and pixel-precision mice effectively render them pointless. Coupled with the flat design trend, UI elements are increasingly growing both bigger and yet somehow harder to locate and tell apart from non-interactive decorations and content. I doubt anyone here will disagree with the premise of this article, even if you might disagree with some of the examples. These past few weeks I’ve set up virtual machines of all the old Windows releases just to remind myself of just how good the graphical user interface introduced in Windows 95 was perfected over the years, culminating in the near-perfect Classic theme in Windows XP and Server 2003. Later iterations of the Classic theme, in Vista and onward, would sadly retain some of the Aero UI elements even when setting the Classic theme, ruining the aesthetic, and of course, the Classic theme is gone altogether now – you can’t set it in Windows 10. Similarly, Platinum in Mac OS 9 is still more coherent, more usable, and more intentful than whatever macOS brought to the table over the years. We can find solace in the fact that trends tend to be cyclical, so there’s a real chance the pendulum will eventually wing back.

I stopped there because we had to get back to work, but without even leaving the Finder and Desktop I was able to find a bunch of things that long-time Mac users had never known about because they never discovered them in their daily use. None of this is meant to say macOS is garbage or anything like that. It’s just interesting to see when people who love the Mac and are so critical of “discoverability” on the iPad. I’m not even saying the iPad is better than the Mac here, I’m just saying that “discoverability” is one of the big things that has people in a tizzy right now about the iPad, but I think some are laying into the iPad harder than is warranted. You have no idea how many undiscoverable or obtuse features, functions, tricks, and so on you take for granted when using old, established platforms like Windows or macOS.

What explains the popularity of terminals with 80×24 and 80×25 displays? A recent blog post “80×25” motivated me to investigate this. The source of 80-column lines is clearly punch cards, as commonly claimed. But why 24 or 25 lines? There are many theories, but I found a simple answer: IBM, in particular its dominance of the terminal market. In 1971, IBM introduced a terminal with an 80×24 display (the 3270) and it soon became the best-selling terminal, forcing competing terminals to match its 80×24 size. The display for the IBM PC added one more line to its screen, making the 80×25 size standard in the PC world. The impact of these systems remains decades later: 80-character lines are still a standard, along with both 80×24 and 80×25 terminal windows. As noted, a follow-up to our earlier discussion.

A month ago, we discussed an article about just how difficult text rendering is, and today we get to take a look at the other side of the coin – text editing. Alexis Beingessner’s Text Rendering Hates You, published exactly a month ago today, hits very close to my heart. Back in 2017, I was building a rich text editor in the browser. Unsatisfied with existing libraries that used ContentEditable, I thought to myself “hey, I’ll just reimplement text selection myself! How difficult could it possibly be?” I was young. Naive. I estimated it would take two weeks. In reality, attempting to solve this problem would consume several years of my life, and even landed me a full time job for a year implementing text editing for a new operating system.

Rendering text, how hard could it be? As it turns out, incredibly hard! To my knowledge, literally no system renders text “perfectly”. It’s all best-effort, although some efforts are more important than others. Text rendering is, indeed, in the eye of the beholder, and often preferences revolve around what people are used to more than anything else. Still, displays with higher and higher DPI have taken some of the guesswork out of text rendering, but that doesn’t mean it’s a walk in the park now.

GUIs are bloatware. I’ve said it before. However, rather than just complaining about IDEs I’d like to provide an understandable guide to a much better alternative: the terminal. IDE stands for Integrated Development Environment. This might be an accurate term, but when it comes to a real integrated development environment, the terminal is a lot better. In this post, I’ll walk you through everything you need to start making your terminal a complete development environment: how to edit text efficiently, configure its appearance, run and combine a myriad of programs, and dynamically create, resize and close tabs and windows. I don’t agree with the initial premise, but an interesting article nonetheless.