[scribus-dev] Tables GSoC draft proposal

[Gregory Pittman]

On 03/29/2011 03:53 AM, Elvis Stansvik wrote:
> 2011/3/29 Elvis Stansvik<elvstone at gmail.com>:
>> 2011/3/29 Elvis Stansvik<elvstone at gmail.com>:
>>> Hello again,
>>>
>>> As the student application period is now open, I'm planning on sending
>>> my application to Google soon.
>>>
>>> No further comments on my draft proposal below? I've done a couple of
>>> small edits in the version on the wiki [1], but it's essentially the
>>> same version as the one I sent to the list.
>>>
>>> Should I give it the "final" stamp and maybe make a typeset version of it?
>>
>> I made a quick LaTeX-typeset version of the proposal (attached).
>
> A few Unicode-related issues crept into that one. I've fixed them and
> also put it up on the wiki, where I'll keep it up to date [1].

Hi Elvis!

First suggestion: Clean the garbage from your emails. You could/should 
have trimmed down your post to the above. We have the archive to find 
old posts if we need them. This is a simple personal discipline issue.

Secondly: Try to get inside the head of a layout design user. While we 
want tables to interact with spreadsheet files and in some respects 
mimic the operation of a spreadsheet program, in layout design one is 
looking for things that you can't get from Excel/Calc or even 
Word/oowriter. We may want to make a table whose contents are links to a 
number of images, or you may start out with data/text, yet replace 
selected cells with images or replace a block of 2 or 4 or more cells 
with one image frame. Do all these need to be implemented for GSoC? No, 
but you need to anticipate these modifications later.

It actually puzzles me as to why, but for whatever reason, in word 
processor programs you can specify different characteristics for the 
different borders of a cell. Again, maybe something to anticipate rather 
than include in your project. What if someone wants a cell to be 
something other than a rectangle? Is this feasible?

Can a cell be a container for other Scribus content, such as render 
frames, polygons, arcs, spirals, even PDF form elements? Maybe container 
is a good paradigm to think about.

Lastly: Consider my position in the Scribus community as someone 
primarily involved with documentation. Don't take too seriously what I'm 
saying for one thing, but see if you can generate some information that 
can be used to generate user documentation for your implementations.

In summary: I think you have a solid proposal.

Greg