October 2006


You might know that being an Open Source developer in general, and a Scribus developer in particular, allows you to travel all over the world, meet interesting people and have a nice dinner with them. This time I attended the GNOME Live! summit in Boston at the MIT. Thanks to Behdad Esfabod from Pango and Ed Trager from Unifont it also hosted the first FLOSS Text Layout Summit this year; and that was the reason for me being there (notย  to prepare for porting Scribus to GNOME and notย  for a tea party ๐Ÿ™‚ ). Also attending where people from Qt, KWord, fontconfig, SuSE, DejaVu fonts, and SIL. So what was this about? You probably all had your share of font related problems, so it should be no surprise we talked about that — a little. The major part was concerned with international text layout. Ed Trager wrote a nice introduction on what this is about. If you are only familiar with Latin script, read in this article all about writing directions and how characters change their shape according to context. International layout usually includes the following steps:

  1. Itemize — find runs of characters which have the same script and font
  2. Shape — apply script specific substitutions and positioning
  3. Find linebreaks — most applications use the simple and straightforward approach, but Scribus will do something more sophisticated soon.
  4. Justify lines — by extending spaces, scaling glyphs, substituting glyphs or by script specific means, e.g. Kashida in Arabic.
  5. Render glyphs — that’s easy once you have all glyphs with their exact position and size.

Currently there exist three different libraries for international text layout (Pango, Qt and ICU) which all have their pros and cons. At the text layout summit we found out that we all share the common vision of a unified library. Why is that? Well, first of all, writing such a library is hard. Also you need a lot of people to check the results for each existing script. Second, there are still many scripts which are not supported yet, and the hope is to support scripts faster if we combine our efforts. Finally, users don’t appreciate if their native language works in some applications but not in others, just because they use different libraries. You can see this within Scribus if you compare for example Arabic text in StoryEditor and on canvas (The SE uses Qt and displays Arabic correctly).
But we also reached some decisions. As a first step we will write a unified shaping engine. I was surprised how fast the Qt and Pango developers agreed on a common datastructure for such a library (well, that’s only tentative, but I expected some long discussions there). Trolltech said they would consider relicensing their shaping code in Qt so it could be included in a common library. Finally we decided to develop the unified shaping engine on top of HarfBuzz. HarfBuzz is a library which handles OpenType tables and is already used by both Qt and Pango. The unified shaping engine will also be called HarfBuzz and will initially support OpenType fonts. Legacy Type1 and TTF fonts can be used for basic shaping in Latin script and for Arabic if they contain the necessary Arabic presentation forms. Later we also want to integrate Graphite, a new open source font technology from SIL, and platform specific glue code for AAT (Macintosh) and UniScribe (Windows).

Ah yes, in the future Scribus will use this unified shaping engine directly. KWord decided on using Qt, and most other applications will also use either Qt or Pango. There was also some interest from FireFox, OpenOffice, Inkscape and Abiword developers, but so far I can’t tell if they would use the new unified shaper directly or not.

Well, what else? We have a combined planning/agenda/minutes webpage. There are also links to some slides and audio recordings of most talks.

The organisation of the summit was not as good as LGM, though. Ok, there was free lunch (American pizza for all), but we had trouble to use a projector, had to organize audio recording ourselves, could only find (near dry) green and yellow pens for the whiteboard and worst of all: no coffee! At first I hoped I had discovered a very geeky coffee machine in one corner of the MIT media lab, but that was just a liquid nitrogen tank. ๐Ÿ™

But all in all, very nice people, very geeky setting, very good dining, and interesting and productive talks. And I had ExScite as my private sightseeing guide on my last day, thanks ExScite! ๐Ÿ™‚

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.