GSoC 2008 UniConvertor and GraphicsMagick integration
|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.|
- 1 Rationale
- 2 Motivation
- 3 Overview
- 4 Details
- 5 Benefits to Scribus
- 6 Use cases
- 7 Deliverables
- 8 Timeline
- 9 Links
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" can help for vector formats and GraphicsMagick, which is a branch of the well-known ImageMagick, does the same for bitmap formats.
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.
My plan 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.
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.
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.
The SVG plugin can serve as a starting point for the new import plug-in.
The list in File->Import would become quite long, so that it might be good to replace these entries with a single file dialog.
I have used ImageMagick, the base of GraphicsMagick, a lot. I customized the bash script based dvd-menu-tool dvdwizard 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.
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.
The Qt image file loaders can serve as a starting point.
No new user interface is required, but a way to show previews for the new file types has to be found.
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 also uses UniConvertor since version 0.46 . As a result, new file formats and improvements added to the external libraries should be usable in Scribus faster.
Importing all kinds of vector and raster formats.
- 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
- 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.