« Open letter to Joyce Bateman | Home | NoXCF-GIMP: an image editor, ... »

GIMP 2.8 versus FontForge

Sat 19 May 2012 by mskala Tags used: , ,

A few days ago, I ran Arch Linux's update process and it pulled down and installed a new version of GIMP, version 2.8. This version incorporates some changes in the user interface which apparently were under development for a long time, but only very recently finally put into the "stable" distribution stream.

The one that interests me may appear on the surface to be very small, but it is and is meant to be a really significant shift in the entire definition of what GIMP is. GIMP used to be, as the name "GNU Image Manipulation Program" implies, an image editor. With version 2.8, GIMP has become an XCF file editor with the ability to read and write other formats.

The visible consequence of the change is that if you want to load a file in a format like PNG, modify it, and save it back to its original format, you face some new obstacles. First, the familiar "Save" command will automatically change the name to have a .xcf extension. If you change it back to .png and attempt to save, you get a warning box telling you to use the "Export" command instead. It's important not to understate the significance of that warning box. This is not a syntax error. It does not mean GIMP doesn't know what you asked for, nor that your order although possibly legitimate was unusually dangerous (like formatting a hard drive - warning that that's dangerous and asking for confirmation on it is just common sense). The dialog box says that GIMP did correctly understand your order, but is choosing not to obey and to give you an order instead.

If you do use the "Export" command, you can save your file in its original format. There is apparently also an "Overwrite original file" command which will make this operation easier, but it has some behaviour I don't fully understand yet with regard to automatically disabling itself after one use or something like that. Neither of these commands will set the internal "file has been saved" flag. As a result, if you save your work with "Export" and try to exit the program, the program will throw up another warning box telling you that your work will be lost and encouraging you to save it - necessarily in XCF format because that is what "Save" now means to GIMP. This warning is factually incorrect, and the software could easily detect that.

The intended purpose of these changes is apparently to make things easier for users who follow a particular workflow centred on XCF files. If your images are created and live extended lives primarily in the form of XCF files, only exported to some other format for final printing, then it makes sense that you want to save XCF files much more often than you save anything else, and (because XCF files preserve information not preserved in formats like PNG) you could lose a lot of work if you accidentally saved in a format other than XCF when you wanted to save in XCF. The new warnings are claimed to be intended to protect users who have an XCF-centred workflow from that kind of mistake. Adobe Photoshop users often have that kind of workflow (centred, of course, on Photoshop's PSD format instead of GIMP's XCF format). It is well known that GIMP is intended as a Photoshop replacement - that is even mentioned in the headlines of press coverage of the 2.8 release - and any claim from someone informed about GIMP's development that replacing Photoshop wasn't a major consideration in the design change is disingenuous to the point of insult.

Users who do not have an XCF-centred workflow are explicitly encouraged by GIMP's spokespersons to use other software packages instead of the latest version of GIMP. That encouragement and the explanation of the philosophical considerations behind the design change have been given clumsily enough by GIMP's spokespersons that they come across to long-time non-XCF non-PSD GIMP users, including myself, as "We want to serve a user base that isn't you. We wish the cool kids who use Photoshop for graphic design would use GIMP instead, and we wish they would invite us to their parties. If you're not one of the cool kids, fuck off, geek!" Users with the Photoshop-like workflow are consistently referred to as "professional" and "advanced," creating the implication that the rest of us aren't.

It is almost cute that anyone really thinks it's possible for a product to compete in the serious commercial arena while being named "GIMP." In many communities that word is understood as a slur against disabled persons, and in a few it's understood as a BDSM technical term. As one commentator on Slashdot said, that word is seen by many non-geeks as being just as offensive as "nigger"; and the GIMP team's continued insistence that the package's name won't offend anybody just because it's an acronym and they didn't intend it to be offensive, is amazing, and shows how clueless about social interaction some people in the technical community really are. Yes, I know that this word can also mean "decorative cord"; as a child I used to make crafts out of gimp at Summer camp. And your little dog's mama is a bitch, and in the right context nobody's offended by that either. But GIMP still won't be able to compete in the serious commercial arena under its current name.

Users who have complained have been told that they are wrong not to be pleased with the "improvements" in the user interface. The old chestnut about "it's free software so you should be grateful for whatever the developers choose to give you unless you are willing to fork it yourself, and if you ARE willing to fork it yourself, you're Not A Team Player" has been dragged out. It is very notable, and unfortunately all too similar to the stand taken by KDE, Facebook, and similar, that the GIMP team's response to user complaints has been to tell users they are wrong, rather than to admit any possibility of user concerns being legitimate.

I am more angry about these changes than I've been about software in a while, and I am now in the process (which will take several hours at least) of cloning the GIMP git repository and forking it myself. It's interesting that I find this particular item so upsetting. I think one reason is that it happened to be sprung upon me suddenly by my upgrade process. I just ran the Arch upgrade and didn't even know GIMP was one of the things that had changed. When I next happened to want to edit an image file, I saw a new banner and thought "Oh, cool, a new version!" The first news I had of the fact that GIMP is now aimed at a user base I am not part of, was the "I want you to have given a different command, so I will disobey the command I know you did give!" box. That's not a good way to announce a new direction for the project. If I had known there was a new version of GIMP in the works at all, and if I had the opportunity to read the developer's propaganda for it before instead of after the new version insulted me directly, I still wouldn't have thought the changes were good ones, but I wouldn't have gone as ballistic about it.

It's also interesting that I use FontForge a lot, and FontForge has very similar behaviour to New GIMP's with regard to workflow. FontForge's native format is the unique-to-FontForge SFD format, and its interface assumes your fonts live in SFD, will be saved in SFD, and will only rarely be "generated" to other formats. If you change the filename extension from .sfd to something else in the "Save" dialog, it will save an SFD file under the alien filename extension, without comment! If you "generate" a non-SFD format and then exit, you will be warned that your work hasn't been saved. And my workflow for using FontForge is usually not SFD-centred, so I'm likely to get that kind of behaviour if I'm incautious in saving my non-SFD files. Nonetheless, it has never even occurred to me before to complain about the privileged status of SFD in FontForge. So why is FontForge different? Why am I angry at GIMP and not at FontForge? I don't know, but here are some thoughts.

  • I most often use FontForge as a viewer (load, don't modify, exit without saving), or as a command-line script language interpreter (loading and saving all done by the script), so the practical chances for it to piss me off with its GUI "Save" behaviour are relatively few despite the fact that I use it frequently.
  • Fonts are always very complicated, so that the times I would edit a font in the FontForge GUI and then want to save in a non-SFD format and only the non-SFD format, are relatively few. Images as I usually use them are simple. It is relatively common that I'd want to load a PNG in GIMP, edit that, and then save as a PNG and only a PNG. The "I need to save an everything-preserving proprietary format and it's a disaster if I miss that step" argument is strong for my use case of FontForge and weak for my use case of GIMP.
  • FontForge has worked this way as long as I can remember, so the SFD-centred design was never introduced as a surprise change from previous behaviour.
  • FontForge's warning messages are not insulting, and in particular do not include any kind of "I will deliberately disobey an order I understood and am capable of obeying" message.
  • FontForge's developers' user communications are not insulting.
  • It's not really about which is the technically or objectively better way for human beings to interact with computers. It's about how human beings interact with each other. It's about people before principles!

Thinking about those differences makes it a little easier to figure out just what the rules are that GIMP broke. Here are the ones that occur to me, and it's interesting that there are so many. These would be worth thinking about for all projects, not just GIMP.

  • Software is never allowed to argue with an order it understood. At most, it may be appropriate to ask for confirmation of an unusually dangerous or surprising order, or to warn the user about important consequences of an order that it is really reasonable to guess the user may not have foreseen.
  • Saving a file that originated in a standard format back into the same standard format is not unusually dangerous or surprising and does not have important consequences the user is unlikely to know about.
  • Software should never produce factually incorrect error messages if it can reasonably avoid doing so.
  • You're not the boss of me, and neither is the software. Software is never allowed to issue orders to the user.
  • I and only I will decide what is the best workflow for me.
  • Developers or their spokespersons are never allowed to be disrespectful to users who raise issues about design decisions in good faith.
  • Don't fix what ain't broke.
  • Dance with who brung ya.


Z - 2012-09-22 23:56
Absolutely Right! I would go even farther than you have, and say it should be possible for a user to modify the software to saner behavior without having to re-code it. All it took was the crap defaults of version 2.6 (tool box window always on top, because we're all designers with giant wide-screen monitors, right?) to make me insane, but 2.8 sounds awful. Good for you in establishing a fork! Where might it be available?
drachenchen - 2013-12-12 22:07

(optional field)
(optional field)
Answer "bonobo" here to fight spam. ここに「bonobo」を答えてください。SPAMを退治しましょう!
I reserve the right to delete or edit comments in any way and for any reason.