Rockbox 4.0 released!

The Rockbox project is pleased to announce the immediate availability of
Rockbox 4.0. This marks our first release since November 2019, and since
then we've been busy adding features and fixing bugs to give you the
best Rockbox experience yet.

The list of changes is too extensive to summarize here, but the full
release notes may be found here:

   https://www.rockbox.org/wiki/ReleaseNotes400

For most of Rockbox's "stable" devices, the Rockbox Utility can be used
to automatically handle installation, updates, and more:

   https://www.rockbox.org/wiki/RockboxUtility

If you wish to perform the installation or update manually, binaries
for all "stable" targets are indexed here:

   https://www.rockbox.org/download/byhand.cgi

All others will need to be manually downloaded from here:

   https://download.rockbox.org/release/4.0/

Enjoy Rockbox - we enjoy making it.

My F/OSS hackery isn't limited to printing. I've been using Rockbox since 2002, but didn't actively get involved with its development until 2018, In 2020 I volunteered to take over nearly all hosting and administrative duties, and I've effectively been running the project ever since.

Rockbox matters, and I'm honored to help keep the dream alive.

The Future of Gutenprint (long and opinionated)

This was originally posted to the Gutenprint development mailing list.

Now that the long-delayed 5.3.5 release is out, it's time to talk about Gutenprint's future.

"Everyone wants to create, but nobody wants to maintain. There is no glory in maintenance."

Gutenprint itself is stable and mature. While there are always areas for improvement, it generally does what it claims to do. In that sense Gutenprint doesn't need much ongoing maintenance; just fixing bugs as they show up and occasionally adding support for additional printers. This has effectively been the status quo for some time, but unfortunately, while Gutenprint itself is stable, the rest of the printing world is not.

For many years now, the greater printing ecosystem has been undergoing a foundational shift away from traditional OS/platform-specific printer drivers (such as Gutenprint) towards "driverless" IPP. Nearly all printers released within the past five to ten years JustWork(tm) out of the box, using driverless IPP, either over a network connection or tunneled over USB.

In other words, modern printers don't generally need something like Gutenprint. Meanwhile, older printers tend wear out so that over time, fewer and fewer remain in service. (There are some notable exceptions, and we will get to that later)

~ ~ ~

Currently, CUPS itself acts as an driverless IPP wrapper around traditional PPD-based CUPS drivers. This will go away in the very near future, but the folks over at OpenPrinting came up with so-called "retrofit printer applications" that provide similar functionality in a self-contained manner.

Additionally, last fall a GSoC project created a "native" Gutenprint printer application around PAPPL. This differs from the "retrofit" insofar as it directly interacts with libguenprint instead of its CUPS/PPD driver wrapper, but it is not in a usable state, and completing it may not actually make sense, for reasons to do with those aforementioned exceptions.

Basically, at this point, there are only two sets of "modern" printers that still need a traditional "driver" like Gutenprint:

  1. Models that provide an additional low-level/native protocol that allows a much higher degree of control over what is exposed via IPP.

    Currently this includes high-end Epson Injket printers used to create "fine art" prints, often involving bespoke ink and media. These printers expose numerous knobs to ensure the output can be carefully tuned to achieve the highest possible quality.

  2. Models that do not provide driverless IPP functionality at all.

    Specifically, high-speed dye-sublimation photo printers (such as those used in photo booths or drugstore kiosks) and other/similar models that are used in commercial/production-focused contexts.

Both of these tend to be expensive, have long product lifecycles (that routinely exceed a decade) and nearly always operated on a commercial basis; that is to say they are used to make money for their operators.

The current retrofit application will more than suffice for the folks that have an old printer and want to keep using it for typical home/office stuff. Similarly, it would not likely take too much effort to finish the incomplete native application to the point where it would be an effective replacement for the retrofit application for these tasks.

However, for those two sets of "modern" printers that we believe make up the primary user base of Gutenprint today, the incomplete application will require extensive additional work before it would be usable.

For the high-end inkjets, a way to usably expose the numerous control knobs is utterly necessary. As IPP (or more accurately, common IPP print clients) is not currently up for this task, this will likely need to be done from within the printer application itself, through some sort of (web-based) user interface; This needs to be planned, prototyped, developed, and maintained, and is likely to involve allowing the creation and management of selectable profiles that would potentially include adjustments to virtually every knob the printer supports. This is a huge undertaking.

For the dye-sublimation models, the current retrofit application is not even usable because it completely lacks the custom USB backend, which needs to be ported and integrated to work within PAPPL. There are additional UI/UX warts without easy solutions, and numerous other bits of functionality (eg extensive diagnostic information) that need to be exported, and architectural issues within Gutenprint itself that need addressing before we will be able to fully take advantage of the new functionality that IPP can enable.

This is on top of other work that Gutenprint desperately needs, including:

  • Finally migrate off of Sourceforge (likely to codeberg or sourcehut)
  • Rework the www site into something modern and relevant
  • Finish cleaning up the litany of build warnings with modern compilers
  • Port the GIMP plugin to GIMP3 (ie GEGL and GTK3)
  • Modernize build system (eg modernized autotools or cmake)
  • etc

Most of these are in of themselves significant undertakings, requiring planning, development, and ongoing maintenance across a broad swath of skillsets. The problem is... we don't have that.

At its peak, Gutenprint only ever had a handful of active contributors, but shortly after the 5.3.4 release that number fell to just one, where it has languished ever since.

Even putting aside this large pile of TODOs, this is not a sustainable position. What happens if that remaining person gets crushed by a tree?

~ ~ ~

The bottom line is that as things stand today, none of this work will happen. Or if it happens at all, it will be on an extremely glacial scale, driven primarily by the self-interest and time availability of that one contributor.

This is not just a matter of funding, except in the sense that a sufficient amount of guaranteed funding can be used to pay for suitably-skilled contributors.

As a poignant example of this, over the course of the past three summers, Google sponsored three GSoC attempts to create a Gutenprint printer application. The first two completely ghosted us, and the third looked to be heading in the same direction before they unexpectedly delivered delivered passable (if incomplete) code at the 11th hour.

Even at the lowest end of the GSoC compensation scale, these three students were collectively paid at least triple the amount of funding that Gutenprint itself received during the same time period. This is actually much worse than it sounds; if not for a generous no-strings-attached "thank you" donation from a commercial ISV, the total donations over that three year period would have totaled less than $160! This greatly-appreciated donation didn't fully cover Gutenprint's costs (eg acquiring hardware and media) over that same period.

It is clear these GSoC participants did so for the stipend rather than of any interest in Gutenprint or printing in of itself. There is nothing inherently wrong with that, but when one factors in the time and effort Gutenprint (and OpenPrinting) spent on mentoring, it was probably a net loss when one considers that none of the participants elected to continue contributing after they were no longer being paid to do so.

Frustratingly, if those same funds had been paid directly to Gutenprint instead, it would have all but guaranteed completion of the scoped work, and likely much more. But that window of opportunity/availability has long since closed.

~ ~ ~

There are two general rules in play. The first is the so-called golden rule -- "Whomever has the gold, makes the rules". If there is no gold involved, the second rule kicks in -- "Whomever does the actual work gets to decide what/how it is done"

Given that there is nobody waving around any gold, and there is only one person doing any work, where does that leave Gutenprint?

  • Will stay on Sourceforge for the time being
  • No feature development planned
  • No additional printer support planned
  • Gutenprint will continue receiving bugfixes as needed
  • Folks can use the retrofit printer application when CUPS finally drops the guillotine on PPD-based drivers
  • No plans to resume work on the WIP native printer application

In other words, other than critical bugfixes, this is effectively the end of Gutenprint development, at least until a sufficient infusion of money and/or manpower comes along. Or that one contributor gets taken out by some sort of Florida Man shenanigans.

~ ~ ~

What would be considered "sufficient"? We don't have a good answer for that, but it's going to be infinitely larger than the 'nothing' of today.

While we don't begrudge folks from making money using Free Software, when most of Gutenprint's userbase (or at least the portion that would benefit the most from this work) is actively using it to make money, one tends to get a grumpy when you realize everyone other than you is getting paid. This is not an exaggeration; entire industry verticals have been built on top of Gutenprint.

Logically, one would expect printer manufacturers to consider it in their best interest to ensure their printers are well supported under Linux -- even at the minimal level of providing documentation and loaner models would be beneficial, as opposed to sending legal nastygrams while their own salescritters are actively sending Gutenprint builds to their customers! (This has happened more than once)

Logically, one would expect systems integrators to treat Gutenprint as a critical supplier instead of an infinite free resource (and nearly inevitably violating Gutenprint's GPL license along the way..)

Instead, they have created an XKCD #2347 situation.

~ ~ ~

So, all that said, where would this contributor like to see things go, if sufficient time and/or money was made available?

(Ho-ray, no more speaking in the third person)

As one can probably surmise from the wall of text preceding this, I don't think it's worth continuing meaningful work on "classic" Gutenprint. The retrofit application will work fine for folks with ancient printers until they inevitably fall to prey to the vagaries of time.

The glaring exception to this are dye-sublimation (and other thermal) printers. Indeed, over at least the past five years these have represented the primary area of (expressed) user interest and actual deployments. (There's also the aforementioned Epson injkets, but that's not something I personally care about)

Consequently, I think it makes more sense to build out a new printer application that caters solely to these dyesub models. It would borrow some printer-specific code from Gutenprint (and re-use most of the backend) but will otherwise be a clean-sheet implementation. It still faces numerous hurdles but not having to uplift the rest of Gutenprint along the way will greatly reduce the overall project scope and complexity.

This also aligns with my personal interests, but unless other interested parties step up with funding or other resources, it will remain a (very) part-time effort, if it gets started at all -- My personal printing needs can be met by just keeping an old CUPS installation around, and I'd rather spend my evenings with my family and my weekends doing things outside -- really, anything other than staring at a computer screen performing unpaid commercial software development.

Comments and feedback welcome. Contributors even more so.

But any proposal that entails my undertaking more unpaid work for other folks' benefit will be mercilessly mocked. This goes double for suggestions on how to make Gutenprint "more attractive to potential contributors" unless that suggestion comes in the form of a bag of cash.

Ra Hath Risen

256045:389922

Surprisingly, it was clear and crisp, with none of the pea soup fog we've had every morning for nearly a week.

Taken along 217th St between CR250 and Newbern Rd, in Suwannee County. Unfortunately, clear skies over a bare field make for relatively boring photos, so I took a different approach to keep things interesting.

The final third of 2024 was especially challenging, with two direct hurricane strikes (on top of the hurricane and forest fire in 2023), three four deaths, and an election that unambiguously showed what kind of society my fellow citizens want for themselves.

Here's to a new, and much better, year than what preceded.

Joyspace U826 / Swiftfoto KSF-10R

255489:388900

The Joyspace U826 is a variation of the HiTi P525L, but with two notable changes: Ribbon rewinding and support for different media types (Standard, Transparent, High Density, Metallic, and Sticker)

Rewinding is completely transparent from the software's perspective; with 6x8" media the printer will accept 4x6" prints, but instead of wasting half of the 6x8" ribbon panels, the printer automatically rewinds and uses the other half of the ribbon.

This is slower than submitting a single 6x8" print and having the printer cut it in half, but gives the benefit of minimizing ribbon waste and simpler software flows.

In the process of adding support for the U826, I was able to finally test automatic job combining (ie converting two 4x6" prints into a single 6x8"-cut-in-half print), added 6x5" and 6x6" sizes, and fixed numerous other bugs along the way.

In other printing news, I got my hands on a well-used Kodak 6900, and discovered that it differs significantly from its S2245/S3 sibling -- Most notably within the image processing library and the data tables the printer stores. Reverse engineering is slowly progressing.

UPDATE 2024-10-16: Kanematsu has decided to sell this printer under the 'Swiftfoto' brand as the KSF-10R. As far as I can tell, there are no funcitonal differences, only the name on the box.

Tree Carvings

254582:387400

Taken along a trail at the Suwannee River State Park.

This park took quite a beating from Hurricane Idalia, and four months later, many trails remain inaccessible.

Another Foggy Sunrise

254546:387337

Taken along the southern end of (Madison) County Road 53.

For this new year's sunrise, I had the brilliant idea of watching the sun come up over a solar farm under construction a few miles from my woods. Unfortunately, not unlike the last two, the fog was so thick we could barely see the road!

There was only a few minutes when the solar disc was visible through the fog before it got too bright for further photos. Two hours later, the solar farm (and my woods) are still shrouded in fog. It's a shame, because the clouds in the sky would have made for an spectacularly colorful sunrise..

Happy Holiday Panoramas

DNP's DS620 and DS820 (and Citizen's CX-02/CX-02W) printers have a cool feature where they can create a large panorama print by stitching together up to three smaller ones. This can take the form of discrete panels with a white border between them, or better yet, blend adjacent panels into each other to produce a truly seamless continuous print.

In principle this overlapping/blending is straightforward, but getting it right can be pretty tricky, to the point where DNP only exposed this functionality in a proprietary library/SDK (and their HotFolder utility) instead of their normal driver packages.

After a several year hiatus from hacking on DNP printers, I'm happy to say that I've independently implemented this continuous panorama functionality, and it shows up as just another print size in a print dialog, operating at the post-color-correction YMC layer.

254497:387256

The DS620 with a 6x24 discrete panel panorama, and an 6x20 continuous panorama, from a sunset photo I took over the Indian River over twenty years ago.

254498:387257

It took a lot of prints to get it right! 89 6x8" panels were expended before I finally figured out how to work around a printer firmware bug that kept glitching the edge of each print.

Once the DS620 was working reliably, I turned my attention to its larger sibling, the DS820, which can generate a seamless panorama of up to 8x32" (and up to 8x36" unblended)

I only used up about 15 prints worth of media, most of which was wasted before I figured out that the DS820 bizarrely doesn't support panoramas with A4 media.

254499:387259

An 8x18" print of a stitched photo I took of the (now-former) Aricibo radio telescope in Puerto Rico, along with an 8x32" print of about a quarter of a full 360 degree sunset skyscape I took out at Wallaby Ranch about a year ago, with the 6x24" DS620 print off to the side for comparison.

While the DNP models are confirmed working, the Citizen CX-02 and CX-02S might need some additional tweaking, as they do differ slightly from their DNP siblings and I don't have access to those.

All of the panorama code is is now committed into Gutenprint. Aside from eating up my most of my free time for about a week, getting this development exercise consumed about $75 worth of media -- 92 6x8" prints, 9 A4 prints, and 5 8x12" prints. Suffice it to say, if you find this functionality useful, donations to the cause are appreciated!

The nice thing about the way this is implemented is that the panel splitting and blending code (and data tables) should be trivially adaptable to other printer models, such as Mitsubishi's CP-D90DW and Kodak's 8810, 6900, and 6950. Unfortunately, this sort of effort requires a lot of hands-on time with these printer models (along with media) and that's not likely to happen anytime soon.

Happy printing, folks!

Sony UP-D711MD

A few days ago, I committed support for the Sony UP-D711MD thermal printer. There's not much to say about this little thing beyond the basic specs; it uses 84mm thermal paper and is used in all sorts of scientific and medical contexts. It operates at 300dpi, unlike the 325dpi of Sony's other thermal models.

254223:386805

I figured it would be appropriate to use a medical image for this test. Say hello to Dracula, my ex-wife's constipated (ex-)Iguana.

I didn't exhaustively test the UP-711AD's options but it works well enough to move it off my desk.

If you wish to use this printer, you'll need a Gutenprint snapshot dated on or after 2022-10-26.

I'd still like to add support for the UP-9xxAD series of printers to complete the Sony thermal set, but they're too expensive to qualify for lowball impulse eBay bidding, and most of my attention these days is going to meatspace projects.

As always, happy printing.

2023-10-29 UPDATE: It's the UP-D711MD, not 771

Mitsubishi CP-W5000 (and other updates)

Not unlike the last time I wrote about anything printing-related, it's been a while. Most of my attention has been spent on meatspace tasks (like finishing the tick farmhouse!) but it's now time for a status dump.

The main news is full support for the Mitsubishi CP-W5000, including both sets of cutters and duplexing support. This printer was Mitsubishi's swan song before their exit from the printer business, and brings aobut the end of an era.

Also gaining proper support is the old Fujifilm ASK-2500 aka the Nidec Copal DPB-7000. It turns out it uses the same command language as the older Sony models, so there's clearly some shared ancestry. The ASK-2000 (DPB-6000) and ASK-4000 (DPB-4000) will benefit from this, and should JustWork(tm) once I get the USB VID/PIDs for them.

The minilab-focused DNP DS480 and DS680 models were added as variants of the Mitsubishi CP-D70 family. I've never seen one for sale on its own, but one can still find media on eBay.

All of these additions were done without physical access, relying on interested third parties to provide sniffs and testing, so I don't have any first-print photos to show for any of these.

Preliminary support for the HiTi P310 and P320 series also landed, but in true HiTi fashion they're different enough from everything else that more development is needed before printing is expected to work. This was done in anticipation of someone sending me these printers, but they ghosted me.

Also added is preliminary support for the Fujifilm ASK-400, a rebadged version of the Citizen CX-02 (and DNP DS620). Once I get the requisite USB IDs it should JustWork(tm).

For existing printers, the HiTi P520/P525 and P461 saw notable improvements, and the older Canon SELPHY CP models landed a fix for a serious regression that prevented printing on most media types. Bringing up the rear is the ability to update the firmware of most DNP and Citizen models (and their various rebadged variants).

Looking to the future, there's still quite a long todo list on my issue tracker, but most of those tasks are on hold as I simply lack access to the the printer hardware or are basically an exercise in hardcore binary reverse engineering.

Along those lines, if someone from inside HiTi or Kodak Alaris could get in touch with me with documentation that would help out a great deal, but barring that, the best way to help is to send a printer my way, preferably with some money tucked into the box.

Happy Printing, folks!