[scribus-dev] Tables as Summer of Code project

[Elvis Stansvik]

Hello Scribus folks,

In 2009 I implemented basic support for table layout in the KWord word
processor as part of Google Summer of Code. This year I'm again
considering applying for GSoC.

I've always had a soft spot for Scribus, having used it quite a lot
for doing flyers and ads in the past. Hence I started looking into
applying with Scribus as a mentoring organization and found out that
you guys are considering tables support for Scribus as a GSoC.

Even though I'm sure you're very much aware that tables support would
be a big undertaking for a GSoC, I would first off like to raise a
warning finger, having been through it once; I think you'll be hard
pressed to find a student that will finish something that can be
called feature complete in one summer, unless the student is already a
core dev. Although my GSoC for KWord in 2009 was considered a success,
I did not finish all features specified in my original project
proposal. The reason it was still considered a success was that due to
the complexity of the task, me and my mentor early on agreed to have
certain features as optional in the project description. Among the
features that were not finished was table breaking across pages and
interactive table editing.

That said, I'd be very much interested in taking on tables support for
Scribus as a GSoC this summer, provided that we can can conclude which
parts of the support are to be considered mandatory, which are
optional and which of them that are out of scope for the project.

I have experience with Qt and C++, naturally, but apart from a small
feature I added a couple of years ago [1], I have no experience with
the Scribus code. Especially not with its core layout code.

I did a checkout of Scribus and tried to get an overview of the code,
and I must say that I'm a little worried; whereas in my KWord project
in 2009, due to a pretty strict documentation policy in KOffice,
almost every class and function was documented. In Scribus,
documentation of the classes seems to be the exception rather than the
rule.

So I have a few questions:

1) Am I right in that a table in Scribus would be a new PageItem?
2) Would tables leverage Scribus' existing layout mechanisms by having
each cell in the table be (or contain) a PageItem_TextFrame?
3) What about the ideas at [2], are they relevant?
4) Is there any "birdseye" developer documentation of how Scribus does
its layout, from loading to final glyph? Classes involved, patterns
used et.c.? If not, is this something that any of the core devs would
be willing to jot down off the top of their head? Wouldn't have to be
anything ambitious, just some notes. It would really help as a guide
when reading the source code.
5) Are there any refactorings, big or small, that needs to be done in
order to accommodate tables support? In my KWord project I was able to
do my work in a plugin, plus some reasonably small and isolated
changes to core layout code. What's the situation in Scribus?

I realize now that this mail sounds awfully negative :) But don't
worry, it's just me trying to be down to earth, as I know it's
important to iron these things out beforehand. Especially important is
to iron out what will be the scope of the project.

If you're interested I dug out my old patches from GSoC 2009 [3] and
if you want to read my blog posts regarding the project from back then
it's at [4].

Looking forward to your input!

Best regards,
Elvis Stansvik

[1] http://bugs.scribus.net/view.php?id=7126
[2] http://wiki.scribus.net/canvas/Tables
[3] http://dose.se/elvis_stansvik_gsoc_2009/
[4] http://estan.dose.se/tag/gsoc