GSoC 2011 Tables Proposal

From Scribus Wiki
Jump to navigation Jump to search

Basic support for tables in Scribus

Abstract

The Scribus software currently lacks proper support for laying out content in a tabular arrangement, a feature commonly known as tables. In the following document I propose to implement a first basic support for tables in Scribus. The proposal comes in three parts. First, a problem description where I provide a rationale for the project. Second, an implementation plan including project deliverables and a contingency plan. Third, a tentative timeline for the project, and last some biographical information and other practicalities.

Problem Description

Tables provide a compact way of representing tabular information in a page layout, and is a common design element in books, magazines and advertisements. Scribus currently has a shortcut for creating an automatically grouped table-like array of text frames. These are not proper tables. To stay competitive, Scribus needs better support for tables. Support that enables the user to create and edit tables as distinct items with their own set of properties as commonly found in other table implementations.

Implementation Plan

Having been through Summer of Code once before, I think I have a good perspective on what's important going into a project of this nature. One thing that cannot be stressed enough is the importance of having something tangible and working by the end of the project period. Not only will this give closure and a sense of accomplishment to me as a student, it also gives the Scribus core developers a good outlook when it comes to taking the code in and building further on it. To mitigate the risk of ending up with an unfinished project, a contingency plan is included. The contingency plan lists features that can be dropped from the project, should time start to run out.

Basic Idea

The implementation will be done by introducing a new page item, PageItem_Table. This item will be responsible for layout and drawing of a table. The layout and drawing of table cell content will be delegated to standard text frames, which might have to be given new features/modifications to better serve this purpose. As content in the table cells change, the table will be notified of this and perform a relayout of the table, starting from the row in which the change occured.

Project Deliverables

These are features that I believe are realistic to implement during the course of the project (but see further down for a contingency plan). For more detailed chronological information, see the timeline.

  • Tables
    • Insert, select, resize and remove.
    • Background color.
    • Border color.
    • Border style.
    • Default cell style.
    • Import from CSV and ODT.
  • Table Rows
    • Insert, select, resize and remove.
    • Background color.
    • Default cell style.
  • Table Columns
    • Insert, select, resize and remove.
    • Background color.
    • Default cell style.
  • Table Cells
    • Select and resize.
    • Background color.
    • Border color.
    • Border style.
    • Padding and margin.
    • Row and column spanning.

For all features, load/save roundtrip to Scribus .sla format will be supported. It might be good idea to do the import from CSV/ODT by providing a scripting API for the tables and implementing the import features as scripts.

Contingency Plan

If unforeseen difficulties are encountered during the project, one or more of the following features may be dropped. Hopefully to be implemented later. Note that should any of these features be dropped, an effort will still be made to keep the feature in mind, to avoid painting ourselves into any corners.

  • Scripting API
    This I really think I should be able to pull off. But should time run short, it may be dropped.
  • Import from CSV and ODT
    While hopefully not too challanging, technically, this feature may be time consuming and is something which can be added later. Hence it may be dropped.

Timeline

Below follows a rough tentative timeline for the project. The timeline is of course subject to change, should some parts of the project turn out to be more/less time consuming than anticipated.

I have my last exam on May 28, and my first day of school after the summer is Aug 28. This means my project period will be cut five days short in the beginning. It was the same thing during my project in 2009, and I believe it's quite common for European students taking part in Summer of Code. It just means the timeline has to take this into account.

In the time leading up to the project period, I'll try to acquaint myself with the Scribus code I'll be touching and experiment with data structures and layout algorithms for the tables I'll be implementing.

  • Week 1 May 29-June 5
    • Data structures for tables.
  • Week 2 June 6-June 12
    • Basic table layout with fixed column widths and mock content in cells.
    • Insertion/removal of rows/columns.
    • Basic drawing of table.
  • Week 3 June 13-June 19
    • More advanced layout.
    • Variable column widths.
  • Week 4 June 20-June 26
    • Cell formatting properties such as border and padding.
    • Cell content layout; use Scribus' text frames to populate cells.
  • Week 5 June 27-July 3
    • More integration of text frames. Fixing of issues/road bumps.
    • UI: Row/column selection/insertion/removal/resizing.
  • Week 6 July 4-July 10
    • Wrapping up for mid-term evaluation.
    • Fix bugs/finish up what I have so far.
  • Week 7 July 11-July 17 (Mid-term-evaluation)
    • Row and column spanning.
  • Week 8 July 18-July 24
    • Table/row/column/cell styles.
  • Week 9 July 25-July 31
    • UI: Direct formatting.
    • UI: Integration of styles in Style Manager.
  • Week 10 August 1-August 7
    • Scripting API.
    • CSV and/or ODT import.
  • Week 11 August 8-August 14
    • Wrapping up for final evaluation.
    • Fix bugs/finish up what I have so far.
  • Week 12 August 15-August 21 (Suggested pencils down)
    • Integration into Scribus trunk.
  • Deadline August 22 (Firm pencils down)

The Future

A big part of what makes a successful project is the student's level of involvement after the project period is over. Although the time I will have available for FOSS hacking will go down drastically after the summer, I'll of course stick around to answer questions, fix bugs and help out the best I can. I've stayed in contact with the KWord developers ever since my project in 2009, and I won't treat you Scribus folks differently. In short; I won't disappear on you.

Provided that the project is a success and I at least manage to implement all the mandatory parts in this proposal, these are some preliminary suggestions for isolated projects that can be done after Summer of Code to improve the tables implementation.

  • Table breaking across pages
    • This is quite a tricky thing to get right, but as Scribus already has the ability to break text content across multiple text frames, at least that piece of the puzzle is done.
  • Scripting API
    • Provide a scripting API for all functions of the tables.
  • Import from CSV/ODT
    • While both could be useful, perhaps CSV is more important than ODT initially. If this needs to be dropped during the course of my project, it could make a good isolated project for someone to take on afterwards.

Student Biography

Living in Stockholm with my girlfriend Hanna, I'm a 27 year old freshman at the Computer Science program at KTH Royal Institute of Technology in Stockholm. I've dabbled with Free Software for about 12 years now. In recent years KDE has been my main focus and in 2009 I implemented basic support for tables in the KWord word processor as part of Google Summer of Code. Previous employments include working at my dads small publishing company Nya Doxa AB and running my own book shop as well as a book café. I should note that Scribus has been a great help at both these positions. Apart from my studies I enjoy hiking our small Swedish mountains when I have the opportunity, and hanging out discussing with my friends over a beer. I have no other engagements this summer apart from Summer of Code.

Contact Information

Name: Elvis Stansvik
E-mail: elvstone@gmail.com
IRC: estan @ irc.freenode.net
Phone: +46763091545

Printable Version

A typeset printable version of this document is available here.