May 2006

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

And a “Thank you, Peter” for the great work you are doing for Scribus. If there are two things most software developers (and FOSS developers in particular) really don’t like to do, it’s writing documentation and regression testing. The Scribus project is very lucky to have Peter, who does not only do a fantastic job with both, but also is an excellent promoter for the Scribus case, and — last not least — provides invaluable background information on the pre-press business to us less experienced developers.

So, a great round of cheers for Peter! We’re all looking forward to another exciting year of team work together with him.

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.


Yeah, seeing MrDocs’s first blog leads me to add a note about CMake as well. Honestly, the autotools system that we inherited was utter crap given its complexity, however it did probably serve its purpose well in its intended environment (building part of KOffice/KDE). It was overly large and for the autotools newbies, a real barrier against making changes to Scribus. Ok, adding a single file was generally ok, but we saw issues with moc running, uic running, and most of all tree-based file locations and adding new checks for dependencies.

Our CMake system is not finished, but its doing a good job so far. It took me about a week from CMake newbie status to at least generally understanding how it works and having Scribus building. Running the very latest CVS was a major help as the KDE guys have switched and enhancements they required helped me out. Once CMake 2.4.2 flows into the distros out there, we will more than likely dump autotools completely, so whens that? Well.. Maybe after 1.3.4 is released.. but you never know…

Repeat after me:

Cmake Rocks

Cmake Rocks

Cmake Rocks

While we named this new blog rants, let’s start by praising something which makes developer’s daily grind a little less of a grind. Cmake is exactly that. A dev friendly replacement for traditional auto* tools.


  • The CmakeLists.txt files are models of clarity and only require you to add the name of a file once, where requires three different entries for a single file.
  • Speed – on my quite ordinary Linux system it takes 5-7 seconds to generate all the makefiles for Scribus, compared to 30-50 seconds for auto*
  • Much more useful error messages when you make a mistake in editing files. Auto* error messages have been known to drive developers to a state of madness trying to fix the errors.
  • Smaller makefiles. 57kb for the main Scribus makefile from cmake vs 257kb from auto*
  • In the future, compiling Scribus with cmake is as simple as: cmake .

It took me about all of 10 minutes after installing cmake to be able to grok and hack on cmake files in our source code. That rocks.

Last week I implemented “optical margins” in 1.3.4cvs. So I’ll use my first blog entry to describe what that’s all about.

When you look at a newspaper, or a Scribus document with justfied text, you might notice that the left margin looks much straighter than the right one, even if all chars line up geometrically. That’s because most characters line up nicely at the beginning of a line, but a lot of characters leave an uneven appearance at the end of the line. Most notorious are punctuation characters: hyphen, comma, dot, quotation mark, and others.

An old technique to repair this is called “hanging punctuation”. This moves the offending punctuation marks into the margin. Unfortunately, this doesn’t look quite right (you can verify this if you activate that option in InDesign). The solution is to move the punctuation marks only to 50%-70% into the margin. This is how it works in Scribus 1.3.4cvs (PDF, sla). I copied the exact values from Hàn Thê´ Thành’s PhD thesis “Microtypographic extensions to the TEX typesetting system”. He implemented this technique in pdftex.

But also characters like ‘f’ and ‘r’ contribute to the uneven appearance of right margins. Moving those characters (very slightly) into the margin is called “margin kerning”. Since characters might have very different shapes in different fonts, I don’t use fixed percentages to move those into the margin. Instead I use a trick: I use the font’s kerning information for the pairs “f.”, “r.”, and so on. Maybe in the future font designers will include information for margin kerning explicitly in their fonts, but for now I’m quite content with my implementation. I only use margin kerning for the right margin, though. The left margin is usually quite smooth, except for characters like ‘A’, ‘W’ and ‘V’.

Currently there’s no option to deactivate optical margins in Scribus. I’ll add that later, and probably also options to finetune it (change the percentages for hanging punctuation per font, activate margin kerning for the left margin).

So tell me what you think about it and how I can improve it further.

Is that all? No. First, I fixed a bug in Scribus 1.3.3 which messed up right margins by placing hyphens irregularly. Hey, all that work with optical margins is for nothing if Scribus places hyphens randomly anyway! 😉
Then, Hàn Thê´ Thành describes another technique called “glyph extension”. This stretches or shrinks characters by -2% to +2% in a line, in order to avoid large white spaces between the words. This glyph extension won’t be visible to the naked eye but will help to get a more even word spacing.
Now, speaking of word spacing, isn’t TEX supposed to have a much better algorithm for linebreaking, which was also adapted to InDesign? Yep. TEX and InDesign optimize linebreaks for a whole paragraph. That results in a much more even word spacing than is achieved by the straight forward algorithm used by Scribus and other layout programs. Used to be used by Scribus, I should say, since we have a prototype of a new text layout system which supports this optimisation. Currently, the prototype is lacking some standard features of the old layout system (like non-justified alignment, tabs, drop caps, and some linespacing options). Once this is done we’ll merge it into cvs, so there’s something you can look forward to!

Ciao for now

Finally we made it online with a blog. Well, everyone else is doing it. Time to have our say to all the people who might bother to read it.