Graphics & Colors

Now that 1.3.5(1) is released, development has regained speed. Here’s a short overview of what has happened recently in 1.5svn and Scribus in general:

  • Scribus founder Franz Schmid returned from his well-deserved break with a big bang, the latter being experimental code to embed 3D objects in Scribus-created PDFs.
  • Franz also wrote import filters for Calamus Vector Graphics (CVG), WordPerfect Graphics (WPG) and Apple PICT files. The quality of those filters is already superb. Along the way he also created an import filter for colour palettes from Viva Designer.
  • The code of a successful GSoC 2009 project has finally found its way into 1.5svn, namely export to PDF/X-1a and X4.
  • The first part of another student project, an import filter for QuarkXPress Tags, has also been finished, and we expect to add the filter to trunk soon. The student, Jain Basil, is now working on a second import filter for InDesign’s IDML format and hopes to tackle the older InDesign INX format, as well as Xtags, later.

We are also glad that the release of 1.3.5(1) has found an overwhelmingly positive reception in the news outlets, from the Free Software press to magazines for professional publishers.

Finally, we are glad that more companies decided to support our project:

  • The German colour vendor Marabu provided us with colour data for the company’s colour sets, which have been exclusively measured under different lighting conditions for Scribus.
  • dtp studio Oldenburg, another German company, which is in the business of measuring, creating and commercially distributing colour palettes, colour software and colour atlases, donated a huge chunk of colour palettes and will also officially support Scribus, which means that Scribus users will be able to buy additional palettes that work with Scribus from dtp studio.
  • There’s also good news for those who use Scribus on OS/2 or eComStation, as Serenity Systems donated free (as in gratis) licenses of eComStation to the Scribus Team to help with porting Scribus and Fontmatrix to this platform.

And let’s not forget to mention the operator of Vector Portal who agreed to help us with the creation of attractive templates for business cards and presentation templates. Lest we forget: We’re also working on other sets of templates for magazines, brochures etc.

Does this sound good? There’s more to come, stay tuned!

We all know the saying “sometimes life gets in our way,” meaning that something didn’t work as expected. Scribus is no different, although in our case one major fact of “life getting in our way” was newly born (or soon-to-be-born Update: useradd -groups vanek,boys -c "23.07.09 7:00am; 3.2kg, 0.5m" filip) babies, meaning an all-out positive distraction. There were other reasons, of course, that led to the delay of 1.3.5’s release, but after a long time of frustration with the progress of the code, we now have a lot of reasons to expect a bright future for our project again.

What has happened?

  • Especially thanks to the infatigable efforts of Jean Ghali (jghali), Craig Bradney (MrB) and Pierre Marchand (pierremarc), 1.3.5 is 99% finished now. The number of bugs they have quashed over the last 12 months is simply astonishing!
  • Google enabled us to add some really unique features via its Summer of Code programme, among them support for an almost infinite amount of markup languages like LaTeX, Lilypond or POV-Ray, or import of CorelDraw files, as well as a huge list of other vector or bitmap file formats.
  • This year, the Scribus Team was confronted with 6 GSoC applications of equal quality, but given the large amount of applications, the Google selection process required us to select four students, which turned out to be very hard. Fortunately, we have good and reliable friends in India, namely Sarai. Since most of this year’s applicants were Indian citizens, Sarai, in cooperation with NIXI, enabled two other students from India to work on a Scribus-related project by means of a fellowship.
  • The author of this rant has contacted colour vendors all over the world and asked for digital colour palettes of their proprietary colours under a Free license. The reactions, so far, have been mostly positive, but in most cases, the licensing conditions still need to be negotiated. The major exception here is the New-Zealand-based colour vendor Resene. The company didn’t hesitate one second to support Scribus, and their willingness to cooperate and their speed, as well as their professionalism, left me speechless at times.

All that being said, and with a big Cheers to our supporters, I’m more confident than ever when it comes to the future of our project.

During the release party for Jean Ghali one of our quietest but steadiest developers (he’s slaughtered a mountain of bugs in 1.3.3.x), noticed that we were about to pass our millionth download on Sourceforge. Which got me thinking…

A million downloads for a project like Scribus. What is the significance ? What does that tell us ?

The technical part: Just shy of 20TB of data. Or looking at the rough averages currently, one person downloading a copy of Scribus every two minutes or so. Two years ago when we started hosting our downloads on Sourceforge we averaged 4.5Gb of data. Now we’re getting close to 2TB some months and the trend is steadily upward.

Moreover, those numbers are actually lower than reality when you consider it only counts downloads of Scribus after 1.2.something and we host a lot of binaries on the OpenSuse Build Server and we also have a separate Debian/Ubuntu repository. Lastly, almost every Linux distro includes Scribus by default.

So, where does that leave us ? What does it tell us ? The plain numbers are kind of dull and boring, but what it represents in the bigger scheme of things is that a complete and very healthy ecosystem has evolved in the area of Free and Open Source graphics applications. You can do serious professional grade publishing reliably using only open source tools.

When Scribus was started there was GIMP and a then sometimes rough on the edges Ghostscript, but not much else. No Inkscape, no Krita, no Fontforge, a dearth of decent professional grade fonts and very few which were really capable beyond Latin and CJK languages. Font managment plain sucked. Keith P. will go to heaven if only for making fontconfig and thus font installation sane on *nix. Early Scribus had all kinds of hacks and code just to find fonts, not any kind of sanity checking or other goodness we can now do with Freetype2.

Which leads us to today, where we can see GIMP getting GEGL and its long promised deep color spaces. Krita2 in a short few months will have a lot of goodness Scribus users will really groove on (and it might be really running stable on Windows.) Inkscape is making its first baby steps in adding color managment and they are really trying to make it work perfectly for Scribus downstream. Lprof, the color profile maker now is cross platform and is getting hardware support for pro grade colorometers.

Even better is the community of people who have emerged around Scribus and other FLOSS graphics apps. We have things like Fontmatrix which I ranted about earlier popping up out of nowhere to complete the scenery. LGM 1 and 2 were great and I fully expect LGM3 to meet or exceed them.

What that million means is are now enjoying what was just something we could only dream of when Scribus 0.2 (~ 150 downloads) was so modestly launched in 2001.

This afternoon and tonight, I had a chance to thoroughly beat up on a very recent snapshot Krita 1.6svn 🙂

What I wanted to see was if I could at last do simple RGB to CMYK conversions and

  • Avoid diving to the command line.
  • Would be usable and understandable for mere mortals who are not color management geeks.
  • Do this in simple 1,2,3 steps that could be explained to Scribus users for reliable transforms from RGB into CMYK.
  • Display reliably in Scribus what would end up coming out of commercial printer.

Krtia succeeded with flying colors.

Now, with Krita 1.6 installed you can take any decent RGB jpeg, png, PSD or tiff open it and convert it to CMYK and then safely, reliably save it as a CMYK TIFF which then imports into Scribus without a fuss. My first tests show that the images in the PDF’s exported look exactly like the original RGB jpeg and PSD files I opened in Krita. As close I get when doing the same in PS6.
The official announcement awaits, but it should be out and available packages soon.

I’ll rant more later about the details 😉
This is a huge step for open source graphics. Huge.

One thing about GIMP which generates lots of virtual ink, but not much enlightenment is the lack of CMYK support in GIMP. Post a subject on slashdot with OSS + graphics and watch the flames begin… About 50% of the Scribus 1.0 story was GIMP vs PS flaming… Sad.
Many many people have moaned, complained and sworn off GIMP for its lack of CMYK and/or other perceived deficiencies, yet the number of people to step up and put the effort to make it a reality seems to me awfully small.
In hindsight, both working on Scribus for more than 5 years now and in pre-press longer has led me to the opinion that adding CMYK to GIMP prematurely would have been a disaster.
My observations:

  • In defense of the GIMP developers, I too would be really sick and tired of people coming on IRC, or various mailings and asking/demanding/complaining about this feature or that feature. So, if they are less than polite when you are person number 998 to ask/whine/demand/plead for the same thing that is entirely understandable. You are at fault for simply failing to google the question. The answers are there…
  • Unlike 99.95% of the people who have used, flamed or discussed GIMP, thanks to LGM, I have actually met a fair number of the GIMP developers face to face. They are nice people and they did a terrific job organizing LGM. We could not have been more welcome.
  • Trust me, they know CMYK support is a long standing request. They are neither blind, nor idiots and perfectly well understand why it is so sought by end users.
  • Those who have not worked on a project like Scribus or GIMP or Inkscape may not be aware how difficult it is to make CMYK work properly. We are rightfully proud of the CMYK and color management capabilities in Scribus. But it is not perfect and we still have more work to do there. Thanks Marti.
  • I think they are not only correct, but completely within their rights to say they do not wish to make a Photoshop clone. You know what? Photoshop, while it wonderful for some things it is far from perfect…
  • I use both, side by side and they both have their quirks and oddities, There are things GIMP just does better, more efficiently than PS. GIMP’s ability with retouching old photographs is extremely good and its handling of PNG is superior in my experience. The new screen grabber in 2.3.x rocks.
  • Users running GIMP on Windows complain about all the palettes and the lack of SDI (Single Document Interface.) While I don’t like MDI myself, the GIMP developers are correct: Windows has a sucky window manager. What is also interesting to note is that PS 6 and 7 run perfectly well on recent versions of Wine — thanks to Codeweavers. Guess what? All those PS palettes are not so nice under KDE or Blackbox on Linux 😉 A perfect example of an application working in an environment where it was not really designed for. A note for all future or potential reviewers of GIMP, please test it on Linux or some Unix with a decent window manager, it does make a difference.
  • Those who complain how it runs on OSX or its lack of native port should: 1) Complain to Apple to make their X-11 work more seamlessly with Aqua. 2) Give or loan a pile of well equipped OSX boxes to the GIMP team and while you are it, start or pay a team of experienced developers to port GTK2 to OSX.
  • Both PS and GIMP are complex applications that take time to master. For longtime Photoshop users to try GIMP for a short time then reject it out of hand are just as ignorant of the GIMP fanboys who blindly recommend GIMP as a replacement for PS. Sorry, it is not. The GIMP developers have no shame in that being so… You have to “Think Differently”, to borrow a well known tagline 😉
  • CMYK and spot colors by themselves are not patent encumberd. They are actually part of the open published standards for Postscript and PDF. Anyone saying anything different is clueless or spreading FUD and/or openly demonstrating their ignorance of the fact.

So it might be useful to ponder a moment, why Scribus was able to integrate CMYK and color management seemingly so easy? A good question and the answers are hopefully instructive. The most important? You need the correct development environment that can support adding and maintaining such a feature, the lack of which is not the fault of the GIMP developers:

  • Unlike GIMP, CMYK was from day one a necessity for Scribus. Scribus without CMYK and spot color support equals Scribus being a less than useful toy. Adding useful color management makes that so much easier. Having littlecms as a drop in library to handle all the CMS chores is truly a gift. GIMP and Inkscape are truly useful applications of their own, right now, for a huge audience without these features.
  • You need developers who have pre-press and print design know how — very different from RGB/Web/Video image editing. Jean on our team probably does have Video/Web imaging foo (he’s a pretty skilled imaging engineer, but I doubt the rest of us would be a good team to write an image editing app or something like GIMP GAP.)
  • You need end users who understand how to use these features properly, willing to dedicate time and effort to test and guide the developers where they are right and wrong. Thank you Louis, Christoph, Maciej, Johannes and ExScite among others for relentlessly thrashing CVS.
  • You need a testing environment which is capable of testing CMYK output in a realistic fashion. We were blessed early in Scribus’s life to have clients who allowed me in early days to run and test Scribus in a real world pre-press environment where you could compare Scribus’s and other application’s output side by side. Bring heaps of money to recreate that from scratch. 😉
  • Think about spending tens of thousands in special pre-press software and special equipment. Then, a bunch more time to learn how to configure and calibrate these bits properly. It took the better part of year studying and testing before rolling out my first real color managed workflow. Even then it takes time to keep up with the latest CMS development and standards.
  • The current GIMP developers inherited a code base with 8 bit color. Implementing 16bit and larger color spaces on that code base is not trivial. For some parts of the GIMP, I would imagine there are parts where a complete rewrite is in order. The efforts they put into improving 2.0.x and 2.2.x were far more valuable for a very wide part of their user base. Stability and hundreds of other upgrades small and large benefit all users. I cannot remember the last GIMP crash in 2.2.x.

So, now before ranting about the lack of CMYK or spot color support in GIMP, maybe you might have a more realistic understanding of the undertaking. I’m perfectly content with GIMP now and I only expect it will be better in the future. The revitalization of GEGL is a big step. Maybe, GIMP 2.6 or 3.0 will have CMYK and spot colors. I expect when it is added it will work pretty well right out of the box. That’s worth waiting for…

Layer transparency revisited

Today i have something for the ones who are waiting impatiently for the new layer transparency features, the first screenshots of them ever.

For those who want to have this now on their own systems let me tell that this is highly experimental. First you need to check out the latest cairo version with git and have to patch the file cairo-features.h that it reports a cairo version 1.1.8. Second you need the very latest Scribus-1.3.4cvs sources.

But the results are very promising now, i only have to solve some minor on screen mispaintings. Working on this was also very good in another area of Scribus: the PDF-Export. I was able to fix the longstanding issue that RGB PDF files with transparency showed up in Acrobat Reader 7 with wrong colours.

And now for the pictures:


Two layers, the stars are on the top layer, which has the “Difference” mode assigned

And another feature that is utterly wanted by some people:

An Overprint Preview on screen

overprint1.png overprint2.png
The on screen preview The same with the regular postscript preview

In this short article I want to explain why Scribus should switch to a cairo based rendering as soon as possible. There are many reasons for doing this despite some drawbacks. But I hope these drawbacks will soon disappear. Let us first look at the benefits of libart:

  • It’s fast
  • Libart has been around for a long time, well tested and stable
  • Can be found in about every distribution and is cross-platform

And now the drawbacks:

  • it seems that it isn’t maintained actively now
  • Sometimes hard to use/find advanced features as the documentation is weak or non-existant.
  • It is missing some advanced features like blendmodes, clipping paths etc..

Cairo is instead a modern, completely developed from scratch rendering library. It’s still under heavy development and has a very active community. Furthermore, the developers are very cooperative in terms of suggestions and feature requests. For Scribus, it would be a very good thing to switch completely to cairo. With the current 1.1.6 version of cairo there is no more excuse not to use it as cairo is now available on all major operating systems. It would greatly ease coding, no more #ifdef HAVE_CAIRO in the code. Second, the code would be much more readable, as the cairo library has a very clean API, which is very close to the Postscript syntax.Instead of boring you with more rants, I’ll show you some differences with a few pictures… a picture says a thousand words….

Rendering Gradients
Both images show a gradient starting with 50% black and ending with 50% black (yes, that’s not really a gradient but should produce an even gray rectangle).
On the left side is the libart one, on the right side the cairo one.
Libart Gradient Cairo Gradient Sample

You see that cairo does exactly what you expect for a gradient like this. libart instead seems to have a bug here, and we do not expect that this will be fixed ever.

Another cool feature that has been added to cairo in their current development snapshot is the push_group and pop_group feature. This does give us the possibility to add real professional transparency features to Scribus. In particular it enables us to add “Layer Transparency” and “Group Transparency”. And if the cairo developers would add more blendmodes we can get very close to the features other proprietary page layout applications.

Normal Transparency Layer transparency
Normal transparency,
2 Objects with 50%
Same objects on a layer
with 50% transparency

This layer transparency feature can also be used to implement an “Overprint preview” mode, i already have the needed maths for this special blendmode. BTW: The current CVS version of Scribus contains already a basic preview mode when build with cairo support.

Final Thoughts

I can’t wait to get hands on the final 1.2 version of cairo. When this release is out we should definitely switch…no more libart woes.