[scribus-dev] Cell splitting behavior
Elvis Stansvik
elvstone at gmail.com
Wed Aug 17 08:26:15 UTC 2011
Hello all,
While working on the table menu and its actions I realized that I had
left the splitCells(...) function of the table unimplemented. So
currently there's no support for splitting cells.
I'm planning on implementing this, however not this very minute. But
since the behavior/implementation of splitting is kind of non-trivial,
I have a couple of questions about how we want it to behave.
Since it's pretty hard to describe these behaviors in just words. I've
made a short (1:30) screencast showing how it works in InDesign. We
can then discuss around this, and my notes below. You can find the
screencast at
https://www.strongspace.com/estan/public/gsoc2011/indesign_splitting.webm
In the screencast I perform three different operations that shows the
behavior of InDesign when splitting cells. I've marked these scenarios
with the titles "1.", "2." and "3." in the screencast.
1.
Here I simply split two cells, one horizontally and one vertically.
Probably no surprises here, and I expect this is how we want it to
behave as well. The split cell is simply divided right on the middle
into two cells, the very definition of splitting something.
Internally this is implemented by inserting a new row in the table and
then adjusting the row or column spanning of the surrounding, thereby
giving the "illusion" of a cell being split independently. This is how
virtually all implementations of tables I've seen choose to implement
splitting, and how I will implement it as well. It's the easiest way
and won't require any changes to how the table is represented
internally.
2.
Now it gets a little more interesting. Here I split two cells
horizontally that are in the same row, and have the same dimensions,
but are not adjacent. What happens then is that, since InDesign
discovers that there's already an "underlying" row at the position
where one should be inserted, it will "reuse" this row. The effect is
that when I later move the boundary that resulted from the split, this
boundary will be moved in both of the split cells. It is in fact the
very same row boundary that is moved.
Even before I looked at how InDesign works, this is how I imagined
that we want it to work as well. Do you agree? When a split is
performed, this means first checking if there's an existing row
boundary that is sufficiently close (some very small epsilon
distance), and if so, reuse this boundary for the split.
3.
Here I do almost the same thing as in 2., but I resize the boundary
that resulted from the first split before splitting the second cell.
This is just to illustrate that the behavior will be different if the
requested split is not sufficiently close to the existing row
boundary. The result is that the boundaries in the two split cells can
now (obviously) be moved independently of each other.
So, after looking at the behavior of InDesign and reading my notes, do
you agree that I should go ahead and implement the same behavior?
No hurry with replying to this, as I have plenty of other work to do.
Cheers,
Elvis
More information about the scribus-dev
mailing list