[scribus-dev] Tables GSoC draft proposal

[Elvis Stansvik]

Hi Gregory,

2011/3/29 Gregory Pittman <gpittman at iglou.com>:
> [...]
> 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.

Really sorry about that. Different lists have different policies, or
maybe people have just been too shy to tell me. Thanks for pointing it
out. Won't happen again, promise! ;)

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

I guess my background in implementing tables for a word processor in
the past might shine through a bit in my proposal :) It's good that
you bring this up. For the use case you bring up, having images as
cells (possibly spanning several cells), I believe this should be
possible using "traditional" tables by using cell background images
combined with row/column spanning.

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

I'll answer the question of different cell border characteristics for
the different sides of cells first (I believe this is what you
meant?); I think this might have a use case even in graphical design.
See e.g.

http://www.creativepro.com/article/master-indesign-s-tabs-and-tables

for an example where I believe this feature has been used.

As for non-rectangular cells; it is true that a user might want to
layout e.g. hexagonal cells in a "beehive formation", or use other
types of non-rectangular "cells". My Summer of Code project is only
concerned with tables in the traditional sense though. Of course I'll
do my best to make these as intuitive and useful as possible for
graphic designers.

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

It is a good paradigm. And I can keep that in mind when writing the
code so that it will be feasible for my table layout code to lay out
other items apart from text frames in the future.

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

I take all advice seriously! And your input is very valuable. Just
like you say, at the highest level of abstraction, tables are just a
collection of containers layed out according to certain rules. And
it's always good to keep abstraction in mind when writing new code.
But my project is by its nature limited, and I've decided to stick to
the traditional definition of tables. That is, a rectangular array of
rectangular cells. Baby steps you know ;)

But I'll keep in mind that one day we might want something more
abstract, maybe something called a "Collection", which could have
different strategies for layout, and of which my table layout code
would be one strategy. Although I can't see into the future, I'll try
to write clean and modular code with this in mind.

Finally, I'll make sure to at least jot something down that can be
used as a basis for user documentation during the project. Perhaps
I'll also have time to help out with writing it after the project
period is over.

>
> In summary: I think you have a solid proposal.

Great. And thanks again for your input.

Elvis

>
> Greg
>
> _______________________________________________
> scribus-dev mailing list
> scribus-dev at lists.scribus.net
> http://lists.scribus.net/mailman/listinfo/scribus-dev
>