It is hard to believe Scribus is almost an adolescent. Just yesterday, Scribus turned ten years old, with the first bits of code written by Franz Schmid in December 2000. A few months later, it was linked on Freshmeat and then, well… it kind of had a life of its own. I googled DTP and Linux and stumbled across the link to Franz’ home pages. Of course it would not compile… (User error on my part.)

However, after posting a short e-mail, during the time of dial-up internet, I got an almost instant reply with a: the correct fix b: a question I cannot remember exactly, but well, it struck me as the right kind of question.So a good sign.

Not long after that, began a long series of e-mails about page layout, PDF and design over the course of probably 2+ years. It was clear way back then Franz had the singular idea to create a page layout application with a robust powerful PDF engine. Then and now, it was a brilliant design decision in my opinion.

There have been some memorable moments:

The release of 1.0 which got the front page of slashdot and took out the community ISP in his town for 3 days and oops, my most important clients’ web server traffic climbed 5000% in a few hours, as all the screens shots were directly linked.

One other strikes me is testing a pre 1.0 version of Scribus in my client’s service bureau and seeing the color managed preview nearly perfectly matching the PDF output in a RIP.

Booting the first native port of Scribus on Windows (thanks Jean) and OSX (thanks Andreas)…

Another one is seeing LGM #1 come about from some idle chat in IRC. We expected an attendance of 50 to arrive and got 200..

Finding this mysterious character Ltning show up on IRC with an offer of lots of shiny gear for hosting us and delivering the goods.. for years on end now… I’ve yet to meet him in person, but already I know could give him my wallet and not worry.. Apparently the banks in Norway feel the same way 🙂

In the intervening years, Franz,  Craig, I and others, along with our families have shared holidays together; quite a special thing to see when it all began over the Internet – across continents no less. Even better, we are still involved daily, because we have a lot of mutual respect and the bonds of friendship, but its still fun!

So, here is a virtual tip of the hat to Franz, Craig, Petr, Christoph, Andreas, Jean, Pierre and the others. Keep on rockin’

One of the things we have always been quite proud of is the community which has developed around Scribus: the lively and flame free mailing list, the busy and accessable IRC channel on freenode.net and not least the number of user contributions to the wiki, templates and other sample files.

We have never called for financial support for Scribus before. Now we are. There is a simple and easy way to help, not just the Scribus Team, but all the other free and open source graphics applications you probably use with Scribus. Collectively, we and the other teams have organized a community fund drive to help sponsor the costs of the Libre Graphics Meeting.

The Libre Graphics Meeting brings together developers and users of free software graphics applications, such as the GIMP,Inkscape, Scribus, Blender, Krita, the Open Clipart Library and more. For the first time, we are asking the community to help support this meeting.

What is the Libre Graphics Meeting?

In its third edition, the organization needs your help! You can support your favorite graphics application, and ensure that the travel costs of as many volunteer developers as possible are paid to ensure that this edition of the conference is as successful that its predecessors. The conference is May 8 – 11 in Wroclaw, Poland.

Where will the money go?

We have kept costs associated with infrastructure to a minimum. Over 80% of the conference budget will be spent on subsidizing travel and accommodation costs for developers. $20K is the goal to raise by Friday April 18! Already over $ 7000 has been raised in a just a short few days, which is humbling to see so much support so quickly. But our goal has not been reached yet and you can help.

So how does it help Scribus ?

For the team, it is the most important venue for us in the year. It allows us to collaborate with face to face, both as a team and with other teams. A couple of concrete examples:

At the first LGM, Marty Maria of Littlecms gave an excellent overview of color management use for developers. One of the issues we were struggling with was occasional crashes with non-conforming color profiles which were difficult to prevent. During a side session a couple of Scribus developers walked through how Scribus was using littlecms and Marti pointed out some special error checking code he had added to littlecms. He guided us on enabling it and a few days later Scribus now had the “self-defense” code to prevent bad profiles from causing a crash. When the Lprof developers were having the same kind of issue, we pointed them to the new code in Scribus which solved the issue.

During LGM2, we had some informal late night discussions with some Inkscape developers on the importance to add color management into Inkscape. We talked through some of the challenges and also walked through where we could improve SVG import. Since then, Inkscape has made its first foray into color management and Scribus has a more capable SVG importer.

These face to face meets, as we have learned, are vitally important to accelerate the progress of development, which in the end means better applications for everyone. 🙂

So how does it work ?

Simply go the Pledgie Page for LGM and make your contribution.

A non-profit organization

All donations will be made to the conference organizers via the GNOME Foundation, a 501(c)3 tax exempt US-based non-profit, so donations will be tax deductible for US taxpayers. We would like to thank the GNOME Foundation for their support.

Thanks for your support!

During the release party for 1.3.3.10 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.

One of the things which is perceived as a stumbling block to using Linux as a designer’s platform is the lack of font management tools. Most graphics professionals started or at some time worked on a Mac and often enough MacOS 9 or earlier.

So, while font management is nowhere as difficult on Linux as it might be assumed since the arrival of Keith Packard’s fontconfig, it is a perception thing. Moreover, KDE3 for a while, now has a simple and very effective font manager/installer called Kfontinstaller. I have commented elsewhere that I think it is the simplest and most user GUI friendly font manager on any platform. It is a font manager with no extra bells and whistles. To boot, Linux can run with lots of fonts installed with no large performance hit – unlike earlier graphics apps and older Windows versions.

Getting back to Macs, and in my experience with production workstations on Win32 , a 100% certainty was the need for a third party font manager. Most of the time either Suitcase or ATM sufficed. They made it manageable to use and select from more than a few hundred fonts.

Plus, fonts on pre-OSX Macs had a nasty tendency to corrupt themselves every once and a while. Most of the older font managers had tools to try and fix this too. Something which one should never worry about happening on Linux. 😉 As you can imagine over time doing layout professionally you tended to end up with hundreds if not thousands of fonts installed. Not good for performance and a nightmare to manage without third party tools.

Given all that, one can see why graphics and layout folks are asking: “Where is the font manager ?” In a sign of the increasing maturity of open source as a graphics platform, there is now a real font manager built with the kind of features and abilities graphic designers, layout pros. along with others have felt necessary, but modernized with some new touches. Introducing Fontmatrix. 🙂

fontmatrix1.png

One thing where Fontmatrix has the older proprietary managers beat is the concept of ‘tagging’. This makes it really nice to group fonts and even sub-group them logically for use in say a book. It also has extensive support to give you a nice gui to show all the glyphs in a font, previews of sample text, variable sizing and also tell you what kinds of advanced Open Type features are inside the guts of your font. That is something I’ve never seen outside of a font editor. And not least, it creates a nice PDF catalogue of your fonts for printing or reference. All in all, a real pro’s font manager, but still nice and user friendly.
Fontmatrix is still young, but it does not crash for me and it works really well already. For installing ease, I have packaged it for Suse 10.2+ and Fedora 8 on the OpenSuse Build Service which I have talked about before. Enjoy.

This is just a quick update of the ongoing LGM2 in Montreal. Some last minute complications prevented all the Scribus team members from being here, but LGM2 has been an excellent meet so far. In brief:

  • We have announced the latest release of 1.3.3.9, 1.3.4 and the first public demo of 1.3.5, the port of Scribus to Qt4. The port is not complete, but Scribus compiles, loads documents and runs under Qt 4.2. Packages and source will available soon.
  • We saw Raphael from LeTigre give an excellent talk about how LeTigre has been produced using 100% FLOSS graphics applications.
  • The Krita developers give a well organized talk about the future of their painting/image editing application.
  • Louis Soares-Potts gave a presentation about the importance of Open Document format. We had a very interesting conversation about how ODF is used with Scribus and how we can better use ODF for not only import, but export for some use case our future plans with ODF.
  • The GIMP team has shown up en masse and we have had a bit more time to chat together informally. I hear the gimp developers want gimp 2.4 be out very very soon.

This list is far from complete and more to come…. Montreal has been a great host city.

While we recently released 1.3.3.7 into the wild, one of the tools we used for the first time is the new OpenSuse Build Server. So why the rant ?

In a word it is terrific. 🙂 It still is in “beta” phase and there are features to be added. However, it is a major helper for time stretched developers to package their application in a sane way and then automagically push them to rotating mirrors worldwide without a lot of fuss.

It is all fine and well if you write the best code in the world if no one can use it. And that means packaging. For Linux, that means creating a .deb or creating rpm packages which many Linux distributions use.

The magic is one can upload the source and a spec file which is a recipe to build rpms. Select which platforms to build, push a button and voila. In an hour or two you have all your packages built in a carefully controlled manner. This allowed us to supply 1.3.3.7 for all Suse releases 9.3+ including the Enterprise Desktop 10 for the first time. Even better for users, they can use what ever tool be it Yast, Smart or Yum to add these repositories to get the latest greatest Scribus with all dependencies automatically satisfied. Push button packaging for users too 🙂

In part two, I’ll explain the master plan and I’ll rant a bit more about why this is all a Good Thing â„¢

So a big thanks to darix, adrianS and the Build Server team for making such a nice tool and allowing us to play.

We rant and rave about Scribus’ PDF quality and its ability to make commercial grade PDF by mere mortals. A design decision made early on to focus on robust PDF export was in hindsight a brilliant one by Franz. OK, now that is one side of the PDF coin. The other side is parsing and editing PDF. A task even more complex in some cases and in no case trivial.

We often get asked when Scribus will edit PDF and if there are tools which will do it easily and are open source. The first answer is eventually – but it will not be easy, given the team’s collective knowhow about PDF. The second is nothing open source beyond some minor manipulation like splitting, merging and some imposition. And while Acrobat Professional can do some limited PDF editing, it cannot do everything. PDF editing in the way most people perceive is the realm of pre-press specialist Acrobat plugins which are expensive and require some knowhow of pre-press and commercial printing. They also require Acrobat Professional.

Today, I had a chance to get a cvs build of PoDoFo and its GUI browser running which uses cmake and Qt4. PoDoFo is the first serious attempt to write an open source pdf library and tools which can both parse correctly the internals of a PDF and edit PDF. 🙂

 

Podofo Browser walking through the internals of a Scribus created PDF

Above is the PoDoFo browser tool. To the untrained eye, you’d say “So what?” To the trained eye what you see is the ability to parse, select and even edit the contents of a PDF. Things like extracting and replacing images. Or eventually re-embedding fonts. Or editing the text within the PDF. Or …
So what it is about PDF that makes it so difficult to edit? Simply parsing PDF correctly is difficult enough. One, it is a non-linear format. You can put the fonts after the text and put the images above them if you want. Content is embedded in what are known as streams and one needs to decipher on the fly the type of stream it is, how it is compressed and where it belongs in the file, along with things like how it is displayed. Oh and objects are reusable too. You cannot simply fire up your preferred editor and start hacking.
PDF was always meant to be “Electronic paper” if you will. In final finished form the idea is it will display the same everywhere no matter what platform or device. (You can display PDF in a Palm Pilot easily.) It was never ever meant to be edited once created.
As I said, not trivial. Then, even if you figure all this out, then you need to reassemble all these bits in a PDF coherent way which won’t break when reloaded in a viewer.

So, PoDoFo is the first real open source PDF editor. Plus, it comes with some other very useful tools for PDF. It will be in the future I hope a PDF library to allow lots of applications to create high quality PDF with the same kind of simplicity and robustness Scribus has now. The key thing is now it is able to get to the much of the low-level bits inside of a PDF. From this lots of magic will come in the future I am sure.

Ready to do some surgery on a PDF ?

One of our translators and contributors mentioned to me that they had comments to the effect that Scribus is a “closed shop”. In other words, the team is really not open to adding new developers and contributors. So let’s dispel that rumour right now.

It is not true. Not now, not before, never.

To an outsider, it might appear that way, but not by intent. The Scribus Team is probably a bit different than most in that we are a bit older, perhaps than the average OSS team. Several of us have a few grey hairs on top – but that is a Good Thing for many reasons. 🙂

Our experience in various parts of graphics and pre-press has given us a sense of direction about what not only Scribus needs, but what to avoid like faux bold and italic . Sometimes avoiding the same architectural and “feature” errors we’ve suffered as users in the past is just as important as ultra coding foo.

One other thing which is important to understand that we do work very harmoniously as a team. We share the same core values of respecting our users and each other’s unique talents and capabilities. We choose, compliments before criticism, cooperation instead of flaming and division. This, I think, is transmitted through in the way the community surrounding Scribus has grown. Note the lack of flame wars on our mail list. That is something I think we can be proud of and if we are protective of that – so be it.

However, get closer and you will see that Scribus is far from a “closed shop”. Surrounding the core team is a larger circle of folks whose contributions are not only valuable, but necessary. One look at Help > About, the mailing list or a look at the Wiki is evidence enough for me.

To the contrary, we do want more coders, more translators, more packagers and folks to help with testing bugs. Jump in! The water is just fine.

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…

Next Page »