GSoC 2008 Final Student Applications

From Scribus Wiki
Jump to: navigation, search

Short list to facilitate mentor ranking discussion:

1. OPENDOCUMENT EXPORTER AND IMPORTER (viwe simon lolwane)

2. ScripterNG - a new scripting plug-in for Scribus (Henning Schröder)

3. UniConvertor and GraphicsMagick integration (Hermann Kraus)

4. new application: Xml Editor (Vijay Kartick)

5. SVG import and export (LEMAIRE Adrien)

6. XML Story Editor for Scribus (Steven Bartz)

7. Tailored user interface for common creative projects (Ryan Prior)

8. Scribus Picture Browser (Markus Thomas Durst)

1. Title/Summary OPENDOCUMENT EXPORTER AND IMPORTER Student viwe simon lolwane Student Email ghostnet2000@gmail.com

Student Major Computer Science Student Degree undergrad Student Graduation 2009

Organization Scribus Team Assigned Mentor No Mentor Assigned Score 0

Abstract The ISO Opendocument format is a standard that is used to exchange Information over various application, this standard is used by many projects or applications like the Open Office. The scope of this project is to improve or write the current Scribus 's open Office support, so that it can import and export the opendocument format file without data loss. This will enable Scribus to support and exchange information with Open Office.

Detailed Description OPENDOCUMENT EXPORTER / IMPORTER BY VIWE SIMON LOLWANE email : ghostnet2000@gmail.com

Introduction

The ISO Opendocument format is a standard that is used to exchange Information over various application, this standard is used by many projects or applications like the Open Office. The scope of my this project is to improve or write the current Scribus 's open Office support, so that it can import and export the opendocument format file without data loss. This will enable Scribus to support and exchange information with Open Office.

About me

I am a final year student at the University of South Africa, studying towards a Bsc degree in Computer Science. My programming skills are c++, python, java, c# and delphi. I am familiar with the Qt / KDE framework, I have a 3 year experience on 3D modeling and animation, the current software that I use is Blender. My current interest are on how a 3D raytracer rendering engine can be build. I have worked on a small project to reduce, high polygon meshes to lower polygon meshes without losing details of their structure.

Description

This can be done by extending the current Scribus OO text importer and OO text exporter plugin and write a plugin that will import / export a valid opendocument file format. I would need to research or analyze the current Scribus OO text / importer and the current structure of the Scribus document so that I can write an exporter and importer that are complaint to scribus. The project s schedule is a three month project and it must be completed in this time frame.

Software development process

The project will be designed with Extreme Programming “XP” software development process. Since executable Code is the most important part of the ultimate deliverables of the software development process, XP focuses on the executable code from the very beginning, the process consists of frequent and small releases, each iteration produce a release. The very first iteration will produce a minimal, skeleton and executable implementation of the system being developed, then each subsequent iteration should enhance or improve upon the deliverables of the exceeding iteration and produce a new executable code. Which will be posted on the website for users to download, and test it. I selected XP process because it fits well into system developed on open source, where frequent releases are a norm, and the process involves both users and developers to take part, and the best part is that some RUP ( Rational Unified Process ) Models like UML can be incorporated on the process.


Testing

The frequency of defects discovered during each phase of the cycle falls within the following ranges, most are found during unit testing,followed by product testing and system testing respectively. This show that identifying and fixing defects during unit testing is significantly less expensive than doing so during other phases. This means that testing should be performed from the very beginning of system development and we must make sure that all the test are validating the planned functional coverage or use.

Project deliverables

The project deliverables are divided into functional and non functional requirements.

Functional requirements The project should have a Open document complaint exporter The project should have a Open document complaint importer The importer must import a complaint Scribus document Each import and exporter must be be created as separate plugin

Non functional requirements All plugins should be user friendly and responsive without freezing other windows

By project completion all requirements should be delivered.

simon viwe lolwane

2. Title/Summary ScripterNG - a new scripting plug-in for Scribus Student Henning Schröder Student Email henning.schroeder@gmail.com

Student Major computer science Student Degree undergrad Student Graduation 2008

Student IM 12036401 (ICQ)

Organization Scribus Team Assigned Mentor No Mentor Assigned Score 0

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.

Detailed Description

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.

Project

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:

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.

Questionnaire

Available at http://wiki.scribus.net/index.php/GSoC_2008_ScripterNG

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

3. Title/Summary UniConvertor and GraphicsMagick integration Student Hermann Kraus Student Email hermann@physiklaborant.de

Student Major Physics Student Degree undergrad Student Graduation 2011

Organization Scribus Team Assigned Mentor No Mentor Assigned Score 0

Abstract 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


Detailed Description 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.

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. 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.

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.


Bio:


I study physics at the university of Regensburg in Germany [www.uni-r.de] in the fourth term. My school thesis ("Facharbeit") about creating a PC controlled function generator included as practical work hard- and software design. This meant writing programs for both the PC and a microcontroller and it was completely done using open-source software. The work was graded 30 points of 30 possible. I'm interested in computers and electronics in general and I've taught me all programming languages (except for Pascal, which I had the chance to learn at school in the 5th grade) myself. I've already modified some open-source applications to fit my needs and contributed patches to simulavr (a microcontroller simulator). Created a kernel module to upload firmware to a TUSB3410 device and also completed my SoC 2006 project successfully. And of course my LaTeX frames SOC 2007 project was also completed and I still maintain it.

Links


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

4. Title/Summary new application: Xml Editor Student Vijay Kartick Student Email jayka417@gmail.com

Student Major Electronics and electrical Student Degree undergrad Student Graduation 2009

Organization Scribus Team Assigned Mentor No Mentor Assigned Score 0

Abstract In this project the an xml editor will be created as enhancement to the Story Editor to enable users to edit the XML content of text frames,so that advanced users can edit it manually.

Project Goals:

  • Create an xml editor describing the textframes
  • Support to import/export css style files(which are applicable to text)
  • Availability of built in styles.

Detailed Description Name:Vijay Kartick.P University: College of Engineering ,Guindy,Chennai,India Email:jayka417@gmail.com Major:Electrical and Electronics,Undergraduate Year of passing:April 2009

==========================================================

I've submitted a previous application.I made changes to project goals due to preponed campus placement interviews.

==========================================================

Biographical Sketch: I am Vijay Kartick.P, son of Prem Kumar.S and Bavani Premkumar, born on 14th december 1987. I took computer science group in my tenth grade and learned C and visual Basic 6.0.Around that time designed simple games like chess,monopoly and tic-tac-toe with VB6.0. I was also the Head of the computer club during year 2002-2004 and was editor of maths and science magazine for the school.I joined college in the year 2005 in Electrical and Electronics department.I gained interest in ethical hacking during second year. I learned python,xml,PHP,MySql,windows and unix system and network programming,etc by myself.I also started preparing for CEH certification and accustomed myself with various tools. I partcipated in both international and national level hacking and programming contest and won them. In 2007 i organised "404- File not found" an online hacking contest for our college symposium "Kurukshetra" which got UNESCO patronage.

http://onlinehacking.kurukshetra.org.in http://kurukshetra.org.in

We got participation of 1188 students from colleges all over the country and outside. I also created various libraries in c# for image processing and pattern recognition. My recent project is "RssGlut" an opensource rss feed reader designed using python and sax parser. It reads the rss feeds and converts them into Html pages.It requires a Html generator module and GUI which are under development. Apart from that i'm also a pretty good painter.

6. Title/Summary XML Story Editor for Scribus
Student Steven Bartz
Student Email steve.bartz@gmail.com

Student Major Undecided Student Degree undergrad Student Graduation 2012

Student Home Page stevebartz.com Student IM magicstick254 (AIM)

Organization Scribus Team Assigned Mentor No Mentor Assigned Score 0

Abstract XML provides a way of structuring a document. Scribus provides a way to make fantastic-looking documents. So it's natural to want to combine the power of both tools.

XML is a standard that goes far beyond the scope of desktop publishing. The Internet demonstrates the power of XML to divide documents, and it shows how natural this setup can be. XHTML contains the structure of the document and CSS contains the information about how the document should be displayed. With Scribus, this division is also natural. Styles are applied to sections of a document according to the content.

Yet in the current implementation of a Story Editor in Scribus, it is not possible to edit the structure of the text contained by text frame. Stories can only be given a structure by the application of various paragraph and character styles. The ability to edit the XML of text would make Scribus really shine.

Adding an XML editor to Story Editor is an important step in Scribus's future, because it will lead to many new and important features. Scribus is capable of becoming a Content Management System (CMS) and a versatile piece of software to create complex printable styles for XML-based files. Scribus will still be a Desktop Publishing application, but it will capable of doing so much more.

In order to include an XML editor within Story Editor, Story Editor must be rewritten, a task that on its own was already quite necessary and valuable. Story Editor is a critical component of Scribus. The update of Story Editor and the addition of an XML editor will bring Story Editor to the same level as the other components of Scribus.

Detailed Description VISION The goal is to bring XML editing control to the Story Editor. XML will not only add new power to Scribus and Story Editor, it will change the way text is edited and controlled within text frames.

Story Editor in its current iteration is hard to use. Formatting is supposed to be applied in Story Editor, but most users are unable to see the changes they are making in Story Editor without reverting to the page view.

My vision for the XML editor is a toggle. Users can switch to XML editor mode and make use of XML's ability to organize and structure documents. XML's strict structuring makes very good sense for most uses in Scribus. Users have a handful of styles for each document that they want to apply to certain parts of the document according to its place within a document.

DELIVERABLES

  • New Story Editor code
  • XML Editor for text frames
  • Story Editor modes (XML, plain text, etc.)
  • Documentation

POSSIBLE SPINOFFS

  • Python Interface Tie-in

According to Scribus developer Craig Ringer, "The ability to expose the internal XML for text objects might also be rather interesting for the Python interface."

  • Document XML Editor

Text objects are the majority components of Scribus documents. With the ability to edit the XML, it would not take much more to have the ability to edit the XML of the entire document.

  • XML/CSS

An XML editor moves Scribus one step closer to division of content and style. We can style the same content with a completely different styles. Say we have a marketing campaign with a slogan, an explanation and maybe a picture. We can create many different materials just by altering the stylesheet.

  • Content Management System

Many Scribus documents are big projects that are worked on by more than one person with different skills. Photographers need to edit photos. Illustrators need to edit graphics. Editors need to edit text. With an XML editor, Scribus is one step closer to having functionality similar to Adobe's InCopy, but in a much more open way. With this, Scribus is capable of attracting the same widespread use as GIMP.

IMPLEMENTATION After talking with the Scribus Community in the IRC channel, we have decided that the code of Story Editor needs to scrapped and rewritten. This is the perfect opportunity to introduce new functionality and provide the framework for additional powerful upgrades to Story Editor.

RESOURCES

  • Inkscape's XML editor
  • KXMLeditor
  • Scribus Team

POTENTIAL ISSUES

  • Size of Project

I have been told and understand that this Story Editor project will be massive project. It will certainly not be a simple task to rewrite Story Editor with my new features. However, I am not worried about finishing it within the scope of GSoC. The Scribus Team is quite supportive. They have helped me turn just my simple interest into a complete project plan. I am dedicated to making my vision of Story Editor within Scribus a reality. I have the ability and support to get this project done.

  • Code

Rough plans originally included the ability to preview text formatting in the Story Editor. This may not be feasible due to issues with the way Scribus is currently rendering text. Additionally, some fonts can not be drawn by Qt because the font libraries of Scribus and Qt are not necessarily the same.

TIMELINE

  • April 14 - May 7

Getting up to speed with Scribus internals.

  • May 7 - May 26

Develop firm plan for the new Story Editor in cooperation with the developers and the community.

  • Week 1-3 (through June 16)

Rewrite current Story Editor so it meshes with current codebase.

  • Week 4-6 (through July 7)

Add XML Editor component.

  • Week 7 (through July 14)

Complete Mid-term report. Readjust project schedule to reflect current pace and progress.

  • Week 8-9 (through July 28)

With advice and direction from the Scribus developers, improve usability and seamless integration of Story Editor, especially the included XML Editor.

  • Weeks 10-12 (through August 18)

Fix new documentation. Test code and fix bugs. Work out plans/details for additional new features now possible.

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

7. Title/Summary Tailored user interface for common creative projects Student Ryan Prior Student Email ryanprior@gmail.com

Student Major Computer Engineering Student Degree undergrad Student Graduation 2006

Student Home Page http://www.ryanprior.com Student Blog http://www.ryanprior.com/?feed=rss2 Student IM ryanprior (gmail.com)

Organization Scribus Team Assigned Mentor No Mentor Assigned Score 0

Abstract Scribus is an excellent application for desktop publishers, but many users are intimidated by the great flexibility and number of features that Scribus presents. I would like to create a set of alternate user interfaces tailored to creative print projects such as greeting cards, posters, and business cards so that novice users can get an introduction to Scribus and have fun creating their own print projects from scratch. Integrating with projects like Inkscape, the Creative Commons, and OpenClipart.org will allow for a novice-friendly print shop application that brings the best of open source and open content together!

Detailed Description My name is Ryan Prior (priorra@uwec.edu) and I am a computer engineering student at the University of Wisconsin in Eau Claire. My homepage is http://www.ryanprior.com - it is a new one, but I intend to start blogging in earnest this summer when I have more time to fiddle with things that aren't C++ and discreet mathematics.

I have a fair amount of experience with C++ and Python, having programmed with C-like languages for years and having studied C++ in college classes and for my own enjoyment. I have a some experience with Scribus from fiddling around with it, but I have never done significant hacking on the code base. I have used Scribus and Inkscape to produce many posters, flyers, banners, and other print projects. I am experienced with programming on Linux and use Linux as my desktop, development, and server operating system. I also have a fair amount of experience programming on Windows, growing up and cutting my programming teeth with Microsoft products. I have no experience with programming on Mac OS X, though as a Unix user I am confident in my ability to read documentation and communicate with others in order to gain knowledge of Mac OS X as I need it.

I am an enthusiastic open source developer, and though I have not made my mark on any major open source projects, I enjoy downloading source code and tinkering with it. As a young college student, I have no experience in the commercial software industry. However, in high school I apprenticed in the UW-Madison Peptide Synthesis lab, which gave me valuable experience communicating with busy, technical, and highly intelligent people, reading dense documentation, mastering systems with many complexities and details, and being part of a large community with many aims and goals. I am comfortable communicating over Internet channels including IRC, mailing lists, web forums, change logs in controlled versioning systems, and issue tracking frameworks, and I pride myself in my competence as an effective communicator. I am a very friendly and open developer: I like to let others know what I am doing in order to keep them in the loop and enable their commentary, discussion, and guidance to lead me to greater success.

I would like to implement an interface for Scribus that allows people with little understanding of desktop publishing to complete creative projects such as greeting cards, posters, letterheads, and business cards.

  • A project type should be defined by which UI elements are needed to compete the design, which print sizes are likely to be used, and what sort of templates the user is likely to want to start from.
  • Projects should be able to be completed by somebody who is not very familiar with the GUI interfaces of creative applications, but should also contain advanced controls for more capable users.
  • The focus is on enabling creativity by simplifying interfaces and providing gentle guidance where possible. It should not be a cookie-cutter greeting card application like many from e-card companies, nor should it be as flexible as the full-fledged Scribus interface.
  • Ideally, interaction between Scribus, Inkscape, The GIMP, the Creative Commons, and OpenClipart.org should be implemented in order to bring the best features of each program to Scribus users generally, and users of these specialized project interfaces in particular.

That list is intentionally ambitious; as a beginning step of this project, I will collaborate with the Scribus developers to decide which points are most important in order to prioritize the list and schedule delivery dates for the enhancements. If it is determined that I will not be able to reasonably complete everything I have outlined, I will develop a road map usable by myself or other developers in order to carry the project forward and ultimately produce a really excellent new tool for Scribus users. I will have all day every day to work on this project, and there is little that I love more than sitting in front of a computer and writing code for something I'm excited about!

Link to Further Information:

8. Title/Summary Scribus Picture Browser Student Markus Thomas Durst Student Email schlaumeier22@gmx.de

Student Major Physics Student Degree masters Student Graduation 2011

Organization Scribus Team Assigned Mentor No Mentor Assigned Score 0

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.

Details


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

Biographical Sketch


My name is Markus Durst, and I'm a student of physics at the university of Regensburg in Germany (http://www.uni-r.de) in the fourth term. My first computer was a 286, with which I started coding in QBasic. Later I switched to C/C++, and I have several years of experience with both languages. In addition, I have some knowledge in ASM and PHP. I am also very interested in computer security related issues and have already visited a couple of CCCs (Chaos Communication Congresses) in Germany.

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

Link to Further Information: