Graphics Archive

Wayland (the protocol and architecture) is still lacking proper consideration for color management. Wayland also lacks support for high dynamic range (HDR) imagery which has been around in movie and broadcasting industry for a while now (e.g. Netflix HDR UI). While there are well established tools and workflows for how to do color management on X11, even X11 has not gained support for HDR. There were plans for it (Alex Goins, DeepColor Visuals), but as far as I know nothing really materialized from them. Right now, the only way to watch HDR content on a HDR monitor in Linux is to use the DRM KMS API directly, in other words, not use any window system, which means not using any desktop environment. Kodi is one of the very few applications that can do this at all. This is a story about starting the efforts to fix the situation on Wayland. This is a great article to read – and an important topic, too. Colour management and HDR should be a core aspect of Wayland, and these people are making it happen.

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.

Inkscape 1.0 has been released. A major milestone was achieved in enabling Inkscape to use a more recent version of the software used to build the editor’s user interface (namely GTK+3). Users with HiDPI (high resolution) screens can thank teamwork that took place during the 2018 Boston Hackfest for setting the updated-GTK wheels in motion. This is just the tip of the iceberg of this massive release.

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.

Glass is a simulated operating system user interface (UI) project and it is being made with Unity 2018.4. It is not a real OS, although everything in the package is functional and can be changed easily. Not really an operating system, of course, but still a fascinating project. It also highlights just how versatile modern game engines really are – this is the same engine some of my favourite modern cRPGs and Cities: Skylines are running on.

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 rollicking and surprisingly political blog post takes us through a fascinating history, connecting 1860-era US bank note presses to the 80×20 terminal standard, passing though the Civil War, the US census, mechanical computers, punch cards, IBM, early display technology, VT100, ANSI, CP/M, and DOS along the way.

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.

This is the real, full photoshop - the same codebase as the regular Photoshop, but running on the iPad with a touch UI. The Verge's Dami Lee and artist colleagues at The Verge got to test this new version of Photoshop, and they are very clear to stress that the biggest news here isn't even having the "real" Photoshop on the iPad, but the plans Adobe has for the PSD file format.

This does seem to be much more than a simple cash grab, and I'm very intrigued to see if Adobe finally taking the iPad serious as a computing platform will convince others to do so, too - most notably Apple.

This program has been around since the early '90s, and runs, among other platforms, on Haiku today. Amazing.

Fantastic read with fantastic examples. Set some time aside for this one - you won't regret it.

The lack of a menu bar in (most) touch applications is really what sets them apart from regular, mouse-based applications. It makes it virtually impossible to add more complex functionality without resorting to first-run onboarding experiences (terrible) or undiscoverable gestures (terrible). While menus would work just fine on devices with larger screens such as tablets and touch laptops - I use touch menus on my Surface Pro 4 all the time and they work flawlessly - the real estate they take up is too precious on smartphones.

If touch really wants to become a first-class citizen among the mouse and keyboard, developers need to let go of their fear of menus. Especially for more complex, productivity-oriented touch applications on tablets and touch laptops, menus are a perfectly fine UI element. Without them, touch applications will never catch up to their mouse counterparts.

There's something unsettling about these brutalist redesigns by Pierre Buttin - but I don't outright hate them. There's something very functional about them.

While there are some more objective arguments to be made, most arguments for and against either title case or sentence case mostly come down to whatever you're used to - what you grew up with. Title case looks entirely ridiculous and confusing to me, and makes dialog boxes, text, and other things much harder to read than when it's in sentence case.

The reason? We don't use title case in Dutch. Everything is sentence case. In English, it's mostly a case of preference, and either case type is fine as long as you're consistent.

Interestingly enough, Apple - generally considered the poster child for title case - actually localises its choice for case type. When you run Apple software in, say, Dutch - it doesn't use title case at all, opting for sentence case instead, because that's the norm in Dutch.

Title case also appears to be on its way out - generally, while pre-internet publications use title case, publications originating from the internet generally use sentence case. I wouldn't be surprised to see title case fall into disuse almost entirely over the coming decades in English - including at Apple. There's going to be an inflection point where title case will simply look incredibly out of place in English, as younger generations grow up on new publications that do not use it.

Title case is old - very old - probably because lowercase evolved out of uppercase, and over the centuries, we've been slowly pushing uppercase letters to perform very specific functions in text. Capitals have become an integral and core part of punctuation rules in every (?) language using on the Latin, Greek (?), and Cyrillic (?) scripts, and while there is some variation here and there - e.g. German holding on to capitalising every single noun, not just proper nouns - there's a remarkable consistency between them.

I'm fairly certain English' title case is the odd-one out, and as the internet continues to break down barriers between cultures and languages, title case will eventually disappear from English, too.