GSoC 2008 Accepted Applications

This article is ARCHIVED. It is a part of the Scribus Community's history and is kept here for reference and as a representation of the contributed efforts. It is protected from editing, but its source can be copied.

Descriptions of the Scribus Team GSoC 2008 Student applications funded by Google for this year's summer of code. Progress on these project will be provided by our gsoc 2008 student coders. Stay tuned...

= ScripterNG - a new scripting plug-in for Scribus

Henning Schröder <henning.schroeder@gmail.com>

Abstract

Scribus shows that professional desktop publishing is possible with Free Software. But - in my opinion - the potential of the scripting interface is mostly underestimated. Other Open Source projects like Firefox, Blender, Inkscape, OpenOffice.org or Gimp have shown that having bindings to scripting languages results in many new features and make it easier for others to extend the functionality of the application.

The current Scripter plug-in has some limitations, a less than optimal architecture and is very difficult to extend. Therefore, I want to create a new scripting plug-in (called ScripterNG), which will also support QtScript besides Python and is easily extendible. Besides the technical aspects I want to make sure that extensions are easily accessible and configurable. Another important issue is integration. An extension should look native in Scribus and can hook directly into the GUI. To make the plug-in usable it has to provide a wide API which includes most of the functionality of the old plug-in plus many new features.

The current way of writing bindings by hand is very hard and error-prone. I ended up writing my own small system to dynamically access any Qt object. It requires sip (the PyQt bindings generator) at build-time and PyQt at runtime. Since QtScript also uses the Qt meta-object-system, one can get support for this EcmaScript-compatible scripting language without additional work.

The API has to be carefully designed to keep it stable across releases. Several people already thought about it and I will try to consider as much of the ideas as possible.

For a transition period old scripts for the old Scripter plug-in can still be used side by side with the new ScripterNG. I also plan to write a compatibility module.

Motivation

Scribus shows that professional desktop publishing is possible with Free Software. Scribus has many powerful features which are often mentioned in articles, eg. high quality PDF export and color management. But the potential of the scripting interface is mostly underestimated. The scripter plug-in is included in the Scribus main distribution together with some example scripts. However, from my point of view it does not get the attention it deserves.

Other Open Source projects like Firefox, Blender, Inkscape, OpenOffice.org or Gimp have shown that having bindings to scripting languages results in many new features and make it easier for others to extend the functionality of the application. People without knowledge of C/C++ but some Python, JavaScript or Perl skills can easily write import-/export-filters, create wizards, write plug-ins or create something nobody else has thought about before. The distributed scripts can be used without recompiling and often without knowledge of the scripting language.

Scripts can help to automate tasks and can adjust a program to the special needs of a user. It is also possible to test new ideas, as languages like Python are great for prototyping. And sometimes it makes more sense to stay with Python instead of rewriting everything in a compiled language.

Summary

The current Scripter plug-in has some limitations and a less than optimal architecture and is very difficult to extend. Some experiments with boost-bindings never proceeded beyond preliminary testing.

Therefore, I want to create a new scripting plug-in (called ScripterNG), which also will support QtScript besides Python and is easily extendible. I hope that this plug-in will catch-up with scripting solutions in other major software products. Besides the technical aspects I want to make sure that extensions are easily accessible and configurable. Another important issue is integration. An extension should look native in Scribus and can hook directly into the GUI.

To make the plug-in usable it has to provide a wide API which includes most of the functionality of the old plug-in plus many new features.

Architecture

As a general rule in software development, rewriting everything from scratch is a bad idea. But the current approach does not work anymore with the growing requirements of users and the growing code base. The current way of writing bindings by hand is very hard and error-prone. Automated systems exist (like swig and boost), and I have evaluated most of them.

Some are really interesting, but I ended up writing my own small system to dynamically access any Qt object. Like Smoke, Kross (http://kross.dipe.org) or PythonQt (http://pythonqt.sf.net, do no confuse with PyQt!), it uses the Qt meta-object-system. It requires sip (the PyQt bindings generator) at build-time and PyQt at runtime. I kept the base small and chose an approach where I can move things like configuration dialogs or a scripting console into Python extensions. Since QtScript also uses the Qt meta-object-system, one can get support for this EcmaScript-compatible scripting language without additional work.

The API has to be carefully designed to keep it stable across releases. Several people already thought about it and I will try to consider as much of the ideas as possible:

• http://wiki.scribus.net/index.php/Public_C%2B%2B_API
• http://wiki.scribus.net/index.php/ScripterNG#API_brainstorming
• 

For a transition period old scripts for the old Scripter plug-in can still be used side by side with the new ScripterNG. I also plan to write a compatibility module.

Roadmap

The roadmap tries to follow the proposed time line published at http://code.google.com/opensource/gsoc/2008/faqs.html#0.1_timeline

Work on the project will start in the middle of April (selected students are announced and the project can officially start):

First week

• Setting up the infrastructure (weblog, code repository, ...)
• Adding details to project plan about exact API, extension meta-data file-format, ...
• Publishing document on my research of binding technologies
• Getting additional feedback from developers and from the community about the project

Week 2-3

• Cleaning up current prototype of ScripterNG and epyqt (build system, i18n, ..)
• Completing current prototype of the extension manager and extension repository

Until 7th of July

• Working on extending the ScripterNG API
• Porting most needed features from old Scripter

Until 14th of July

• Writing mid-term evaluation
• Until 1st of August
• Further improving the API
• Writing examples
• Porting old extensions like the OpenClipArt browser

Until 11th of August

• Fixing bugs
• Reviewing and improving usability
• Writing documentation for users and developers

Until 18th of august ('pencils down')

• Writing final evaluation

Benefits

1. Scribus gets a new easy extendible and maintainable scripting plug-in and API.
2. Other developers without knowledge of a given scripting language can make their enhancements available for scripting.
3. Scribus gets an additional popular scripting language: JavaScript (QtScript).
4. Scribus users get a powerful and more freely extendible desktop publishing platform. This will lead to more features, many new ideas and hopefully even more satisfied users.

UniConvertor and GraphicsMagick integration

Hermann Kraus <hermann@physiklaborant.de>

Rationale

Scribus aims to be a professional level DTP application and therefore has to deal with many different file formats. While it already supports quite a few formats, some others are still not or incompletely supported. UniConvertor, which is "a universal vector graphics translator"[1] can help for vector formats and GraphicsMagick, which is a branch of the well-known ImageMagick, does the same for bitmap formats[2].

Motivation

My motivation for doing this project is that I think it will be a huge benefit for Scribus and I like this kind of work (gluing two programs together). I did this last year with LaTeX and Scribus. From the feedback I received both from the users and developers, I think it is fair to say it was well received. This year I want to accomplish something similar and my aim is for results as good or, based on my previous experience, even better than the last time.

Overview

My plan is to write an import filter for Scribus that uses UniConvertor and GraphicsMagick to read most of the formats supported by these programs. An export filter is an optional part.

Benefits to Scribus

By using these libraries it is no longer necessary to write a new filter for each new file format, but we can benefit from the formats added to shared libraries. For example, Inkscape[4] also uses UniConvertor since version 0.46 [5]. As a result, new file formats and improvements added to the external libraries should be usable in Scribus faster.

Use cases

Importing all kinds of vector and raster formats.

Deliverables

• Import plug-in for UniConvertor
• Export plug-in for UniConvertor (optional)
• Import only plug-in for GraphicsMagick (or integrated into the main code)
• A new import mechanism (file dialog) for vector files
• Documentation

Links

• [1] http://sk1project.org/modules.php?name=Products&product=uniconvertor
• [2] http://www.graphicsmagick.org/
• [3] http://dvdwizard.wershofen.net/
• [4] http://www.inkscape.org
• [5] http://wiki.inkscape.org/wiki/index.php/ReleaseNotes046

Rationale

Scribus aims to be a professional level DTP application and therefore has to deal with many different file formats. While it already supports quite a few formats, some others are still not or incompletely supported. UniConvertor, which is "a universal vector graphics translator"[1] can help for vector formats and GraphicsMagick, which is a branch of the well-known ImageMagick, does the same for bitmap formats[2].

Motivation

My motivation for doing this project is that I think it will be a huge benefit for Scribus and I like this kind of work (gluing two programs together). I did this last year with LaTeX and Scribus. From the feedback I received both from the users and developers, I think it is fair to say it was well received. This year I want to accomplish something similar and my aim is for results as good or, based on my previous experience, even better than the last time.

Overview

My plan is to write an import filter for Scribus that uses UniConvertor and GraphicsMagick to read most of the formats supported by these programs. On IRC I was told that export with UniConvertor is "quite restricted", so I will add export filters only if they turn out to be useful.

UniConvertor

Previous experience

I've not worked with UniConvertor before, so this information is based on a short research only and the implementation details are likely to change. However, the Unicoverter developers are very cooperative with Scribus and other graphics application developers. It is very reasonable to expect that will continue or even improve over time with my project.

Implementation

The import plug-in will either call UniConvertor directly and get "raw" commands to create the vector objects. The third option will use UniConvertor to convert to an intermediate format such as SVG and then read this format. The same applies to the (optional) export filter, but here it might be possible that some of the features supported by Scribus are not supported by the output format, so the user given an informative dialog explaining not all features are one for one transferable between each format.

Existing work

The SVG plugin can serve as a starting point for the new import plug-in.

User interface

The list in File->Import would become quite long, so that it might be good to replace these entries with a single file dialog.

GraphicsMagick

Previous experience

I have used ImageMagick, the base of GraphicsMagick, a lot. I customized the bash script based dvd-menu-tool dvdwizard[3] at a time when it was less powerful than today. I had to rewrite a lot of the graphics code which relies on ImageMagick. I also have a bit of experience with image frame loaders, because I learned about this part of the Scribus code when I was working on my LaTeX frames project.

Implementation

As GraphicsMagick deals with raster graphics, an import filter for image frames is required here. With libgraphicsmagic++, a C++ library for the GraphicsMagick functions, the integration should be feasible.

Existing work

The Qt image file loaders can serve as a starting point.

User interface

No new user interface is required, but a way to show previews for the new file types has to be found.

Build system

The build system has to be updated to look for UniConvertor and GraphicsMagick.

Benefits to Scribus

By using these libraries it is no longer necessary to write a new filter for each new file format, but we can benefit from the formats added to shared libraries. For example, Inkscape[4] also uses UniConvertor since version 0.46 [5]. As a result, new file formats and improvements added to the external libraries should be usable in Scribus faster.

Use cases

Importing all kinds of vector and raster formats.

Deliverables

• Import plug-in for UniConvertor
• Export plug-in for UniConvertor (optional)
• Import only plug-in for GraphicsMagick (or integrated into the main code)
• A new import mechanism (file dialog) for vector files
• Documentation

Timeline

• April 14: Accepted student proposals announced on the Google Summer of Code home page. Community Bonding Period: Students get to know mentors, read documentation, get up to speed to begin working on their projects.

I can start coding at this point, as I am already familiar with the Scribus development process.

• May 26: Students begin coding for their GSoC projects;

At this point I should have read the required documentation and probably the basic functionality for UniConvertor ready.

• July 7: Mentors and students can begin submitting mid-term evaluations.

UniConvertor should be fully working now and work on GraphicsMagick is started or about to be started.

• July 20: End of semester

Around this time there will be some exams at university, so expect me to be learning a bit more and coding a bit less. No exact dates are available yet.

• August 11: Suggested 'pencils down' date. Take a week to scrub code, write tests, improve documentation, etc.

Now the GraphicsMagick part should be completed too. The time lost with the exams should be no problem, as this part of the work should take much less time and I'll also use the "Community Bonding Period" for coding.

• August 18: Firm 'pencils down' date. Mentors, students and organization administrators can being submitting final evaluations to Google.

Links

• [1] http://sk1project.org/modules.php?name=Products&product=uniconvertor
• [2] http://www.graphicsmagick.org/
• [3] http://dvdwizard.wershofen.net/
• [4] http://www.inkscape.org
• [5] http://wiki.inkscape.org/wiki/index.php/ReleaseNotes046

Link to Further Information: http://wiki.scribus.net/index.php/GSoC_2008_UniConvertor_and_GraphicsMagick_integration

Scribus Picture Browser

Student Markus Thomas Durst
Student Email schlaumeier22@gmx.de

Abstract

Importing images is one of Scribus's core features and it's already well implemented. However, it lacks a proper and easy to use picture browser to make the selection of pictures from large collections easier. The basic goal is to create a picture browser similar to OpenOffice.org's "Gallery" [1], which allows users to select images from a neatly arranged preview with just a few clicks or drag and drop. Optional features like PictureFlow[2] and the display of additional information (metadata, color spaces, resolution) will further enhance the browsers usability. In addition, users will be able to access pictures from various external sources like network repositories and digital cameras.

Detailed Description

For a better formated version see the wiki: http://wiki.scribus.net/index.php/GSoC_2008_Picture_Browser

Rationale

Importing images is one of Scribus's core features and it's already well implemented. However, it lacks a proper and easy to use picture browser to make the selection of pictures from large collections easier.

Motivation

My motivation for this project is that i think this feature will greatly improve image handling in Scribus and I plan to deliver a vital contribution for all Scribus users (including myself). Furthermore, I like playing around with graphics and UI design, so that adding this feature corresponds with my personal interests.

Overview

The basic goal is to create a picture browser similar to OpenOffice.org's "Gallery" [1], which allows users to select images from a neatly arranged preview with just a few clicks or drag and drop. Optional features like PictureFlow[2] and the display of additional information (metadata, color spaces, resolution) will further enhance the browsers usability. In addition, users will be able to access pictures from various external sources like network repositories and digital cameras.

Implementation

The picture browser will provide access to large collections of images. It will be possible to drag and drop an image from the browser to a page. Alternatively, an image frame can be selected/created, and its content can be inserted from the browser. It will also be possible to add new and remove collections of images permanently as in the OpenOffice.org gallery. The picture browser will use the exisiting and possibly the new image file format plugins to make sure it can display all image types supported by scribus. If possible, Scribus will also be enabled to add online collections like Open Clip Art [3].

Existing work

The picture browser will be able to reuse much of Scribus's image-related code, eg. for previews, image data etc. Digital camera import could be based on existing digiKam[4] code. A prototype of a PictureFlow plug-in has been developed by a Scribus contributor who gave permission to extend his code.

User interface

I think the best solution is to keep this as simple as possible, but also to follow proven solutions. The OpenOffice.org Gallery is a well tested feature, which is used by millions of users all over the world, so that the picture browser in Scribus should work similarly. It will, however, need to be extended to meet the requirements of professional users. Scribus's "Manage Images" feature provides a solid basis to start from. It will be extended by a directory browser using a tree-hierarchy for easy navigation. The preview function will be altered to show all supported images in the selected folder and to provide basic filtering/sorting options (name, size etc). Optionally, the user can switch from the common preview list to PictureFlow. Moreover, the browser will allow users to create/remove collections of images.

Deliverables

- An advanced picture browser for Scribus - Documentation

Timeline

April 14: Accepted student proposals announced on the Google Summer of Code home page. Community Bonding Period: Students get to know mentors, read documentation, get up to speed to begin working on their projects I start learning the Scribus internals and Qt coding as I am not sufficiently familiar with the Scribus development process yet. I will also ask layout professionals on #scribus for their requirements.

May 26: Students begin coding for their GSoC projects By then, I should already be familiar with the Scribus development process and ready to start with the actual work.

July 7: Mentors and students can begin submitting mid-term evaluations: Most of the basic features like browsing folders/collections and a simple preview list should work right now.

July 20: End of semester Now the basic features should be fully working, and I will start implementing extras like PictureFlow and network / digital camera access. Some exams at university will keep me from finishing my tasks at this time, but I cant specify any dates yet

August 11: Suggested 'pencils down' date. Take a week to scrub code, write tests, improve documentation, etc. I will recheck my code and get some final feedback for minor changes, if necessary. Also, I will finish the documentation.

August 18: Firm 'pencils down' date. Mentors, students and organization administrators can being submitting final evaluations to Google. Hopefully everything is completed to the team's and my satisfaction.

Links

[1]http://wiki.services.openoffice.org/wiki/Documentation/OOoAuthors_User_Manual/Getting_Started/Working_with_the_Gallery [2] http://code.google.com/p/pictureflow [3] http://openclipart.org [4] http://www.digikam.org