Kudos


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.

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 ?

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.

Well, we said CMake rocks, but after the time we have used it, we have generally come to like it. So far it has provided our escape we wanted, and given us more flexibility and ease of build system modification. A generally good experience all round you could say.

Well thats all very nice, technically, but this post is just a big thank you to the CMake team that have helped me with the migration task, and in more recent times, quick fixes into CMake, and fixes into our CMake setup. I had made some mistakes initially and it wasn’t until this week that I had time to track it down as discrepancies between building here and on other devs’ machines didn’t make sense. You know… clean checkout, clean build of CMake and Scribus… builds fine here. Same clean versions on another box… splat. In the end, it was a mistake in my code and the CMake guys spent the time to find it… simply outstanding support. Another vote from me goes their way.

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.

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.

Benefits:

  • The CmakeLists.txt files are models of clarity and only require you to add the name of a file once, where makefile.am 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.