New GIMP Book Under Open Publication License

Carey Bunks wrote to tell us that last week, "a new GIMP site, Gimp-Savvy.com, has come online and is making available the complete text of the recently released book Grokking the GIMP . This new GIMP resource, written by me and published by New Riders, has been released under an Open Publication License. The goals of Gimp-Savvy.com are to provide high-level educational and practical resources for the GIMP, and to promote its skillful and knowledgeable use."

It's good to see high-quality books on open source software, and this one is well-organized, thorough and profusely illustrated. It happens to make a great online GIMP tutorial as well.

Note: as you might expect, many of the Web pages that make up the book are image-heavy (as you might expect), so if you're on a slow connection, browse the detailed, outline-format table of contents carefully.

And if you do have the bandwidth, you can slurp down the entire book to browse later. When's the last time you read a book that came as an HTML tarball?

Re:let it begin

> Well, since the Gimp is open source, it should
> be possible for somebody to add this in.

Problem with that:

The very process of pre-press colour management is patented and controlled by the industry in other ways. The pantone system, for example, is an industry standard method of converting additive colours to their subtractive equivalents. Unfortunately, even if you can work this into your free software, you cannot call it pantone. That's okay for some situations (I need cmyk for my colour laser printer, e.g.), but it's not going to fly for professional prepress.

This is not just a matter of working a translation layer for colour into the software. There is an intellectual property issue. Even if you could do a colour separation with Gimp, you cannot use the results professionally without licensing which we cannot obtain.

For web publishing, that's fine, since all we need for computer monitors is RGB+alpha. For hard publishing, it's altogether another story, and not a trivial matter at all.

The printer needs to know, for a given ink and paper on a given press, how a colour is defined. If I have a press in michigan and a press in new york both printing the same book, magazine, cd cover, or what-have-you, I need the colours and ink textures to not only match each other, but also to match as closely as possible the original RGB image. (There are a LOT more colours possible with ink than even the best graphics systems can display, so "closely as possible" means we get the same results from different systems). Just because you have an amazingly accurate flesh tone on your monitor, does not mean that you have the information you need to get that flesh tone onto paper. And even if you could tweak one press or printer to give you the correct tones, you haven't done it for another printer, or even the same printer with different ink.

If you can convince someone like Adobe to release a pantone plugin for gimp, some of this problem will be solved. If you have photoshop, you can do your colour separation with that and use the rgb values for gimp, but do you see something wrong with that picture?

This problem is very similar to the problem with RSA. Someone in a free country could create a NON-US version of Gimp that has CMYK separation capabilities (which isn't hard). *BUT* it could never be legally used in the USA for prepress (commercial or not!) so no one bothers. (At least, the non-us/non-rsaref crypto has a niche where it is useful, so the community delivers that.)

Basically, pointing out the lack of colour standardization as a shortcoming of gimp is not fair to those whose images are not destined for hardcopy press.

I would wager a dollar that most people reading this slashdot article are using gimp to create rgb images which will remain rgb images for their entire life, and that those who criticize the lack of colour standardization in gimp are using something far more sophisticated than gimp for their prepress work.

Furthermore, most of them end up using ONE cmyk value more than any other. (the one for black).

It's not totally fud, but it's not really a fair criticism either. Colour standardization will not magically find it's way into gimp; and it only needs to be there for prepress purposes. Unfortunately, this includes everything from the black ink on your business card to getting your digital photograph on the cover of the Rolling Stone. Basically, if the only tool you have for your digital image is gimp, you won't be getting your picture published, or rather, you will get to pay someone else to put their grubby hands on your image before it gets printed. Do you understand the problem now?

We haven't even touched on the font problem. Have you ever thought about why people who write books benefit from typesetting systems as opposed to word processors? Just because you can make a beautiful antialiased screen font and display it, does not mean that's the way it's going to be rendered by the printing press.

I thought online publishing was taking over anyway. Did the revolution end, or did I miss something? Why are we still printing things on paper? Is it only to keep these patent holders fed?

I'd like to hear how well it works

I'd be very interested in hearing the experiences of both authors and publishers about how well open licenses work for books. There are now at least three publishers that I am aware of who have published books that are licensed in whole or in part under an open license: O'Reilly [oreilly.com], Coriolis [coriolis.com], and New Riders [newriders.com]. I am not counting the various publishers who have printed the Linux HOWTOs, Guides, manpages, etc. because those were not new material at the time they were published in printed form. For the same reason, I have also omitted the Free Software Foundation, which has been publishing printed copies of its own manuals for years.

Obviously, from the point of view of the publishers, it works well enough to stick their financial necks out to print the copies. It would be interesting to hear the pros and cons from a financial viewpoint. But what I really want to know is whether anyone has found a way to blend an open license with a print book in such a way that the open source community feedback has continued to improve the text after print publication. There are a lot of worthwhile documentation projects that are too big for a single person working part time on them. A positive answer to this question could encourage them to happen.

HTML Books

When's the last time you read a book that came as an HTML tarball?

Like the GNU Make book ? (The GNU version, not the ORA one).
In that case, it can't be more than a week or two.

HTML Books are cool. I wish that ANSI/ISO would work that out. I'm still using the Draft C++ standard bcs I can get an HTML version of it. I'd happily pay for the final standard, but I'm allergic to PDF.

Don't Forget to Register Your Open Texts and Sites

Note that an Open Content license work is only Open Source if the copyright holder does not elect to use either of the options.

Don't forget to register your open texts and open web sites: At OpenContent.org [opencontent.org] there's a database specificaly for works under the Open Content license, and of course you should also register them with Freshmeat.net [freshmeat.net].

The database at OpenContent.org is pretty impressive but a lot of existing Open Content titles are missing from there.

Thanks

Bruce