From koffice-devel Fri Mar 27 15:18:06 2009 From: Elvis Stansvik Date: Fri, 27 Mar 2009 15:18:06 +0000 To: koffice-devel Subject: Re: Formal GSoC Proposal [Second Draft]: Basic tables support for Message-Id: <751a4f870903270818n75b17da3q31e87945c9190ec7 () mail ! gmail ! com> X-MARC-Message: https://marc.info/?l=koffice-devel&m=123816714218636 2009/3/27 Thomas Zander : > On Thursday 26. March 2009 22:04:39 Elvis Stansvik wrote: >> Below is a second draft of my formal GSoC proposal. Please point out >> if you think there's anything that I should leave out or if there's >> any glaring inaccuracies. I plan on submitting my proposal on Monday. > > Hi Elvis, > > The suggestion looks good. I like the level of detail! > > I would suggest you add the concept of unit testing to your application.  The Good idea. An updated draft is at the end of this mail with a fifth paragraph under the "Implementation Details" section about unit testing. > loading/saving of ODFs is already unit tested using the work that Girish did > last year but it doesn't test any tables loading yet. > I suggest to extend his work with tables loading tests and aim to keep the > existing unit tests passing. > > Next to the loading the text-layout is also heavily unit tested (see the > plugins/textshape/tests/ dir) since this is practically the only way to write > something as complex as a (text) layout engine without breaking what already > exists every time you make a little addition ;) Ah, I was aware of Girish's loading/saving work in libs/kotext/opendocument from before. Good to know where the layout tests go. Which tests go in libs/kotext/tests BTW? More low-level kotext tests? > So I would suggest having all new features that you write for tables to have > an accompanying unit test written. > This additionally makes it possible to design a simple tables layouting > structure first and make that work. Later, when your knowledge and insight in > the matter grows, you can probably restructure or even rewrite the code in a > fraction of the time when more features have to be supported, and the unit > tests will help you to make sure that what worked before still works after > such changes. We <3 tests ;) > > Would your proposal be selected I offer to mentor it. That's great. Thanks for the input. Elvis > -- > Thomas Zander > > _______________________________________________ > koffice-devel mailing list > koffice-devel@kde.org > https://mail.kde.org/mailman/listinfo/koffice-devel > > DRAFT Name: Elvis Stansvik Email Address: elvstone@gmail.com Freenode IRC Nick: estan Location (City, Country and/or Time Zone): Örebro, Sweden, GMT+1 Proposal Name: Basic tables support for KWord Motivation for Proposal / Goal: Tables are common in many documents, and can be considered a key feature of a word processor. KWord currently lacks a competitive implementation of tables in its latest iteration, the upcoming 2.0 release. In this project, I will try to build a basic and robust implementation of editable tables, including loading and saving, that can later be extended to a more competitive implementation. I'm fully aware that this is an ambitious task that might be more suited for one of the core developers, but I think this year's Summer of Code could be a good opportunity to get the ball rolling on this, because let's face it; it will have to be done at one point or another. Implementation Details: My implementation will use the built-in support for tables in Qt's Scribe framework. I will modify the text layout engine in KOffice's kotext library to support layout of text into table cells instead of into the normal document flow of the text shape. I'll also add loading and saving code and will try to map as many of the ODF table related style attributes in the ODF specification to properties of KOffice's and Qt's style (/format) classes as possible, extending them where necessary. I'll do this in order of importance, starting with the attributes required for a very basic table implementation first. I will ensure correct cursor and selection behavior during keyboard/mouse interaction as well as correct table breaking at page boundaries. The table editing functionality will most likely be part of one or several tools working with the text shape and will allow the user to split/merge cells, resize rows/columns, edit the table heading et.c. I'll put quite some focus on documenting my implementation and, together with my mentor and other KOffice developers, making sure that it will scale well to meet the demands of a future full implementation of ODF tables, and possibly also taking into account the requirements of tables as they are specified by the Microsoft Office .DOC format. Unit tests for both loading and saving as well as layout of the tables will be added to the existing infrastructure in libs/kotext/opendocument/ and plugins/textshape/tests/ respectively. I'll take care to keep the tests passing as my work progresses and make sure any new features I add along the way will be covered by unit tests. Tentative Timeline: June 1-June 30 - Basic functionality I will begin by implementing minimal loading/saving as well as basic display and editing. Using this first iteration, the user should be able to load a document containing a very basic 3x3 table [1], and remove and add columns and rows to it and save the document. More specifically I will add basic support for the following ODF elements: o o o o o along with a basic subset of the properties of their corresponding style families: o o o Such as e.g. July 1-August 10 - Extended functionality In this second step, I will: o Add support for row and column span. o Add support for splitting/merging of cells. o Improve the behavior of tables breaking across multiple pages by duplicating the cell position/size calculations performed inside Qt in order to determine where the break will occur and be able to do the break myself at a desired location. o Make sure shapes can be put into table cells, possibly by creating a new kind of anchoring mechanism in kotext for cells which are not allowed to contain any text. o Add support for more of the table related style properties of the ODF specification. August 10-August 16 - Finishing up Fix any outstanding bugs and write missing unit tests and documentation. Do you have other obligations from late May to early August (school, work, etc.)?: My studies ends on May 31, so I can't really start full-time coding until then. During the summer I may have to do some part time work for a publishing company to be able to pay my June rent, but it's flexible hours and I'll essentially be able to work 100% with my project throughout the summer. About Me (let us know who you are!): My name is Elvis Stansvik. I'm 25 years old. Most of you probably know me as 'estan' on FreeNode. I live in the nice little town Örebro, about 200 km west of Stockholm, Sweden. I've been tinkering with free software for about 10 years and I've had an increased interest in programming in the last 4-5 years. I already have a handful of commits to KOffice. They would be many more had I not been so busy with work and studies. My past experiences are quite varied and include working with a small non profit wireless ISP in the rural town of Nora, running my own book shop and later book café and working as an IT technician at a book publishing company. Currently I'm brushing up my old high school (gymnasium) grades at a local school, and after this summer I'll be in uni. Things I enjoy other than free software include traveling, swimming, the occasional painting session (oil or acrylics on canvas), hiking the Swedish mountains and hanging out with friends in my home town. [1] Roughly the minimal example at the very end of 8.1 Basic Table Model in the ODF (v1.1) specification. _______________________________________________ koffice-devel mailing list koffice-devel@kde.org https://mail.kde.org/mailman/listinfo/koffice-devel