GSoC 2008 UniConvertor and GraphicsMagick integration: Difference between revisions
Line 10: | Line 10: | ||
My motivation for doing this project is that I think it will be a huge benefit | 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 | for Scribus and I like this kind of work (gluing two programs together). I did | ||
this last year with LaTeX and | 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. | good or, based on my previous experience, even better than the last time. | ||
Revision as of 19:40, 30 March 2008
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
I plan to write an import filter 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.
Details
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.
Implementation
The import plug-in will either call UniConvertor directly and get "raw" commands to create the vector objects or it 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 will be warned.
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.
Other changes
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.